[PATCH]: javac[8,9] with jdk7

[Joseph Darcy]

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 
> <mailto: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>
>         <mailto: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/20140404/dd2ef268/attachment-0001.html>