Hi Gregg,
Gregg Wonderly wrote:
Mark Brouwer wrote:
"With regard to RIVER-230 I'm wondering whether the request for
improvement is "a good thing", given the fact that ClassDep specifies
Platform specific classpaths and file paths. I don't think we should
take 'advantage' of the fact Java also accepts the wrong file separator
for the Windows platform. I believe that Ant can provide the proper
abstraction layer so you won't run into any problems as the build files
of the River project show, or that other Ant tasks on top of ClassDep
provide. Personally I would like to close RIVER-203 as "Won't fix", but
maybe I'm missing something, so please shoot if my reasoning is wrong."
This is what I was disagreeing with. The Java platform already honors
the mixed usage. I assert that this is a good thing because the
contents of executable Jar files can contain file paths that need to be
acceptable on all Java VMs.
This expectation, in my opinion, is not unrealistic and thus I am
bringing my view here. I appreciate that in the case of Ant, there is
${/}. But, there are other ways to run ClassDep and I think that
supporting / and \ as equivalent is something that makes sense because
the Java platform already does.
My reading of the following part in java.io.File always gave me the
impression that Java on the Windows platform required path names to be
used at construction time with backward slash.
"When a pathname string is converted into an abstract pathname, the
names within it may be separated by the default name-separator character
or by any other name-separator character that is supported by the
underlying system."
The default name-separator character on Windows is '\' but it is just
after some digging that I found out Window (in its native APIs) also
supports the forward slash character, see
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4745638 (it was quite
shocking to find this out).
So I think you are right, I will reopen this issue for someone else to
resolve it. Do want to have a go at it Gregg ;-) ?
--
Mark
