<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Well, it has always been the intent to
      be able to run javac N on JRE N-1, albeit currently with some
      inelegancies. If we can do that in a cleaner way, without
      disturbing the code too much, then that's probably a good idea.<br>
      <br>
      -- Jon<br>
      <br>
      On 03/25/2014 05:36 PM, Martin Buchholz wrote:<br>
    </div>
    <blockquote
cite="mid:CA+kOe0-8ao=QPVfSzc3m5q2EzCJwqdkAdNYZoQsPhSJVuwWR=Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">I think we understand each other now.  And it seems
        you would be willing to accept a change that would allow jdk8 to
        work within a jre7 as a normal application with possibly
        degraded functionality - e.g. when acting as a "better javac7"</div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Tue, Mar 25, 2014 at 5:08 PM,
          Jonathan Gibbons <span dir="ltr"><<a
              moz-do-not-send="true"
              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 class="">On 03/25/2014 04:10 PM, Liam Miller-Cushon
              wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                Hi Jon,<br>
                <br>
                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.<br>
                <br>
                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:<br>
                - the filemanager implementation could use the
                FileManager.Location interface instead of depending on
                specific StandardLocation values<br>
                - Source.toSourceVersion(...) could return only the
                SourceVersion values that are present in the current
                platform, instead of requiring that the latest version
                is available<br>
                <br>
                Liam<br>
              </blockquote>
              <br>
            </div>
            OK, I think I finally see the issue that you may be
            addressing.<br>
            <br>
            I think you're saying that javac 8 depends on some enum
            constants in the JDK 8 rt.jar. To be specific, it depends on
            javax.tools.StandardLocation.NATIVE_HEADER_OUTPUT and
            javax.lang.model.SourceVersion.RELEASE_8.<br>
            <br>
            So yes, at some level, this is a bug.  For what it's worth,
            we don't see this problem when bootstrapping JDK because the
            classes in question are part of the "interim" version of
            javac used for the bootstrap, and yes, I guess we do use
            -Xbootclasspath/p: to override the classes in the bootstrap
            JDK, so now I maybe understand Martin's comment as well.<br>
            <br>
            With respect to your suggestions, yes I can see that it
            would be technically feasible to dynamically determine is
            SourceVersion.RELEASE_8 was defined and to avoid trying to
            return it. But NATIVE_HEADER_OUTPUT is a bigger problem.  We
            *do* expect JDK 8 clients to use the StandardLocation
            values, and so javac must support them. But we could simply
            disable the native header feature entirely if we're running
            on top of JDK 7, meaning we would dynamically determine if
            NATIVE_HEADER_OUTPUT was defined and deal with it if it was
            not.<br>
            <br>
            -- Jon<br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>