On 04/07/2017 08:02, Langer, Christoph wrote:
Hi experts,
probably this was already asked or discussed here but I don't find an exact
answer for my type of issue, so I'm asking again.
I have some piece of software that we ship as a jar file and which will hence
run on a JDK 9 in the unnamed module. However, this jar file contains a package
that is also contained in our JDK image in a module that is always part of the
runtime. So, when my app wants to use one of these classes, I get a
java.lang.IllegalAccessError because the class is not exported from the runtime
module to my app. And, also if I have a class in that package which is not part
of the runtime module, I get a java.lang.NoClassDefFoundError because probably
the package is loaded from the runtime module.
As I don't want to maintain 2 copies of the same code just to have different
package names, I'm wondering if I could solve this somehow by implementing my
own class loader for the app that would first try to load these classes from
the classpath before delegating to the default application class loader. Would
that work? I also did some googling on implementing a non-delegating class
loader but to me that seems not so easy and has pitfalls.
Yes, that should work.
An alternative is to patch the module (with --patch-module) with the
additional classes in the JAR file. This assumes of course that the
contents of the JAR file are indeed a compatible superset.
Is there a good reference or even something in the JDK that I could subclass?
The trampoline code in sun.reflect.misc.MethodUtil is roughly in this
area but might be too specialized. There may be some test code that you
could use - one example is in the patch for JDK-8183503 which is
currently waiting for review on hotspot-runtime-dev [1].
-Alan.
[1]
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-July/023841.html
