<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Thanks for the valuable feedback... but read until the end...<br>
    </p>
    <p>To be clear, this was not a case of Change for the sake of
      change. Rather I was inspired by Linux, Microsoft, DOD, and other
      swho I believe would not choose Rust for the sake of change. My
      intuition was, if these famous projects were investing in Rust,
      then the famous project of Java and the JVM might benefit from a
      similar investment. My intent was to open a discussion on these
      issues because I could not find previous discussion.<br>
    </p>
    <p>While I am not a Rust expert, I have played around with it enough
      to appreciate some of the important new thinking it integrates,
      and the reasons why I gave up on C/C++.<br>
    </p>
    <div class="moz-cite-prefix">On 2024-11-20 11:07 AM, Jesper
      Wilhelmsson wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:F1DA38A2-28CB-427C-B999-5890480CCCAA@oracle.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      Hi Eric,
      <div><br>
      </div>
      <div>As you probably already figured out, this is a no-go for so
        many reasons. I'll just add another one on the pile for good
        luck.</div>
      <div><br>
      </div>
      <div>Even if we could just snap our fingers and have the perfect
        translation of the JVM in rust, just ready to go, all tests
        passing, drop in replacement in the src directory, we could
        still not do it.</div>
    </blockquote>
    That was never my intention. I don't know why you are assuming that.<br>
    <blockquote type="cite"
      cite="mid:F1DA38A2-28CB-427C-B999-5890480CCCAA@oracle.com">
      <div><br>
      </div>
      <div>The JVM is developed and maintained by engineers who in many
        cases have worked with C++ development for decades. They know
        the C++ language, they know the JVM source code. Re-writing
        things in a different language like rust would unavoidably
        change how things are implemented, like synchronization/locking
        or gory details in the GC implementation. There are things in
        the JVM internals that are built the way they are because C++
        works the way it does. Moving to a new programming language
        would change how these things are implemented - not only the
        syntax of the language, but the algorithms themselves as well.</div>
    </blockquote>
    That is a good argument that I did not have insight on. Thank you.<br>
    <blockquote type="cite"
      cite="mid:F1DA38A2-28CB-427C-B999-5890480CCCAA@oracle.com">
      <div><br>
      </div>
      <div>This means that not only would you have to teach all JVM
        developers world wide a new programming language and new tools
        for development and debugging that at least some of them have
        never seen before and have no interest in learning, which in
        itself is a major and truly expensive task, you would also loose
        all institutional knowledge these developers have about how
        things in the JVM works after having worked in the code base for
        decades.</div>
    </blockquote>
    <p>My intention was an evolutionary change to the JVM. For example</p>
    <blockquote>
      <p>I might like the idea to write *new* components in Rust, or
        replace certain subsystems with new implementations when it
        makes sense, and if we can figure out how to interface between
        the C++ and Rust parts. It has actually already been done
        before. IIRC, the research group around Steve Blackburn wrote a
        new (research-y) HotSpot GC entirely in Rust.<br>
        <br>
        Roman</p>
    </blockquote>
    <p>From my understanding of Linux, they have been writing new
      drivers in Rust, similar to writing a new GC in Rust.<br>
    </p>
    <blockquote type="cite"
      cite="mid:F1DA38A2-28CB-427C-B999-5890480CCCAA@oracle.com">
      <div><br>
      </div>
      <div>Change for the sake of change is almost never a good idea. We
        routinely say no to changes that cleans up code or make use of
        new language features if they don't bring an actual benefit as
        well. Cleaning up code that no one is working in is not really
        useful for instance. Moving all code to a new language would
        change code that has been running without bugs or changes for
        20+ years. I started with the assumption that we could do the
        translation perfectly without bugs, but we all know that's not
        true. There will be bugs introduced all over the place. New
        interesting bugs that will take years to weed out. So unless
        your intention here is to destabilize the Java platform for many
        years to come and force a large group of C++ developers to start
        looking for a new job because they actually are C++ developers
        by choice ...
      </div>
    </blockquote>
    <p>I am personally offended by the remark, "So unless your intention
      here is to destabilize the Java platform for many years to come
      and force a large group of C++ developers to start looking for a
      new job because they actually are C++ developers by choice ..."</p>
    <p>That is insulting, childish, and very unprofessional. Why would
      anyone ever intend such a thing?<br>
    </p>
    <blockquote type="cite"
      cite="mid:F1DA38A2-28CB-427C-B999-5890480CCCAA@oracle.com">
      <div>
        <div><br>
        </div>
        <div>As all developers who suggest changes to the JDK should
          have done already, I suggest you also read <a
            href="https://openjdk.org/guide/#why-is-my-change-rejected"
            moz-do-not-send="true" class="moz-txt-link-freetext">https://openjdk.org/guide/#why-is-my-change-rejected</a></div>
        <div><br>
        </div>
        <div>/Jesper</div>
        <div><br>
          <blockquote type="cite">
            <div>On 20 Nov 2024, at 18:52, Kennke, Roman
              <a class="moz-txt-link-rfc2396E" href="mailto:rkennke@amazon.de"><rkennke@amazon.de></a> wrote:</div>
            <br class="Apple-interchange-newline">
            <div>
              <div><br>
                <blockquote type="cite">
                  <blockquote type="cite"><br>
                      If we're translating the Java runtime into a
                    better language, that<br>
                      language would be Java.<br>
                    <br>
                    <br>
                    Although rewriting HotSpot in Java would be equally
                    hard work, it would<br>
                    be much more rewarding and interesting.<br>
                  </blockquote>
                  Having worked on two Java-in-Java VMs (JikesRVM and
                  SubstrateVM -- oh<br>
                  and also a Lisp-in-Lisp OS i.e. Interlisp-D) I can
                  agree to the<br>
                  interesting but I'm much less sanguine about the
                  'rewarding'.<br>
                  <br>
                  There are many aspects of how pure Java operates that
                  make implementing<br>
                  Java in Java a significant challenge. You end up
                  having to allow some<br>
                  smaller or larger subset of the language to be
                  'impure', i.e. get<br>
                  substituted/compiled specially so it is not actually
                  operating like Java<br>
                  code in one way or another. That's necessary in in
                  order to be able to<br>
                  perform operations that are not constrained by the the
                  Java's highly<br>
                  opinionated and deliberately constrained memory model,
                  threading and<br>
                  synchonization model, etc. You also still need to
                  pirate on native<br>
                  libraries to do things like i/o (unless you relish
                  writing things like<br>
                  device drivers, file system management, etc in Java --
                  can be done, just<br>
                  as it was with Interlisp-D, but pheweee!).<br>
                  <br>
                  Once you concede that latter point you have to ponder
                  where exactly it<br>
                  is best to draw the lines between Java code, code
                  masquerading as Java<br>
                  code but compiled/translated as if it were something
                  else and explicitly<br>
                  invoked foreign code. I actually think Hotspot makes a
                  very good<br>
                  trade-off, implementing a lot of stuff in the JDK,
                  providing various<br>
                  flavours of intrinsics and JVM callouts to sidestep
                  some of the language<br>
                  limitations and using standardized foreign libraries
                  to do a lot of the<br>
                  heavy lifting.<br>
                  <br>
                  Also, now that we have a JPMS we can maintain those
                  boundaries very<br>
                  flexibly, redrawing the line to accommodate to new
                  hardware, new<br>
                  libraries and new language features (e.g. as was done
                  with method<br>
                  handles). It does not really do to be absolutist here.<br>
                </blockquote>
                <br>
                <br>
                I agree with all that you said.<br>
                <br>
                Plus, we should not forget the cost-benefit equation:
                HotSpot is a *huge* code base with dozens or more
                engineers having poured more than quarter century of
                work into it. Rewriting this in Rust or any other
                language would be a prohibitively expensive undertaking,
                with comparably little benefit, IMO.<br>
                <br>
                I might like the idea to write *new* components in Rust,
                or replace certain subsystems with new implementations
                when it makes sense, and if we can figure out how to
                interface between the C++ and Rust parts. It has
                actually already been done before. IIRC, the research
                group around Steve Blackburn wrote a new (research-y)
                HotSpot GC entirely in Rust.<br>
                <br>
                Roman<br>
                <br>
                <br>
                <br>
                <br>
                Amazon Web Services Development Center Germany GmbH<br>
                Krausenstr. 38<br>
                10117 Berlin<br>
                Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss<br>
                Eingetragen am Amtsgericht Charlottenburg unter HRB
                257764 B<br>
                Sitz: Berlin<br>
                Ust-ID: DE 365 538 597<br>
                <br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
  </body>
</html>