Re: Java 9 build 118 is hiding some documented & public classes from unnamed module
Yes, sorry to be clear, DatatypeConverter base64 stuff is the same class/methods I am seeing. On Sun, May 22, 2016 at 3:36 PM, Alan Bateman wrote: > > > On 21/05/2016 13:51, Robert Muir wrote: >> >> : >> Just a little followup: It seems most code impacted by this change is >> just using jaxb's base64 class. We've seen it not just with Solr but >> with cloud libraries like AWS SDK and so on. >> >> I'm not really suggesting anything here but just mentioning it as a >> possible "easy win" from usages I have seen. > > This is useful - thanks! We've also had a few tests in the JDK test suite > that needlessly used javax.xml.bind.DatatypeConverter because it defines > methods such as printHexBinary. > > -Alan
Re: Java 9 build 118 is hiding some documented & public classes from unnamed module
On 21/05/2016 13:51, Robert Muir wrote: : Just a little followup: It seems most code impacted by this change is just using jaxb's base64 class. We've seen it not just with Solr but with cloud libraries like AWS SDK and so on. I'm not really suggesting anything here but just mentioning it as a possible "easy win" from usages I have seen. This is useful - thanks! We've also had a few tests in the JDK test suite that needlessly used javax.xml.bind.DatatypeConverter because it defines methods such as printHexBinary. -Alan
Re: Java 9 build 118 is hiding some documented & public classes from unnamed module
On Mon, May 16, 2016 at 10:45 AM, Alan Bateman wrote: > > As to what is going on? The java.corba and the EE modules are no longer > resolved by default when compiling code in the unnamed module or where the > main class is loaded from class path. This means the types in these modules > are not visible. Nothing has been removed and if you run with `-addmods > java.se.ee` then each of the Java EE modules will be resolved as they were > previously. We have updated text for JEP 261 that describes this in more > detail, along with the rational. We will likely assess the impact of this > change later in JDK 9 but for now, there is easy workaround for those that > depend on these components being in the JDK. > Just a little followup: It seems most code impacted by this change is just using jaxb's base64 class. We've seen it not just with Solr but with cloud libraries like AWS SDK and so on. I'm not really suggesting anything here but just mentioning it as a possible "easy win" from usages I have seen.
Re: Java 9 build 118 is hiding some documented & public classes from unnamed module
On 16/05/2016 16:19, Uwe Schindler wrote: Thanks Alan, so this means we should better remove the references to the mentioned class from the Apache Solr code if not needed (I don't think we need the Java EE features here, it might be an oversight). I just wonder why Javac succeeded in our case to build. I have to dig. For now I added "-addmods java.se.ee" to our build server's testing Java configuration, to be able to test build 118. Good. Is it planned to have those classes disabled for pre-Java-9 apps by default in Java 9? Would't it be better for standard unnamed classpath apps to "fall back" in a backwards compatible way? Once JEP 261 is update then I hope the rational will be clearer. It's not really a problem to resolve java.xml.bind and java.activation by default, the others are problems though. In addition, the Javadocs don't say anything about which modules are visible by default. I think this should be added, too. I think TBD, partly because this is really JDK policy. -Alan
RE: Java 9 build 118 is hiding some documented & public classes from unnamed module
Thanks Alan, so this means we should better remove the references to the mentioned class from the Apache Solr code if not needed (I don't think we need the Java EE features here, it might be an oversight). I just wonder why Javac succeeded in our case to build. I have to dig. For now I added "-addmods java.se.ee" to our build server's testing Java configuration, to be able to test build 118. Is it planned to have those classes disabled for pre-Java-9 apps by default in Java 9? Would't it be better for standard unnamed classpath apps to "fall back" in a backwards compatible way? In addition, the Javadocs don't say anything about which modules are visible by default. I think this should be added, too. Uwe - Uwe Schindler uschind...@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -Original Message- > From: Alan Bateman [mailto:alan.bate...@oracle.com] > Sent: Monday, May 16, 2016 4:45 PM > To: Uwe Schindler ; jigsaw-dev@openjdk.java.net > Cc: rory.odonn...@oracle.com; d...@lucene.apache.org > Subject: Re: Java 9 build 118 is hiding some documented & public classes from > unnamed module > > On 16/05/2016 15:28, Uwe Schindler wrote: > > : > > > > This is not the only class that’s missing at runtime, there are more: I do > > not > have the complete list, but our checks using the forbiddenapis > Ant/Maven/Gradle plugin fails to load classes around JAXB/XML > (javax.xml.bind.*, javax.jws.*) and CORBA (org.omg.CORBA.*), but also > "javax.activation.ActivationDataFlavor". But there may be more packages > missing. > > > jdk-9+118 is the first JDK 9 build to have the policy for root modules > that is described in JEP 261. This has been changed in the Jigsaw EA > builds some time and only merged into the main line for build 118. I > hope to send mail to jdk9-dev shortly about this - we know it will be a > surprise to some. > > As to what is going on? The java.corba and the EE modules are no longer > resolved by default when compiling code in the unnamed module or where > the main class is loaded from class path. This means the types in these > modules are not visible. Nothing has been removed and if you run with > `-addmods java.se.ee` then each of the Java EE modules will be resolved > as they were previously. We have updated text for JEP 261 that describes > this in more detail, along with the rational. We will likely assess the > impact of this change later in JDK 9 but for now, there is easy > workaround for those that depend on these components being in the JDK. > > -Alan > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Java 9 build 118 is hiding some documented & public classes from unnamed module
On 16/05/2016 15:28, Uwe Schindler wrote: : This is not the only class that’s missing at runtime, there are more: I do not have the complete list, but our checks using the forbiddenapis Ant/Maven/Gradle plugin fails to load classes around JAXB/XML (javax.xml.bind.*, javax.jws.*) and CORBA (org.omg.CORBA.*), but also "javax.activation.ActivationDataFlavor". But there may be more packages missing. jdk-9+118 is the first JDK 9 build to have the policy for root modules that is described in JEP 261. This has been changed in the Jigsaw EA builds some time and only merged into the main line for build 118. I hope to send mail to jdk9-dev shortly about this - we know it will be a surprise to some. As to what is going on? The java.corba and the EE modules are no longer resolved by default when compiling code in the unnamed module or where the main class is loaded from class path. This means the types in these modules are not visible. Nothing has been removed and if you run with `-addmods java.se.ee` then each of the Java EE modules will be resolved as they were previously. We have updated text for JEP 261 that describes this in more detail, along with the rational. We will likely assess the impact of this change later in JDK 9 but for now, there is easy workaround for those that depend on these components being in the JDK. -Alan
Java 9 build 118 is hiding some documented & public classes from unnamed module
Hi,
the Lucene team installed JDK9 build 118 today and this failed our build during
some checks. The reason is that some classes are missing from the unnamed
module (standard Java 8 classpath-only application). Just try this test:
public class Test {
public static void main(String... args) throws Exception {
Class.forName("javax.xml.bind.DatatypeConverter");
}
}
$ javac Test.java
$ java Test
Exception in thread "main" java.lang.ClassNotFoundException:
javax.xml.bind.DatatypeConverter
at
jdk.internal.loader.BuiltinClassLoader.loadClass(java.base@9-ea/BuiltinClassLoader.java:366)
at
jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base@9-ea/ClassLoaders.java:184)
at java.lang.ClassLoader.loadClass(java.base@9-ea/ClassLoader.java:419)
at java.lang.Class.forName0(java.base@9-ea/Native Method)
at java.lang.Class.forName(java.base@9-ea/Class.java:294)
at Test.main(Test.java:3)
$ java -version
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+118)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+118, mixed mode)
This works with build 116 and Java 8.
This is not the only class that’s missing at runtime, there are more: I do not
have the complete list, but our checks using the forbiddenapis Ant/Maven/Gradle
plugin fails to load classes around JAXB/XML (javax.xml.bind.*, javax.jws.*)
and CORBA (org.omg.CORBA.*), but also "javax.activation.ActivationDataFlavor".
But there may be more packages missing.
It looks like some module exports are missing because the classes are all
listed on the JDK docs:
http://download.java.net/java/jdk9/118/docs/api/index.html
I'd suggest to add a check in the packaging that validates that all classes
also visible in the Javadocs are visible at runtime from applications not using
the module system.
Should I open bug report or can we shortcut this through the mailing list?
Greetings from the Lucene team,
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
