Limit ValidateClassFilesTest to scan only JARs referenced from modules #4775
Conversation
With the addition of jakarta ee 10 API jars it was found, that there is an implicit assumption, that all JARs not referenced by modules have to be JDK 8 compatible. In the case of jakarta ee 10 this is an invalid assumption as it explicitly does not support JDK 8. The module that introduces the binaries correctly declares a JDK 11 dependeny, but at runtime the module <-> binary association is lost. To prevent false positives, the test must be limited to JARs, that are directly referenced from modules.
|
@neilcsmith-net @jtulach you two worked previously on this test. This change is triggered by the commit validation errors reported in #4692 (Commit da98cbd). From my observation the problem is, that the test assumes, that all JARs, that may need a java version higher than 8 are referenced by modules (either as module itself or as dependency). This is not true for bundled jar files. In the referenced PR the bundled library is Jakarta EE 10, which has a minimum baseline of JDK 11. |
There was a problem hiding this comment.
I think this is OK as a quick fix. I acknowledge that my addition was also a quick fix! Ideally we should probably add bundled JARs along with the result of module.getAllJars() but I wasn't sure of the best way to access this information in the test (and didn't need it to get it to pass then!)
|
restarting tests since master is green again. |
apache#4775) With the addition of jakarta ee 10 API jars it was found, that there is an implicit assumption, that all JARs not referenced by modules have to be JDK 8 compatible. In the case of jakarta ee 10 this is an invalid assumption as it explicitly does not support JDK 8. The module that introduces the binaries correctly declares a JDK 11 dependeny, but at runtime the module <-> binary association is lost. To prevent false positives, the test must be limited to JARs, that are directly referenced from modules.
With the addition of jakarta ee 10 API jars it was found, that there is an implicit assumption, that all JARs not referenced by modules have to be JDK 8 compatible. In the case of jakarta ee 10 this is an invalid assumption as it explicitly does not support JDK 8. The module that introduces the binaries correctly declares a JDK 11 dependeny, but at runtime the module <-> binary association is lost.
To prevent false positives, the test must be limited to JARs, that are directly referenced from modules.