javac8 with jdk7
jonathan.gibbons at oracle.com
Wed Mar 26 01:07:56 UTC 2014
Well, it has always been the intent to be able to run javac N on JRE
N-1, albeit currently with some inelegancies. If we can do that in a
cleaner way, without disturbing the code too much, then that's probably
a good idea.
On 03/25/2014 05:36 PM, Martin Buchholz wrote:
> I think we understand each other now. And it seems you would be
> willing to accept a change that would allow jdk8 to work within a jre7
> as a normal application with possibly degraded functionality - e.g.
> when acting as a "better javac7"
> On Tue, Mar 25, 2014 at 5:08 PM, Jonathan Gibbons
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> 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
> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the compiler-dev