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

Liam Miller-Cushon cushon at google.com
Fri Apr 4 19:22:01 UTC 2014


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/20140404/cf61e69f/attachment.html>

More information about the compiler-dev mailing list