As I've discussed in prior messages to platform-dev@, I'm
working on prototyping a proposed new ejc feature, to
surface an option in the IDE's Java compiler preferences,
allowing setting JavaCore.CORE_CIRCULAR_CLASSPATH,
and adding an IGNORE value to it's range (in addition to
ERROR and WARN), with the ultimate purpose of allowing
building systems that intentionally leverage
mutually-recursive modules (where I use module in
the classic sense, not the JDK's Module subsystem since
9).
As I've also promised, I'll be creating a feature bug
that explains the background, rationale, and proposed code
changes, hopefully by this Friday. That said, prior to
doing so, I feel it's essential for me to empirically
verify that this mod works end-to-end as I intend, and,
for example, doesn't spawn a class-loading or other
runtime hornet's nest (that's not straightforwardly
avoided|addressed).
To this verification end, I'm trying to run a test
harness that
- selects the IGNORE option,
- builds 2 (test) subject projects that
are mutually-dependent,
- assuming that the subject projects successfully build,
launches the main (entry-point) project (which triggers
loading the second one, etc), and
- assuming no hornets appear, verifies that at least a
minimal circular classpath case is correctly handled,
end-to-end.
I've spent quite a bit of time reading eclipse docs,
how-tos, the Eclipse Plugins bible (3rd ed), and
browsed a fair amount of JDT code, trying to figure out
how to get the test to work, and at this point, my pick is
bent. I could really use a hint how to proceed.
To set context, the test project, and both subject
projects, all reside in the jdt-master workspace (btw, is
there a vernacular shorthand for this workspace?). My
first attempt to get the test to work was simply to either
run or debug it as a Java app. It fails with the
backtrace
Exception
in thread "main" java.lang.SecurityException: class
"org.eclipse.core.runtime.IStatus"'s signer
information does not match signer information of other
classes in the same package
at
java.lang.ClassLoader.checkCerts(ClassLoader.java:898)
at
java.lang.ClassLoader.preDefineClass(ClassLoader.java:668)
at
java.lang.ClassLoader.defineClass(ClassLoader.java:761)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at
java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
at
java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at
java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at
java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at
java.security.AccessController.doPrivileged(Native
Method)
at
java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at
java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at
java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at
net.ess.jcore.CompilerRunner.configureCompiler(CompilerRunner.java:47)
at
net.ess.jcore.CompilerRunner.doCompilation(CompilerRunner.java:42)
at
net.ess.jcore.CompilerRunner.main(CompilerRunner.java:37)
Just prior to throwing the SecurityException, the JVM's
classpath is
C:\Users\rsteiger\.p2\pool\plugins\org.eclipse.osgi_3.15.0.v20190830-1434.jar
C:\Users\rsteiger\.p2\pool\plugins\org.eclipse.osgi.compatibility.state_1.1.600.v20190814-1451.jar
C:\Users\rsteiger\.p2\pool\plugins\org.eclipse.equinox.common_3.10.500.v20190815-1535.jar
T:\eclipse\SDK\jdt-master\git\eclipse.platform.runtime\bundles\org.eclipse.core.jobs\bin
C:\Users\rsteiger\.p2\pool\plugins\org.eclipse.equinox.registry_3.8.500.v20190714-1850.jar
C:\Users\rsteiger\.p2\pool\plugins\org.eclipse.equinox.preferences_3.7.500.v20190815-1535.jar
C:\Users\rsteiger\.p2\pool\plugins\javax.xml_1.3.4.v201005080400.jar
T:\eclipse\SDK\jdt-master\git\eclipse.platform.runtime\bundles\org.eclipse.core.contenttype\bin
C:\Users\rsteiger\.p2\pool\plugins\org.eclipse.equinox.app_1.4.300.v20190815-1535.jar
T:\eclipse\SDK\jdt-master\git\eclipse.platform.runtime\bundles\org.eclipse.core.runtime\bin
T:\eclipse\SDK\jdt-master\git\eclipse.jdt.core\org.eclipse.jdt.core\antbin
T:\eclipse\SDK\jdt-master\git\eclipse.jdt.core\org.eclipse.jdt.core\bin
T:\eclipse\SDK\jdt-master\git\eclipse.platform.debug\org.eclipse.core.variables\bin
C:\Users\rsteiger\.p2\pool\plugins\org.apache.ant_1.10.5.v20190526-1402\lib\ant.jar
C:\Users\rsteiger\.p2\pool\plugins\org.apache.ant_1.10.5.v20190526-1402\lib\ant-launcher.jar
T:\eclipse\SDK\jdt-master\git\eclipse.platform\ant\org.eclipse.ant.core\src_ant_bin
T:\eclipse\SDK\jdt-master\git\eclipse.platform\ant\org.eclipse.ant.core\bin
T:\eclipse\SDK\jdt-master\git\eclipse.platform.runtime\bundles\org.eclipse.core.expressions\bin
T:\eclipse\SDK\jdt-master\git\eclipse.platform.resources\bundles\org.eclipse.core.filesystem\bin
T:\eclipse\SDK\jdt-master\git\eclipse.platform.resources\bundles\org.eclipse.core.resources\bin
T:\eclipse\SDK\jdt-master\git\eclipse.platform.text\org.eclipse.text\bin
T:\eclipse\SDK\jdt-master\git\eclipse.platform.ui\bundles\org.eclipse.core.commands\bin
C:\Users\rsteiger\.p2\pool\plugins\com.ibm.icu_64.2.0.v20190507-1337.jar
T:\eclipse\SDK\jdt-master\git\eclipse.platform.team\bundles\org.eclipse.team.core\bin
T:\eclipse\SDK\jdt-master\git\eclipse.platform.team\bundles\org.eclipse.compare.core\bin
T:\eclipse\SDK\jdt-master\git\eclipse.jdt.core\org.eclipse.jdt.compiler.apt\bin
T:\eclipse\SDK\jdt-master\git\eclipse.jdt.core\org.eclipse.jdt.compiler.apt\lib\java10api.jar
T:\eclipse\SDK\jdt-master\git\eclipse.jdt.core\org.eclipse.jdt.compiler.tool\bin
T:\eclipse\SDK\jdt-master\git\eclipse.jdt.core\org.eclipse.jdt.compiler.tool\lib\java10api.jar
My understanding is that the launchConfiguration that's
being generated and applied is erroneous: as can be seen,
the classpath includes references to plugin jars in my
base eclipse installation (paths starting with C:\Users\rsteiger\.p2\pool\plugins\),
and not from the just-built jdt-master workspace (paths
starting with T:\eclipse\SDK\jdt-master\git\). I've
tried several approaches to fix this:
- made the test project into a plugin (not sure I didn't
goof this up, since am a plugin-noob);
- discovering that the project's Plug-in
Dependencies is a read-only classpath container
containing the above incorrect jars, tried removing <classpathentry
kind="con"
path="org.eclipse.pde.core.requiredPlugins"/>
from the project's .classpath, then adding kind="lib"
entries for (what I thought are) the correct jars;
- revisiting various references describing care and
feeding of launchConfigs, finding nothing covering how
to configure configs from the jdt workspace UI, just how
to do so programmatically (which is of course totally
useless in this context); and
- gnashing my teeth and swearing.
None of these approaches have helped.
I turn to y'all to suggest a viable approach.
Thanks in advance,
-rjs
_______________________________________________