You don't really need to hold out hope for this... it is coming and soon. It's been in active progress for years now (its a huge undertaking).

Is there an update somewhere that I've missed? I keep looking for updates and haven't seen them.

(And yes, I know it's a huge effort, I was definitely not trying to say that it should be an easy change to get into the language)

There are JEPs out for parts of it now - Primitive Objects (which is the new name for value types) https://openjdk.java.net/jeps/401 and Unify the basic primitives with objects https://openjdk.java.net/jeps/402

I haven't read up on the details of these but this is a huge step in the right direction if pulled off properly. The dichotomy between primitive and non-primitive types in Java is a real rough spot. I'd have to see how they deal with null values though because the introduction of auto-boxing certainly introduced a new area for NullPointerExceptions to catch the unwary off-guard.

There is extensive discussion of that topic in the valhalla-dev and valhalla-spec-experts mailing lists, but I think the details are still being worked out.

>It's been in active progress for years now

And it might be in "active progress" for years more, seeing that we were promised it would come a decade ago.

I recall someone in /r/java saying that I should stick with Java for the new project because project loom is just around the corner. The system has been in production for 3 or 4 years by now.

Even more useful will be a Mandatory<T> type. Maybe with “T!” and implicit conversion to T as syntactic sugar.

Edit: Unfortunately it would have the drawback of nonoverloadability due to type erasure.

I am not sure I understand, why would you want Optional type to never be null? Isn't it being null sometimes — the whole point?

Say you have:

    public void doSomething(Optional<String> foo) { ... }

You want `foo` to be `Optional.empty()` or `Optional.of("some string")`. The way things currently work, `foo` could also be `null`.

Kotlin's approach of making null act kind of like Optional is pretty nice, but I wish there was a strict option for interacting with Java types -- by default, all Java-native types (type names ending with !) can be null and are not null checked at compile time.

In our code base we just throw a `?:` after any type that shows up as Type! and handle it immediately. If you actually expect a null value you can also use `?: null`

How does making Optionals allocated on the stack (value types) prevent this?

Or rather why do you need value types to accomplish this?

Perhaps this example will make it more obvious:

    boolean truthy = false;
    truthy = null; // compilation failure, type mismatch

vs. the Boolean type

    Boolean truthy = new Boolean(false);
    truthy = null; // compiles just fine

The reason Boolean (and other boxed primitive types) exist is because it is an Object (a reference type) and that allows them to be used in things like collections that expect Objects and not primitive types.

Looking at https://openjdk.java.net/jeps/401 it's not totally clear to me at the moment how you can use ValueTypes (primitive keyword) in Collections. Might be that you'll need to take a reference to them with Type.ref (but I need to read 401 in more detail to understand that).

Hope that helps.

> Looking at https://openjdk.java.net/jeps/401 it's not totally clear to me at the moment how you can use ValueTypes (primitive keyword) in Collections.

JEP 401 won't cover it quite yet, note this from the "Non Goals" section:

> An important followup effort, not covered by these JEPs, will enhance the JVM to specialize generic classes and bytecode for different primitive value type layouts.

It wasn't until recently that I understood for myself just how large the surface area of the "value types" problem is - it will be delivered incrementally. JEP 401 and 402 are the first steps (if I were to guess they will show up as previews soon? maybe JDK 17 or 18?), but there is more to come.

So you are really looking for compiler checks for null? Kind of like kotlin?

var truthy = null; // Compile fails

var nullable? = null; // Compile passes

You don't need value types for this?

That's not exactly the same thing... It can also (again I don't know if this is part of the jep or not) be used to perform stack based destructors (finalize) and then Java could implement RAII. Reading the jep it discusses perhaps rejecting finalize as function on primitive objects, so this might not be in scope.

Additionally, the type is also lighter weight than an Object and should be stack allocated, so there are memory advantages to not having to use boxed types as well.

> How does making Optionals allocated on the stack (value types) prevent this?

Let's not confuse language specification issues with implementation issues. Both value and object types can be allocated on the stack. Both can be allocated on the heap. Both can not be allocated at all and can be scalar replaced. So this isn't the meaningful difference!

There's a big difference between the Optional containing null (useful) and the Optional itself being null (but why).

> Isn't it being null sometimes — the whole point?

No you have it backwards - the whole point is that Optional is never null. You use empty instead.

I'm looking forward to Valhalla too, but I think it won't be as impactful as people think. In particular that use case is a poor fit for Valhalla and I don't think Optional will be widely adopted even post-value types. The intent here is to mark which parameters and return types can be null. A laudable goal. However:

1. You will still be using many, many libraries that pre-date cheap Optional. For those, the lack of Optional will NOT indicate the value is always present, it will mean "no optionality information available". Therefore by looking at an API you can't actually tell what the lack of Optional means: it could be deliberate, or it could be legacy. This will make the signal useless.

2. Optional is a very verbose, heavyweight syntax for handling optionality. Therefore some developers will not use it on the grounds that Java is already a very verbose language and it really doesn't need more. This will cause further divergence.

3. Many developers will want to preserve compatibility with old JVMs. Even though Optional is around a long time now, guaranteed cheap/fast Optional will take a long time to roll out and may never make it to Android at all. This will cause some library developers writing high performance code to shun it because null is as cheap as you can possibly get, and universally supported. Again, the lack of Optional will be meaningless.

4. The killer blow: adding Optional changes your function signatures and therefore breaks both binary and source compatibility. Many library developers want to keep a backwards compatible API, or are required to, and that includes for example the Java standard libraries. Therefore lack of Optional will NEVER mean "guaranteed to be present" in most Java code because the standard library won't use it that way.

There is a far, far better way to handle this and it's what Kotlin did:

1. Integrate optionality into the language using lightweight syntax and type inference.

2. Use non-denotable flex-types at the edges, so missing optionality information is added transparently in the source code the first time a developer specifies a type explicitly.

3. Allow annotations to provide nullability information, preserving source and binary compatibility. Integrate it with IDE and compiler data flow analysis. IntelliJ already does this and you can make nullability violations hard errors today by adjusting your project preferences.

4. Finally, allow third party libraries that aren't being changed to be annotated using external annotation files.

Or use Scala :)

Which doesn’t have value types because it should be implemented in the JVM?

They can only wrap a single primitive type - it’s a nice feature but nothing extraordinary. When Java implements primitive types, Scala will probably use this same construct. But the change have to come from the runtime level.

Does Scala have value types?

Ah right - that's not really what we're talking about here, even though they have the same name.

“Codes like a class, works like an int!” - Taken from the top of the page.

This is exactly what Value Classes are in Scala. You supply an underlying value which is then interpreted as the value itself, not a reference.

What you're talking about is just wrapping a single value. It's a type-system thing.

What we're talking about are wrapping compound values. It's a VM implementation thing.

They're not really comparable.

> must have exactly one parameter,

Huge limitation. Not anywhere near the same thing.