javac8 with jdk7

[Jonathan Gibbons]

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