Hi, that clearly explains what we are seeing. Elasticsearch and Apache Lucene/Solr are compiled with "-source 1.8 -target 1.8" and use the compact profile settings (Lucene Core with compact1, the rest with compact3, same for Elasticsearch).
This works everywhere, except for the javax crypto packages, because those are missing in the ct.properties file, that is used for source/target 1.8. Your explanation is very good, now I understand the problem! Thanks! FYI, this also explains why we did not see a compile failure about the java.xml.bind issue (see previous mails)! This only failed at runtime, because with Jigsaw, the java.xml.bind is not exposed by the root modules. But while compiling it seems to see all those classes, as its compiled against source/target 8 where the module system is ignored. So there is also room for improvement! Alan? So many thanks for this explanation! Uwe > -----Original Message----- > From: Jan Lahoda [mailto:jan.lah...@oracle.com] > Sent: Thursday, May 19, 2016 12:34 PM > To: Uwe Schindler <uschind...@apache.org>; 'Alan Bateman' > <alan.bate...@oracle.com>; jigsaw-dev@openjdk.java.net > Subject: Re: Compact profiles broken? > > This appears to be a bug in the current profiles handling in javac - > currently (without "-release X"), javac uses "ct.properties" to > determine the profile of a class. This file contains mapping from > package to extra metadata, esp. profile. And this file does not contain > mapping for javax.crypto, so javac thinks it belongs to the default profile. > > I guess this is because ct.properties only contains mapping for packages > from rt.jar, and javax.crypto was not part of rt.jar (was in jce.jar). > > It would be relatively easy to use modules to detect profiles, but there > is a problem with "-source 8 -profile compactX", as with -source 8, > javac does not keep information about modules, and so cannot do > module-based checks. So I guess we may need to regenerate ct.properties. > > Jan > > On 19.5.2016 09:10, Uwe Schindler wrote: > > Hi Alan, > > > > Interestingly, compiling large amounts of code with the Java SE8 option for > "compact1" or "compact3" works successfully. It is just this class/package > failing. How can that be? The issue is not visible to the outside (requires > login). > > > > 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 Alan Bateman > >> Sent: Thursday, May 19, 2016 8:55 AM > >> To: Ryan Ernst <r...@iernst.net>; jigsaw-dev@openjdk.java.net > >> Subject: Re: Compact profiles broken? > >> > >> On 19/05/2016 06:49, Alan Bateman wrote: > >>> : > >>> > >>> In the mean-time then this should work: > >>> > >>> java -release 8 -profile compact3 ... > >>> > >>> or specify -limitmods, as in: > >>> > >>> java -limitmods java.compact3 ... > >>> > >> Oops, I meant `javac` here of course (not `java`). > >> > >> -Alan > >
