Back to News
Advertisement
Advertisement

⚡ Community Insights

Discussion Sentiment

86% Positive

Analyzed from 378 words in the discussion.

Trending Topics

#null#value#age#domain#iban#performance#cannot#json#person#haskell

Discussion (11 Comments)Read Original on HackerNews

mrkeenabout 14 hours ago
Oh cool. It's newtype from Haskell 1.3 (1996).

https://www.haskell.org/definition/from12to13.html#newtype

mrkeenabout 2 hours ago
No idea why dfa11's sibling comment got nuked. Looks correct to me.

I guess you can probably do the same with Unpacking.

https://wiki.haskell.org/Performance/Data_types

dfa111 day ago
Valhalla removes the historical performance tax on tiny domain objects. This article argues that value classes finally make domain‑safe primitives practical in real systems — strong invariants, flat layout, no wrapper overhead.

I’d love feedback from folks who’ve experimented with Valhalla or have opinions on modelling domain types in Java.

exabrialabout 9 hours ago
> Value classes cannot be null.

Won't this be an issue for JPA/JSONB? `null` is a an important and value in JSON and nearly every database, and for modeling the real world.

dfa11about 4 hours ago
True: this compiles and the test passes today on JDK 27-jep401ea3:

  record Person(String name, Age age, Iban iban) {}

  // {"name": "SuperMario", "age": null, "iban": null}
  Person result = mapper.readValue(json, Person.class);

  assertThat(result.age()).isNull();   // passes — value class field, null
  assertThat(result.iban()).isNull();  // passes — value class field, null

  Jackson bypasses the constructor for null JSON tokens (getNullValue() short-circuits), so the
  validation in new Age(...) never runs. Both Age and Iban are value classes; both fields are null.
What do you think? Of course, there are limitations as Person cannot be flattened anymore but I guess Valhalla will ship more JEPs later?
mrkeenabout 9 hours ago
It is not.

Null is the thing which it isn't. A null value is evidence that your modelling does not fit the domain.

exabrialabout 9 hours ago
Unfortunately, the simple fact is that one can be handed a JSON document with non-existent keys, and one can be handed a database row with a null column. Often, the programmer may handed a schema from a third party they have no control over: opening a semantics debate is likely not a good course of action.

I guess since basic types, like an int or double, cannot be null, I understand why these cannot be null. This unfortunately limits their usefulness, but it's a carryover from the underlying properties of the basic type.

rf15about 14 hours ago
I've been working in Java for more than 20 years now, the last 10 with unperformant, yet performance critical enterprise slop.

I can only really say one thing here: they are really late to the party with this but it's good. The performance boost will be welcome, and would probably change ORMs forever if applied right.

Nullability rules should of course be also part of this domain-constricted types concept, since it would solve a lot of accidental mistakes. Because that's what a type system is for, right? Validation of programmer input.

dfa11about 2 hours ago
yeah 100% agree! In some critical area, I'm forced to drop all the "good things" and pack 2 shorts into 1 int to build a tuple(short,short)...