javac8 with jdk7

[Jan Lahoda]

On 03/26/2014 07:54 AM, Jeremy Manson wrote:
> 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.

As a note, there are enhancements to the javax.lang.model.** APIs in 8, 
notably TypeKind.INTERSECTION, Modifier.DEFAULT and related changes, 
that may need to be included in the consideration as well.

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

FWIW, at runtime, NetBeans is solving a similar problem using 
classloader magic. But the NetBeans usecase is somewhat different, as 
NetBeans wants to see a specific version of the model.

Jan

>
> (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 <mailto: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
>
>
>