Replace the primitive class with a more general null safety?

[Brian Goetz]

There’s a lot of good thoughts in here (and some wishful thinking too), but most of it is well-covered ground.  

> After I read the JEP and related documents of Project Valhalla, I doubted the necessity of the existence of primitive classes.

We have been asking ourselves this question every day.  As the old saying goes, things should be as simple as possible, but no simpler.  Past attempts to simplify them away did not succeed, but that doesn’t mean we don’t keep trying.  

> It is impossible to migrate from identity class to primitive class, which will break binary compatibility.

This is not entirely true.  There are constraints involved, and at the appropriate time we will publish a migration guide, but it is not the case that you can’t migrate from B1 to either B2 or B3.  But this isn’t your real point.  

> At the same time, in order to support non null types, the universal generics draft also greatly undermines compatibility.

This is a pretty strong statement, and I’ve certainly not seen evidence for this.  But, again this is tangential to your point (and likely overstated to make your point sound better, though there’s no need for that), so let’s get to your point.  

> Although the value class is more compatible, it may not be inlined when it is a field or array member.

You’re confronting the essential physics of the problem; rejigging the packaging won’t change this.  But again, not your point.  

> I don't like the current draft very much. In particular, I am very dissatisfied with the huge cost of providing null safety only for primitive types.

The second sentence is the best part of your mail, pointing out that we’re incurring a lot of complexity whose benefit only accrues to some of the types.  This is indeed suboptimal. 

> Now I have an idea: it's time to provide generic non null types for Java.

You say this like it is a new idea!  We have explored this in *literally every iteration of Valhalla.*. At each iteration, we have asked ourselves whether the key distinctions could be replaced by general-purpose “emotional” (bang and question) type operators, or whether even that notation is helpful or harmful to user intuition. At each point, the answer has been “almost, but not quite.”  And in each iteration, we’ve continued to chip away at the difference, and ask ourselves the question again.  The current iteration is still a “no”, but it is still a matter of active exploration, because *of course* Java developers would prefer this to the current val/ref scheme.  (Or at least some of them think they would.). 

> Since the universal generics draft has decided to break compatibility, we can go further

I don’t know what you mean by “decided to break compatibility”, but even if that were true (and yes, there are small incompatibilities, such as “what happens when you lock on Integer”), the rest would not remotely follow.  

>  and provide universal non null types in Java, just like Kotlin.


Haha, “just”.  No.  Even if we were to find our way to non-null types, it would not be “just” like anything.  

> If we do, we no longer need the primitive class. It is enough to mark the value class as non null.

Actually, no.  This is not the only difference between primitives and references.  If it were, we would have adopted this “solution” a long time ago.  

As I said, there’s a lot of good thoughts in here, and the relationship between values and non-rulllable types has been a constant question along this journey, and still is.  We may be getting closer to having these concepts meet up.  But it is not “just” anything.  Stay tuned.