Community
Participate
Working Groups
Source based, circa v_831 (present since mid 2005 at least) ClasspathJar#getPath overrides FileSystem#getPath which is expected to return an absolute path. Not so. Running the batch compiler with parameters '-cp lib.jar X.java' leads to getPath returning 'lib.jar'. Found this out while investigating bug 97332. While the fastest cure would probably be to fix the comment (this is an internal package anyway), I believe we should examine carefully whether we want to respect the contract or to amend it, and to examine the implications in other parts of the code. Hence this bug.
First exploration raises the following comments: - ClasspathDirectory, a sibling class of ClasspathJar, honors the contract; this would support aligning the implementation with the API; - the same class caches the path, whereas ClasspathJar only caches the normalized path; for reasons of homogeneity, I'd rather cache both in all cases (the impact does not seem too heavy); - ClasspathJar#normalizedPath suffers the same bug as ClasspathJar#getPath. Will craft a fix that caches path and normalizedPath as absolute paths in all cases.
Note also that: - we use absolute paths, which may be different from canonical paths on certain platforms; but this is what is documented, hence it should be fine; - ClasspathJar is more prone to white-box testing than ClasspathDirectory, which constructor is not public; I won't change the visibility for the sole benefit of whitebox testing though; - normalizedPath also replaces exotic File separator by '/' for all implementations, which is not clear from the doc; my patch refines the doc in this respect.
Created attachment 86658 [details] Fix + test cases
Kent, would you please tell me what you think?
looks simple enough
Released for 3.4 M5.
Verified for 3.4M5 using build I20080204-0010
