If I understand the referenced issue [1] correctly (which I'm not so sure ...),
the classloader hickups with ClassNotFoundException when the service provider
offers methods with not declared parameters/return argument, i.e. which were
not mentioned in the module-info.
I think, opposed (?) to Tomcat, we have a fixed set of dependencies and aren't
that dynamic extendable by user code.
So before we release, we should test various constellations with and without
our optional dependencies ... but maybe everything will be mandatory anyways ;)
Andi
[1] https://bugs.openjdk.java.net/browse/JDK-8255854
On 05.11.20 16:01, Dave Fisher wrote:
From the Tomcat Dev List ...
Sent from my iPhone
Begin forwarded message:
From: Mark Thomas <[email protected]>
Date: November 5, 2020 at 4:57:58 AM PST
To: Tomcat Developers List <[email protected]>
Subject: Working around a JRE bug
Reply-To: "Tomcat Developers List" <[email protected]>
All,
The summary:
- The JVM spec states that the ModulePackages attribute in
module-info.class DOES NOT have to list ALL packages in the module
- bnd is consistent with the JVM spec and only lists the packages that
are required to be listed
- the JRE uses a broken class loader optimisation that assumes that
ModulePackages DOES list ALL packages present in the module
When applications try and use our JARs with bnd provided module-info
CNFE occur because the JRE can't find the module for some classes.
For a fuller description of the issue see:
https://bugs.openjdk.java.net/browse/JDK-8255854
This is likely the cause of several currently open bugs reports of CNFE
when using modules.
Possible solutions:
1. OpenJDK accepts the class loader optimisation is flawed and reverts
it.
Given the reaction so far to the reported bug this looks unlikely.
Even if this were to happen, class loading performance would be
impacted and it is going to take a long time before all the broken
JREs have been updated.
2. The bnd project updates bnd to implement what amounts to an
undocumented requirement that the ModulePackages attribute lists all
packages in the module.
This is probably the cleanest solution but depends on the goodwill of
the bnd project who would be well within their rights to reject it as
invalid based on the JVM spec. I haven't yet approached the bnd
project. A fix along these lines might be ready for the next release
round but is unlikely to be ready for this one.
3. We drop all the JPMS meta-data until we have a solution.
I'm not sure of the consequences for users wanting to use Tomcat JARs
in a JPMS environment.
4. We "patch" module-info after bnd has generated it via:
- custom code (BCEL probably helps)
- jar (if using Java 9+ jar rebuilds the module-info.class file)
5. We add "unnecessary" @aQute.bnd.annotation.jpms.Open annotations to
packages so bnd includes them in module-info.
It might be hard to remove these at a later date if folks start to
depend on them.
I am currently thinking along these lines:
- Add @aQute.bnd.annotation.jpms.Open where necessary to fix this.
- Document clearly in the Javadoc, change log, the release announcement
and the RELEASE NOTES that this is a temporary workaround that will be
removed as soon as a better fix is available.
- Ask the bnd project to make a change to list all packages in a module
in the ModulePackages attribute.
Thoughts?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
