split package references in OpenSAML detected by Eclipse 2019-03
Description
Environment
is related to
Activity
Ian Young April 14, 2019 at 5:26 PM
The latest maint-3 sources load into Eclipse 2019-03 without problems, so declaring this dealt with on both branches.
Ian Young April 14, 2019 at 5:10 PM
Tom's change for should have fixed this for v3, will confirm.
Ian Young April 14, 2019 at 5:07 PM
Fixed for v4 by OSJ-275.
Ian Young April 4, 2019 at 3:52 PM
Summary: xml-apis seems to date to before the adoption of the XML processing APIs into the JDK. It includes packages which are now part of the Java API in a specific module. It's no longer legal to have a package available both on the module path (including those modules included in the Java API) and also on the classpath.
Bottom line: you MUST NOT have a dependency, either directly or transitively, on xml-apis, or you will be correctly flagged with an error either by Eclipse (from 2019-03) or javac (when they get round to checking for this properly).
Ian Young April 4, 2019 at 3:45 PM
Although we only seem to have one issue like this in OpenSAML and the IdP seems to be clear, it looks like there's a variation in both java-idp-testbed and java-idp-integration-tests.
The java-idp-testbed one looks like a carry-over from the OpenSAML one, which can probably be fixed with an appropriate rebuild.
The java-idp-integration-tests issue seems to be due to the explicit inclusion of a lot of stuff related to Xerces and Xalan. I suspect the embedded comment (<!-- AFAICT, Selenium requires the Xerces/Xalan dependencies. -->) explains this but I doubt that it can really be accurate post-Java-11 world where, for example, the whole concept of endorsed processors has been abolished. Will coordinate with Tom over this part.
OpenSAML doesn't compile under Eclipse 2019-03. The reported issue is:
This appears to be because the XML APIs appear both in the Java SDK and in an external xml-apis package. Modules are hard.
There's a discussion of what seems to be this issue here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=536928
Assuming that it's the same issue as we're seeing, the conclusion appears to be that:
Eclipse is correct.
The compiler in Eclipse follows the post-Java-9 language spec (particularly around modules and split packages specifically) more closely than the Oracle compiler does.
This has been acknowledged by the Java folks: https://bugs.openjdk.java.net/browse/JDK-8215739
A fix is scheduled for Java 13 which will make the Java 13 compiler stricter too. It has not yet appeared in an EA release as of EA 14, however (2019-04-04).
This is something we need to fix if we want to be able to build under Java 13, and potentially even under Java 11 if someone back-ports that fix.