javac8 with jdk7
cushon at google.com
Tue Mar 25 23:10:01 UTC 2014
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
- 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
On Tue, Mar 25, 2014 at 3:51 PM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:
> Well, you've jumped all the way to -Xbootclasspath/p:. You jumped over
> -bootclasspath alias -Xbootclasspath which are more likely candidates for
> what it seems you are trying to do.
> If you want to set the platform libraries for your compilation,
> -bootclasspath is the way to go. And, in case it is not obvious, note
> that -bootclasspath, -Xbootclasspath and its variants are all options to
> javac itself, and not to the underlying JVM.
> -- Jon
> On 03/25/2014 03:35 PM, Martin Buchholz wrote:
> 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:
>> 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?
>> 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...
More information about the compiler-dev