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
uschind...@apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -----Original Message-----
> From: jigsaw-dev [mailto:jigsaw-dev-boun...@openjdk.java.net] On Behalf
> Of Uwe Schindler
> Sent: Monday, May 16, 2016 5:19 PM
> To: jigsaw-...@openjdk.java.net
> Cc: rory.odonn...@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
> 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 <uschind...@apache.org>; jigsaw-
> d...@openjdk.java.net
> > Cc: rory.odonn...@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-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to