[PATCH]: javac N with jdk (N-1)

[Liam Miller-Cushon]

Hello,

> I'd like to see a crisper description of what the intended behavior is
running the javac from JDK (N+1) on top JDK N.

I'll try to make my suggestion more precise: javac N should provide an
implementation of version N-1 of JSRs 199 and 269 that works with JDK N-1.
For example: the absence of SourceVersion.RELEASE_8 shouldn't prevent javac
8 from compiling java 7 code and using java 7-compatible annotation
processors while running on JDK 7 .

The changes I'm suggesting would also allow javac N to perform command-line
batch compilations of java N while running on JDK N-1, assuming those
compilations didn't involve java N annotation processors. I'm not
suggesting that javac N should somehow implement version N of JSRs 199 and
269 in a way that works with JDK N-1. (I realize that isn't possible, given
the way the updates are structured.)

> In particular, what is the expected interaction with the SourceVersion
latest and latestSupported methods.

When using javac N with JDK N-1, the JDK N-1 SourceVersion would still be
used, so latest and latestSupported would both return RELEASE_(N-1). That
seems like the desired behaviour: RELEASE_(N-1) is the latest version that
can be modeled by version N-1 of the JSR 269 API, and also the latest
version that is supported on JDK N-1.

On Fri, Apr 4, 2014 at 3:32 PM, Joseph Darcy <joe.darcy at oracle.com> wrote:

>  Hello,
>
> A few general notes here, you can look at the maintenance reviews of JSRs
> 199 and 269 to get an idea of the new-in-8 API that javac might be using:
>
>     https://jcp.org/aboutJava/communityprocess/mrel/jsr199/index.html
>     https://jcp.org/aboutJava/communityprocess/mrel/jsr269/index2.html
>
> At the start of JDK (N+1), a new SourceVersion constant for (N+1) is
> added. Later in the release, changes to the language model can be expected
> to accommodate any language changes in the release as well as general
> improvements to the API.
>
> I'd like to see a crisper description of what the intended behavior is
> running the javac from JDK (N+1) on top JDK N. In particular, what is the
> expected interaction with the SourceVersion latest and latestSupported
> methods.
>
> Note that in JDK 9 preparatory work has begun to implement
>
>     JEP 182: Policy for Retiring javac -source and -target Options
>     http://openjdk.java.net/jeps/182
>
> In other words, the javac in JDK 9 will only support -source / -target
> values of 6/1.6, 7/1.8, 8/1.8, and 9/1.9. If this javac were run on top of
> JDK 8, it would *not* support -source/-target 5/1.5 and earlier.
>
> Cheers,
>
> -Joe
>
>
> On 4/4/2014 12:22 PM, Liam Miller-Cushon wrote:
>
> Jan,
>
>  Thanks for trying the patch. I will update it to handle Modifier.DEFAULT
> and TypeKind.INTERSECTION. I was testing primarily with java 7 source and
> java 7 annotations processors, so the issue you discovered didn't come up.
>
>  In the case of the -Xprint crash, PrintingProcessor will need to be
> updated to support SourceVersion.latest() instead of using RELEASE_8
> explicitly.
>
>  I agree that an automatic way to find these problems would be nice.
> Perhaps some subset of the test coverage could be run without the
> -Xbootclasspath hack, but that might get tricky in areas where javac's
> behaviour will have to regress on jre n-1.
>
>
> On Fri, Apr 4, 2014 at 8:40 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:
>
>> Liam,
>>
>> I tried the patch, using this sample code:
>> ---
>> interface ID {
>>     public default void test() {}
>> }
>> ---
>>
>> Running (using JDK 7):
>> $ java -jar javac.jar -Xprint ID.java
>> leads to the attached exception1.txt.
>>
>> Using the attached ScanningProcessor.java, running:
>> $ java -jar javac.jar -processorpath <path> -processor ScanningProcessor
>> ID.java
>>
>> leads to the attached exception2.txt. I suspect there may be other
>> similar problems around TypeKind.INTERSECTION - I wonder if there is an
>> automated way to look for problems like this?
>>
>> Jan
>>
>>
>> On 04/03/2014 07:40 PM, Liam Miller-Cushon wrote:
>>
>>>  On Wed, Mar 26, 2014 at 1:34 AM, Joel Borggrén-Franck
>>>   <joel.franck at oracle.com <mailto:joel.franck at oracle.com>> wrote:
>>>
>>>     having javac run with JRE n-1 in a degraded state would be a nice
>>>     contribution if the patches aren't too intrusive.
>>>
>>>
>>> It sounded like that was the general consensus, so I put together a
>>> patch to allow javac 9 to run on jre 7 in a degraded state. That means:
>>>
>>> - warnings aren't generated for annotation processors that support
>>> RELEASE_7 when the source level is 8 or 9 (because the RELEASE_8 and
>>> RELEASE_9 constants aren't available)
>>>
>>> - the native headers feature is disabled (because
>>> StandardLocations.NATIVE_HEADER_OUTPUT isn't available)
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140408/fa50532c/attachment.html>