javac8 with jdk7

[Jonathan Gibbons]

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