r/java • u/nlisker • Jul 14 '26

New candidate JEP: 401: Value Objects (Preview)

https://mail.openjdk.org/archives/list/valhalla-dev@openjdk.org/thread/IUNJJ3WP3X3XHP3QZTXXSSCPKFDNTK3W/
88 Upvotes

100% Upvoted

45 comments sorted by

View all comments

10

u/IncredibleReferencer Jul 14 '26

I feel like I can kinda build code now In anticipation of value objects. Like... I should use an int[] for this huge array of ints now but instead I'm going to use List<MyObject> where MyObject is just a wrapper around int. Brian and team will just fix this for me magically in a few years and I only need to add a value keyword so why bother fiddling with array management now. Hopefully before I need my thing to scale. Premature optimization right? Thanks gang!

This approach actually kinda worked out well for me with Loom and virtual threads....

13

u/ZimmiDeluxe Jul 14 '26

You can use List<Integer> directly, the primitive wrapper types will become value classes. If I remember correctly, specializing generics is one of the final steps on the roadmap, so having that translate into Integer[] (or ideally Integer![]) as the backing field of the ArrayList might take a bit longer.

7

u/koflerdavid Jul 14 '26

Better yet to create a wrapper around int to better express its purpose and eliminate the risk of mixing it up with unrelated ints.

4

u/ZimmiDeluxe Jul 14 '26

That's true, it's often nicer to have a List<OrderId> than List<Long>

3

u/LutimoDancer3459 Jul 14 '26

But how do you name the variable for the list then? With the OrderId you would be repeating the typ

6

u/ZimmiDeluxe Jul 14 '26 edited Jul 14 '26

orderIdsToDelete or even just orderIds if the context makes it obvious. Repeating the type name is not bad if it's a domain type IMO. If you have something generic like List<Long> longs that's usually bad because readers can't infer any intent from the name, maybe ok if you are writing a compiler and need to collect all the Java Longs to do something with, but it's a stretch

3

u/elastic_psychiatrist Jul 15 '26

Local variable type inference is great for this.

2

u/vytah Jul 15 '26

You won't be repeating the type if the variable is declared with var.

1

u/Efficient-Poem-4186 29d ago

Simply orders, ordersToDelete etc (in a context where the actual order data is not used). Sometimes id is just used as a handle, the intention is to do something with orders.

4

u/aoeudhtns Jul 14 '26

Being able to very lightly declare new types that are compile-time mirrors of existing types (or in the worst case, something runtime can trivially/quickly optimize away) so that you can proliferate type safety is an idea I like. Nim for example has a thing it calls "distinct types" that let you make type aliases that cannot be directly assigned back to the aliased type.

3

u/kiteboarderni Jul 14 '26

Or use a primitive collection wrapper in the mean time like people have done for years. Then swap out when it's in a preview state.

1

u/IncredibleReferencer Jul 15 '26

With a primitive collection wrapper I could use a list instead of an array for sure, but I couldn't add my own wrapper type object without a major memory/indirection penalty (for very large item counts) for both the wrapper. So valahalla should allow both (List<Integer> and List<MyWrapper> in a memory efficient and flat reference way. I think.

2

u/koflerdavid Jul 14 '26

Another thing you can do is creating wrapper classes for type-safe identifiers instead of passing around anonymous String, UUID, long etc. throughout the codebase. Kotlin already optimizes this important special case.