module/bootclass troubles with jdk9

[Martin Buchholz]

Thanks again.

jsr166 CVS is happy with jdk9 for the time being, by migrating from
compiling with -bootclasspath to -Xbootclasspath/p:

Sophisticated users who care about constraining their target runtimes will
probably engineer their own "bootclasspath", including eventually doing
whatever it takes to e.g. intersect two sets of modules from two different
JREs in the post-module world.

On Tue, Feb 3, 2015 at 1:17 PM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

>  We started 8058150 by looking at @since tags, partly with a view to
> refreshing the tags and making sure they were still up to date, and partly
> with a view to supporting -platform.
>
> But, @since paints an incomplete picture.  Simplistically, one needs to
> construct a file containing the necessary info from previous releases. But
> it is not reasonable to expect rt.jar from previous releases to be
> available when building JDK, so the current thinking is to have some sort
> of text file containing the API specification of earlier releases.
>
> The suggestion to be able to point at a JRE is a new and interesting one.
> Thanks.
>
> -- Jon
>
>
> On 02/03/2015 12:18 PM, Martin Buchholz wrote:
>
> Thanks all for the explanations.
>
> (I don't know where I got "jdk9-b34" from.  Apparently I was using
> jdk9-b48)
>
>  I read JEP 8058150 <http://openjdk.java.net/jeps/8058150> with
> interest.  I agree with the goals.  It's nice to be able to compile for a
> previous version of the platform with a single flag and without having an
> actual copy of the previous jdk available at compile time.  One idea is to
> promote javadoc tag @since to be a proper class retention annotation
> indicating when that API became available.  This would allow you to
> implement -platform N fairly cheaply, and the information would be useful
> elsewhere.
>
>  But ... there has been an increased diversity of java runtimes lately,
> and the jigsaw project will only increase that diversity.  I think it will
> also be useful to assert that a java compilation is targeting a particular
> java runtime (or the intersection of multiple such!) given as a root
> directory of an actual JRE, and have javac deduce -source -target and
> -bootclasspath from that.  There's a whole javac target constraint algebra
> behind that!  Difficult.
>
>  Also difficult is the distinction between bootmodules and extmodules.
>
> On Tue, Feb 3, 2015 at 10:30 AM, Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>>
>> On 02/03/2015 12:17 AM, Alan Bateman wrote:
>>
>>>
>>> For javac then there are other ideas to support compiling for previous
>>> releases, Jon might want to say more on this.
>>>
>>> -Alan
>>>
>>
>>  javac is currently in "interim land".  For now, javac still supports the
>> bootclasspath family of options, meaning that if you have an rt.jar you
>> want to use, you can.  If you don't specify any platform classes, the
>> default is to use the classes in the jrt: image.
>>
>> Going forward, the expectation is that javac will support the JDK 8 set
>> of javac path-related options in conjunction with -target N, N <= 8.  In
>> addition, the following JEP (currently in Draft state) will explore
>> providing a new option -platform N, which will be informally equivalent to
>> -source N -target N -bootclasspath jdkN/jre/lib/rt.jar
>> http://openjdk.java.net/jeps/8058150
>>
>> And, we are working on full support for modules in JDK 9 javac, for use
>> with -target N, N >= 9.
>>
>> -- Jon
>>
>
>
>