javac8 with jdk7

[Martin Buchholz]

I think we understand each other now.  And it seems you would be willing to
accept a change that would allow jdk8 to work within a jre7 as a normal
application with possibly degraded functionality - e.g. when acting as a
"better javac7"


On Tue, Mar 25, 2014 at 5:08 PM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> On 03/25/2014 04:10 PM, Liam Miller-Cushon wrote:
>
>> Hi Jon,
>>
>> I was interested in running javac 8 on the JRE 7 to compile java 7 code.
>> In that case my understanding is that you do need to set the JVM's
>> bootclasspath, since javac itself depends on classes from the latest JRE.
>>
>> A more concrete question is whether it's desirable for javac to depend on
>> the latest versions of platform libraries when there are alternatives. For
>> example:
>> - the filemanager implementation could use the FileManager.Location
>> interface instead of depending on specific StandardLocation values
>> - Source.toSourceVersion(...) could return only the SourceVersion values
>> that are present in the current platform, instead of requiring that the
>> latest version is available
>>
>> Liam
>>
>
> OK, I think I finally see the issue that you may be addressing.
>
> I think you're saying that javac 8 depends on some enum constants in the
> JDK 8 rt.jar. To be specific, it depends on javax.tools.StandardLocation.NATIVE_HEADER_OUTPUT
> and javax.lang.model.SourceVersion.RELEASE_8.
>
> So yes, at some level, this is a bug.  For what it's worth, we don't see
> this problem when bootstrapping JDK because the classes in question are
> part of the "interim" version of javac used for the bootstrap, and yes, I
> guess we do use -Xbootclasspath/p: to override the classes in the bootstrap
> JDK, so now I maybe understand Martin's comment as well.
>
> With respect to your suggestions, yes I can see that it would be
> technically feasible to dynamically determine is SourceVersion.RELEASE_8
> was defined and to avoid trying to return it. But NATIVE_HEADER_OUTPUT is a
> bigger problem.  We *do* expect JDK 8 clients to use the StandardLocation
> values, and so javac must support them. But we could simply disable the
> native header feature entirely if we're running on top of JDK 7, meaning we
> would dynamically determine if NATIVE_HEADER_OUTPUT was defined and deal
> with it if it was not.
>
> -- Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140325/a57841e5/attachment-0001.html>