<div dir="ltr">Nice to see! <div><br></div><div>Presumably the concrete goal will be to nail down an ABI between compiled code and the HotSpot runtime services? The compiler independence of the goals is quite interesting. In theory if there's a precise ABI for accessing runtime services like the GC, reflection, deoptimization, TLS etc, then you could write a new non-Java language that compiles to native code ahead of time using some pre-existing compiler infrastructure (e.g. .NET?), which then uses HotSpot almost as a normal language runtime library. Minimal Java code would be executed in this model and you could theoretically even use LTO to get rid of the bits of the JVM you aren't using. So if you wanted to make a new GCd language but wanted to skip bytecode and Truffle then you could do so, with a Leyden of that form.</div><div><br></div><div>Or is the idea to go in some other direction?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 28 Jul 2023 at 04:41, Julian Waters <<a href="mailto:tanksherman27@gmail.com">tanksherman27@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi all,<div><br></div><div>A JEP draft regarding Leyden has been submitted at <a href="https://bugs.openjdk.org/browse/JDK-8313278" target="_blank">https://bugs.openjdk.org/browse/JDK-8313278</a>. Feedback is welcome</div><div><br></div><div>best regards,</div><div>Julian</div></div></div>
</blockquote></div>