Woot! The great folks at bnd have fixed this. It means depending on a snapshot but compared to the disruption of the alternatives I think that is acceptable for the short term.
The issue with depending on a snapshot is reproducibility of builds. The simplest option (and infra seem OK with it) is to put a copy in my home dir on home.a.o. Any objections? Better ideas? Mark On 05/11/2020 12:57, Mark Thomas wrote: > 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: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
