javac8 with jdk7

[Jeremy Manson]

It seems to me that javac should either be officially Java N-1 compliant or
officially not.  Since Java N-1 compliance is a requirement for
bootstrapping (which is SOP for most compiler implementations), it makes a
certain amount of sense to have it be officially Java N-1 compliant, treat
violations of that property as bugs, and welcome appropriate patches.

Having it be mostly Java N-1 compliant, but not really, because there are
some classes that need to sneak onto the bootclasspath, is just confusing.

(Yes, I understand that people like us are the only ones this is ever
likely to bite, and that there aren't many people like us.)

(You may argue that we should just use whatever JDK came with the javac.
 However, from a selfish standpoint, we'd like to use a relatively close to
head javac, and we don't *really* want to use a relatively close to head
rest-of-the-JDK, because it is much harder to make sure that a bleeding
edge JVM works than it is to make sure that a bleeding edge javac works.
 Case in point, 8036100.)

Jeremy


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

> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140325/17eca8d6/attachment-0001.html>