javac8 with jdk7

[Martin Buchholz]

Often software is structured above the level of a process invocation.
 Imagine a jre7 with an api that included a parameter where to find a javac
implementation, that would get loaded via a URLClassLoader.  You could even
run multiple javac versions in the same java process at the same time in
separate classloaders.  Because javac is "just" another java application.
 Almost.  Another way of looking at it is that the -Xbootclasspath/p: hack
is deeply non-modular.  But I can understand if you're maintaining
the -Xbootclasspath/p: hack just to bootstrap-build the jdk itself.


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

>  On 03/25/2014 02:04 PM, Liam Miller-Cushon wrote:
>
>  Hi,
>
>  I'm curious if there's any interest in reducing javac's dependence on
> the specific JDK version it's running on. Currently javac8 works with jdk7
> only if it's on the jvm's bootclasspath, because of some changes to the
> javax classes that are also in rt.jar. (Specifically: the addition of
> StandardLocation.NATIVE_HEADER_OUTPUT and SourceVersion.RELEASE_8.)
>
>  Being able to run javacN on at least jdkN-1 would be convenient when
> working with code that invokes javac programmatically, since configuring
> the bootclasspath complicates deployment.
>
>  Any thoughts on whether this would be worthwhile?
>
>  Thanks,
> Liam
>
>
> Liam,
>
> Because of the way we bootstrap the JDK build, it is a requirement that
> javac N must be able to run on JRE N-1.
>
> I can't quite untangle your second sentence (beginning "Currently...) so
> it would help if you could explain your perceived issues a bit more.
>
> Your issues about configuring the bootclasspath may hint at your issues.
> Any time you want to compile against a different version of the libraries
> other than those native to the underlying JVM, you have to set the
> bootclasspath, at least for now.   There are ideas about a new -platform
> option which would supercede -source, -target and -bootclasspath. But that
> would only allow you to compile for earlier versions (i.e. just like the
> -source and -target options today).
>
> But I suspect you are wanting to compile for future versions. e.g.   you
> are suggesting that it should be possible to run a variant of javac 8 on
> JDK 7, such that the variant has bound within it a copy of the JRE 8
> libraries that are normally found on the JRE 8 bootclasspath.  Technically,
> that could certainly be done; I'm not sure it is generally worthwhile,
> though.  If the only issue is that "configuring the bootclasspath
> complicates deployment" then the solution should be as simple as a modified
> bundle, with the extra libraries added, and a wrapper script for javac that
> sets the bootclasspath for you, before calling the desired version of javac.
>
> -- Jon
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140325/6e84e4e7/attachment.html>