Re: Java 9 build 118 is hiding some documented & public classes from unnamed module

[Robert Muir]

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: Compact profiles broken?

[Uwe Schindler]

Hi,

> > $ javac -source 8 -target 8 Test.java
> > warning: [options] bootstrap class path not set in conjunction with -source
> 1.8
> > 1 warning
> >
> So the question is how should javac behave with -source/-target when
> -bootclasspath is not specified. This has always been a problematic
> usage because it means javac compiling for the older edition of the Java
> Language but with the APIs for the runtime that javac is running on. The
> warning was added in JDK 7 to try to bring attention to the problematic
> usage. I'm not sure if anything should change now to align it with the
> policy for root modules. This may be something that Jon can comment on.
> The right thing is of course to add -bootclasspath or just replace the
> usage with `javac -release 8`.

I agree, that's already done in Lucene since yesterday:
https://issues.apache.org/jira/browse/LUCENE-7292

With that -release option, it of course does not fail, because it uses older 
ct.sym. The problem is now that you get no "warning" that the compilation may 
not work with Java 9. I would have expected to get a warning by javac where it 
says: "java.xml.bind" won't work by default in Java 9. Of course that's another 
discussion about pros and cons.

Here is one problem, I figured out about "-release":

Lot's of tools like Maven or Gradle make it really hard to pass "-release 8", 
because those tools have automatisms to automatically pass "source/target" to 
the javac compiler and you cannot do anything against that. Lucene/Solr is 
fine, because it uses Ant - but Elasticsearch has a hard time with Gradle: 
Gradle detects the Java version and passes the targeted release version as 
"1.8" automatically. If you add "-release 8", it fails because of incompatible 
command line arguments.

In addition, most tools still use "1.8" for everything before 9. So if you make 
it pass "-release" using the build systems's variables, it would pass "1.8". 
Unfortunately, it only accepts "-release 8", not "-release 1.8". I'd suggest to 
add support for old version numbers in the same way like source/target accepts 
both "1.8" and "8".

My proposal would be: If you start javac with "-source 1.8 -target 1.8" and 
don't pass a bootclasspath, it should switch to "-release 8" for convenience. 
What do you think? Alternatively allow source and target when passing release 
if it's not incompatible.

Uwe

Re: 8152650: ModuleFinder.compose should accept varargs

[Chris Hegarty]

> On 21 May 2016, at 00:13, Mandy Chung  wrote:
> 
> 
>> On May 20, 2016, at 1:57 PM, Alan Bateman  wrote:
>> 
>> 
>> There are several patches that didn't go in with the last update, the change 
>> to ModuleFinder.compose to use varargs was one of them. The other part to 
>> this is removing the empty() method as it is redundant. The changes are 
>> straight-forward:
>> http://cr.openjdk.java.net/~alanb/8152650/webrev/
> 
> This looks good to me.

+1

-Chris.