javac8 with jdk7

[Jonathan Gibbons]

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.

-- Jon

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
>
>         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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140325/f32e4d94/attachment.html>