javac8 with jdk7
joe.darcy at oracle.com
Wed Mar 26 01:45:11 UTC 2014
On 3/25/2014 5:08 PM, Jonathan Gibbons 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
> 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
For the purposes of running a Java compiler for JDK version N on top of
JDK version (N-1), JSRs 199 and 269, which define the javax.tools,
javax.anotation.processing, and javax.lang.model.* APIs, are usable
stand alone as well as being bundled as part of the JDK.
In other words, the right way to run a Java SE 8 compiler on top of a
JDK 7 is to have a jar file with the 199 and 269 APIs and pop that into
the right path to override the system-provided versions of those APIs.
> 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
I generally don't think it is a problem for javac in JDK N to directly
reference new-in-JDK-N javac-related APIs. On the contrary, to the
limited extent I do javac development, I would prefer if language and
platform features could be used sooner and more directly in javac than
they are now.
More information about the compiler-dev