Community
Participate
Working Groups
It happens that some real world libraries used in projects have crazy manifest entries. E.g. https://repo1.maven.org/maven2/org/libreoffice/jurt/6.4.3/jurt-6.4.3.jar has the following class path entry in its MANIFEST.MF: Class-Path: ridl.jar unoloader.jar ../ When this JAR is added to a project's libraries, Eclipse adds these entries to the project's class path. This seems to lead to numerous problems, e.g. rebuilds without a legitimate cause, strange results when searching for classes, etc. Unfortunately there seems to be no way to permanently discourage Eclipse to implicitly add dependencies from manifest files.
Moving to JDT.
When a jar declares its dependencies using "Class-Path:", what legitimate reasons exist, to *not* include them in the build path? Is this about the unsafe entry "../"?
Correct. The offending entry seems to be is ../. But I believe that the whole entry is there by accident.
(In reply to Alexander Veit from comment #3) > Correct. The offending entry seems to be is ../. > > But I believe that the whole entry is there by accident. Is there still concern that you would like to follow up on?
Jay, I'm not sure if I understand you correctly. The problem is that third-party libraries that are needed in projects cause class path problems in Eclipse. I suspect that e.g. frequently occurring rebuilds (which take 6 minutes on my machine to complete) may be at least partly related to this issue. Unfortunately we have no influence on what third-party vendors package into their JARs. And apparently there is no way to prevent Eclipse from using the silly class path ../ in its class path building. For me it is an issue in Eclipse. Maybe there should be an option to ignore insecure class path entries in JAR metadata or to ignore Class-Path entries from MANIFEST.MF files in JARs altogether.
I would first check, what would javac do if it compiles a class that depends on two jars - on on the classpath given to javac and one indirectly through the first jar manifest. If that doesn't with javac, we probably can ignore that too. Nor sure if ecj is also affected here. Anyway, that crazy manifests parsing can lead to including entire unrelated directories on classpath. We had a case where root file system was entirely on classpath because of manifest pointing to ../../ directory.
Could we agree at least that using any relative paths from manifests is a problem, and that there should be some way to ignore them (may be via some new jdt compiler option)? Like "Use unsafe build path entries from manifests: allow|ignore|warning|error"? Or just ignore all "open end" directory entries like ../. etc?
*** Bug 281189 has been marked as a duplicate of this bug. ***
"Regression" from bug 198572. I assume the intention was to implement https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4212732 by adding referenced *jar* files from classpath of a jar, but that also added unintended support for adding any kind of weird entries like ../, ./.., . etc (*resolved from the actual jar directory*) to the classpath.
(In reply to Andrey Loskutov from comment #9) > "Regression" from bug 198572. > > I assume the intention was to implement > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4212732 by adding > referenced *jar* files from classpath of a jar, but that also added > unintended support for adding any kind of weird entries like ../, ./.., . > etc (*resolved from the actual jar directory*) to the classpath. Well, it seems that these crazy "../" entries are supported by javac. See https://github.com/eclipse-jdt/eclipse.jdt.core/issues/258#issuecomment-1202351141 So bug 198572 implemented it "right" *in the IDE* but parent bug 97332 didn't for the batch ecj compiler, so Eclipse IDE and Eclipse command line compilers disagree here :-)
