javac8 with jdk7

[Joseph Darcy]

Hello,

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
>>
>> 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.

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.

-Joe