<div dir="ltr">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.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 25, 2014 at 3:02 PM, Jonathan Gibbons <span dir="ltr"><<a href="mailto:jonathan.gibbons@oracle.com" target="_blank">jonathan.gibbons@oracle.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
    <div>On 03/25/2014 02:04 PM, Liam
      Miller-Cushon wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr"><span>
          <p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="vertical-align:baseline;font-size:15px;white-space:pre-wrap;background-color:transparent;font-family:Arial">Hi,</span></p>
          <br>
          <span style="vertical-align:baseline;font-size:15px;white-space:pre-wrap;background-color:transparent;font-family:Arial"></span>
          <p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt">
            <span style="vertical-align:baseline;font-size:15px;white-space:pre-wrap;background-color:transparent;font-family:Arial">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.)</span></p>
          <br>
          <span style="vertical-align:baseline;font-size:15px;white-space:pre-wrap;background-color:transparent;font-family:Arial"></span>
          <p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt">
            <span style="vertical-align:baseline;font-size:15px;white-space:pre-wrap;background-color:transparent;font-family:Arial">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.</span></p>
          <br>
          <span style="vertical-align:baseline;font-size:15px;white-space:pre-wrap;background-color:transparent;font-family:Arial"></span>
          <p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt">
            <span style="vertical-align:baseline;font-size:15px;white-space:pre-wrap;background-color:transparent;font-family:Arial">Any
              thoughts on whether this would be worthwhile?</span></p>
          <br>
          <span style="vertical-align:baseline;font-size:15px;white-space:pre-wrap;background-color:transparent;font-family:Arial"></span>
          <p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt">
            <span style="vertical-align:baseline;font-size:15px;white-space:pre-wrap;background-color:transparent;font-family:Arial">Thanks,</span></p>
          <span style="vertical-align:baseline;font-size:15px;white-space:pre-wrap;background-color:transparent;font-family:Arial">Liam</span></span><br>
      </div>
    </blockquote>
    <br></div></div>
    Liam,<br>
    <br>
    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.<br>
    <br>
    I can't quite untangle your second sentence (beginning
    "Currently...) so it would help if you could explain your perceived
    issues a bit more.<br>
    <br>
    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).<br>
    <br>
    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.<br>
    <br>
    -- Jon<br>
    <br>
  </div>

</blockquote></div><br></div>