Community
Participate
Working Groups
If the iajc ant task's classpath attribute contains jars not ending in .jar (for example some end in .jar.0), then these jars are ignored from the classpath, confirmed by various compile errors saying that such and such type cannot be resolved. If the same jars are renamed to end in exactly .jar then everything will compile without issue. It appears as if the ajc compiler (or perhaps iajc ant task) is filtering out jar classpath entries that do not exactly end in .jar. Having jars that end in .X is very common where jars are symlinked. This bug is a blocker to using ajc in any such environment.
Is anyone interested in fixing this? It seems to be rather trivial, and would make ajc usable more widely.
i am interested in fixing it, just havent had time.
I've had a brief look. It appears that the classpath is run through a ZIP filter first (which checks for a .jar/.zip ending). However in the process of converting the classpath components into absolute locations, it also converts them to the canonical form. On unix the canonical form will resolve any symlinks ( in this specific case .jar -> .jar.0 ) which the zip filter then ignores. I don't know much about canonical v absolute file path but is there a reason why ajc needs to use the canonical representation? I will look into patching this over the weekend but I think it will boil down to: (1) not using the canonical path. (2) not performing the zip filtering. Having looked through the rest of the code, I don't think (2) is an option. It is probably fair for the compiler to assume that jars end in .jar as it also assumes class files end in .class. Therefore (1) might be the best option. I'll investigate over the weekend to confirm if this is the case.
Created attachment 73830 [details] Removal of canonical file logic from ConfigParser.makeFile(String):File The ConfigParser converts each of the classpath elements into a canonical representation. Then, at a later stage, AspectJ filters out elements on the classpath that do not end in .zip/.jar. The problem here is that resolved symlinks e.g. myjar.jar -> myjar.jar.0 are filtered out because of the canonical conversion. This patch simply converts the classpath component to an absolute path and leaves it like that. The patch is in the following: org.aspectj.util.ConfigParser.makeFile(String):File
fix committed. The canonical name is used in model construction and I worry how the removal of that would damage the views in AJDT. Instead I've done the other thing - I made it recognize zips/jars correctly, rather than just relying on suffix. A build should be available shortly containing the fix
fix is now available in the latest dev builds.
closing as fix available.
Thanks Andy. I'll give it a go.
I've tried this out. No problems so far, thanks for the fix.
