<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
Hi,
<div><br>
<div>Maurizio did some excellent work in PR #273 (<a href="https://github.com/openjdk/babylon/pull/273">https://github.com/openjdk/babylon/pull/273</a>), which moves almost all the code reflection implementation and all the API into an incubating module called
jdk.incubator.code. This went much better than we initially anticipated.</div>
<div><br>
</div>
<div>Compilation and execution using code reflection now requires that jdk.incubator.code module be visible. This is commonly enabled by the command line argument:</div>
<div><br>
</div>
<div> —add-modules jdk.incubator.code</div>
<div><br>
</div>
<div>While there is still a lot of stuff to work out we are architecturally in a good position with a reasonable working solution from which we can build applications, gather feedback, and grow mindshare. Further, this will also provide a stronger foundation
for the Heterogeneous Accelerator Toolkit (HAT).</div>
<div><br>
</div>
<div>To do that effectively we think we need to incubate in the JDK. This is the first step in that direction. When will we incubate? Don’t exactly know yet. We need to explore at least the following before being ready doing so:</div>
</div>
<div><br>
</div>
<div>1. Rearrange the operations and types (as discussed in prior email)<br>
2. Evaluate encoding models in class files as methods that build them (we are currently exploring to obtain data on class file sizes)<br>
3. Update to support new language features<br>
4. Do a thorough review of the API (with a view towards minimalism - the API surface is large!)<br>
5. Specify the behavior in documents and JavaDoc</div>
<div><br>
</div>
<div>Paul.</div>
</body>
</html>