javac8 with jdk7

[Jonathan Gibbons]

On 03/25/2014 06:45 PM, Joseph Darcy wrote:
> 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.


I agree, if you want a Java SE 8 compiler.    But the underlying 
question is, do we want to support javac 8 as an implementation of the 
7-version of the 199 and 269 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.
>

I agree that being able to use new language features sooner is an 
admirable goal. But there will always be competing pragmatic goals, not 
least the bootstrapping requirement. So we should always be open to 
using new features less if it satisfies more of the overall set of goals 
for the product.

> -Joe