Project status summary

[Dan Smith]

As I've mentioned, I've been wanting to put together a broad summary of where the project is at. I've grouped this into three areas or tracks: Primitive Objects, Unified Primitives, and Universal Generics.

------
Primitive Objects

JEP 401: This is the core preview feature, including primitive class declarations, primitive object semantics, and primitive value types (with reference companions).

- Awaiting finalization of some outstanding design issues before trying to target a release

- Working towards an Early Access release, with the goal of substantially aligning with the JEP 401 description

- Our design focus recently has been on the "Enforcing instance validation" section of the JEP; our best candidate solution is to support a kind of primitive class that is both strictly-enforced and nullable. I'll flesh this out in a separate email in the next few days.

- There are still some complexities regarding reflection, 'getClass', and MethodHandles that we'd like to refine

- The behavior of weak references is still an open question

- JVMS changes are written, with some iteration necessary to fill in gaps and respond to feedback

- JLS changes are pending the above instance validation revisions, along with some validation of the type system (see discussion in Universal Generics)

---

JEP 8267650: This is a supplementary task focusing on JVMS rules and some corner-case JVM behaviors. We'd like to complete it before or at the same time as the JEP 401 release.

- JEP is nearly ready for Submission, but I need to iterate on it

- Some initial JVMS changes were created; Alex suggested some significant revisions that need to be applied

---

Future work:

- We hope to work on migrating a number of standard library classes (such as java.time.*) once JEP 401 is done (probably to be released after the features are final)

- Other projects like Amber and Panama hope to take advantage of primitive objects as well

------
Unified Primitives

JEP 402: This involves making the wrapper classes primitive and treating 'int', 'short', etc., as their value types.

- Expect to target a release concurrently with JEP 401

- I don't think we've tried implementing this yet (in javac or the special JVM treatment for arrays). It's probably best being handled downstream of the JEP 401 design issues.

- Some lingering discomfort with the proposed reflection story

- Some vague ideas about pushing this equivalence deeper into the JVM, but no concrete proposals

- JVMS changes aren't done, will be pretty small and narrowly-focused

- JLS changes will be fleshed out in parallel with JEP 401

---

JEP TBD: Wrapper Constructor Tooling. JEP 390 provided migration warnings about wrapper class constructors in 16+. We need to follow this up with some tooling to convert legacy class files so that they'll run on a release that doesn't provide Integer.<init>, etc., methods.

- Should release before or at the same time as JEP 401.

- Could also integrate other suggested followups to JEP 390, like runtime logging of deprecation warnings.

---

Future work:

- There are a lot of opportunities to enhance the API provided by the wrapper classes after we've completed the primitive class migration.

------
Universal Generics

JEP 8261529: This is the set of language changes needed to allow generics over value types and to facilitate safe migration.

- Has now been Submitted, awaiting Candidate status.

- The type system rules are being developed. High level intuitions are pretty straightforward, but the details of type variable types (now in two flavors!) and intersection types need some fleshing out and validation, particularly since these have historically been neglected.

- JLS changes will come when the type system design is clearer

- A prototype is implemented, subject to specification clarifications

- A near-term goal is to validate the user experience of the proposed compilation warnings by addressing them in a subset of standard library code

----

JEP TBD: Java Type System Refinements. Not clear exactly what this will entail, but there is probably a significant chunk of spec work that can be spun off independently and address some longstanding issues with the current type system.

---

Future work:

- Applying changes to address warnings in standard libraries (definitely java.base, plus some others, maybe not everything, potentially in stages)

- Parametric JVM, as discussed earlier this year—we have a reasonable picture of what this will look like, but there are lots of details to work through both in the design and prototyping. Type restrictions could be spun off as a separate feature, as they may have other use cases.