You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Uwe Schindler <us...@apache.org> on 2016/05/16 14:28:15 UTC
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
uschindler@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Java 9 build 118 is hiding some documented & public classes from
unnamed module
Posted by Robert Muir <rc...@gmail.com>.
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 <Al...@oracle.com> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Java 9 build 118 is hiding some documented & public classes from
unnamed module
Posted by Alan Bateman <Al...@oracle.com>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Java 9 build 118 is hiding some documented & public classes from
unnamed module
Posted by Robert Muir <rc...@gmail.com>.
On Mon, May 16, 2016 at 10:45 AM, Alan Bateman <Al...@oracle.com> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Java 9 build 118 is hiding some documented & public classes from
unnamed module
Posted by Alan Bateman <Al...@oracle.com>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: Java 9 build 118 is hiding some documented & public classes from unnamed module
Posted by Uwe Schindler <us...@apache.org>.
Hi,
I opened https://issues.apache.org/jira/browse/SOLR-9115.
This is really a stupid thing for the SimplePostTool command line interface to use this class just to encode something with Base64 (while not requiring external dependencies), since Solr requires Java 8 minimum where java.util.Base64 is shipped with!
I think this dates back to Java 7 times...
Uwe
-----
Uwe Schindler
uschindler@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -----Original Message-----
> From: jigsaw-dev [mailto:jigsaw-dev-bounces@openjdk.java.net] On Behalf
> Of Uwe Schindler
> Sent: Monday, May 16, 2016 5:19 PM
> To: jigsaw-dev@openjdk.java.net
> Cc: rory.odonnell@oracle.com; dev@lucene.apache.org
> Subject: 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
> uschindler@apache.org
> ASF Member, Apache Lucene PMC / Committer
> Bremen, Germany
> http://lucene.apache.org/
>
> > -----Original Message-----
> > From: Alan Bateman [mailto:Alan.Bateman@oracle.com]
> > Sent: Monday, May 16, 2016 4:45 PM
> > To: Uwe Schindler <us...@apache.org>; jigsaw-
> dev@openjdk.java.net
> > Cc: rory.odonnell@oracle.com; dev@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-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: Java 9 build 118 is hiding some documented & public classes from unnamed module
Posted by Uwe Schindler <us...@apache.org>.
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
uschindler@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -----Original Message-----
> From: Alan Bateman [mailto:Alan.Bateman@oracle.com]
> Sent: Monday, May 16, 2016 4:45 PM
> To: Uwe Schindler <us...@apache.org>; jigsaw-dev@openjdk.java.net
> Cc: rory.odonnell@oracle.com; dev@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Java 9 build 118 is hiding some documented & public classes from
unnamed module
Posted by Alan Bateman <Al...@oracle.com>.
On 16/05/2016 15:28, Uwe Schindler wrote:
> :
>
> This is not the only class that\u2019s 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org