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