javac8 with jdk7

[Liam Miller-Cushon]

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


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:
>>
>>  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/f0db431f/attachment.html>