I appreciate the hard work that went into the things that did make it into Valhalla eventually, but:
> The model was powerful, but also mentally heavy
No it isn't! it is this interpretation that kills off the null-safety debate entirely. Saying you have a variable that cannot be null is not a mentally taxing distinction, especially since everything is labelled thoroughly.
> The team, faithful to the lesson “simplify the model for the user, even at the cost of the performance ceiling,” ultimately dismantled this dualism.
but it would have simplified it for the user.
The whole attitude and process around this and the other topics gives me very little faith that Java can be steered in a sensible direction here. The type system of a programming language is supposed to give convenient guarantees to the developer on a CPU that can only do numbers. There is no reason to reduce the optional(!) safety guarantees you can offer with the excuse of "too mentally taxing".
Hell, they even get there half way by recognising:
> the language model and the JVM model don’t have to overlap one hundred percent
> The whole attitude and process around this and the other topics gives me very little faith that Java can be steered in a sensible direction here.
I agree. The stewardship of Java seems rather lacking - particularly when compared to that of .net, where MS etc. mostly seemed to make the correct decisions from the start.
Does Java even have any value or mindshare at Oracle nowadays? The company seems to be a datacentre/compute business at this point, with appendiges for its legacy activities and a vast overhang of debt.
I sometimes wonder if the only parts of Oracle that are still profitable are the Legal and Lawnmower divisions.
First, your parent comment misunderstood what the section they were critiquing is referring to. It's not about nullability (which is orthogonal) but about reference/value projections.
Now, as a member of the Java team (although I'm not directly involved in Valhalla), I'm obviously biased so let me just say that both designers and fans of programming language features would do well to remember two things:
1. Opinions about features are almost never universal, even among experts, and almost each of them is about a tradeoff where different people prefer different sides. It is rare that some scientific study settles the issue.
2. These preferences are often not evenly split. Even when both sides are equally confident that their preference is the right one, sometimes 80% or 90% of programmers share a preference. The people with the strongest opinions are more often than not in the minority, because most programmers don't think so much about the programming language (nor, I would say, should they).
All of the language differences between .NET and Java fall in this "non-consensus" zone, and at least in one area I was deeply involved with, virtual thread, I can say that we thought that whatever we do we mustn't do what .NET did and that what they chose didn't work out well for them at all.
This is great advice and it applies to a lot more than just language features. Different architecture, deployment setups, QA approaches are all like this. It's always "approach A is no good", "but company X uses approach A and they're doing very well", "yeah but look at all of these problems they have". Maybe a fair argument but the approach B people also have their fair share of problems...
What's funny is that the only languages in the same popularity league as Java are Python and JS/TS (and possibly C and C++ if you want to extend things to more domains) yet I rarely ever hear people saying Java should be more like these languages. It's because many of the people who dislike Java also don't like any of the most popular languages (even those who like, say, Python better don't think Java should be more like Python).
These people may point out that languages become more or less successful not because of the things these people care about but because of other factors. And they're right, but then the question is, shouldn't a smart product team focus more on the things that actually matter more to more people?
Programming languages are tools, and so their value is not intrinsic, but comes from the value of the software they're used to create. Now, some people claim that Java's success is largely the result of it being one of the most hyped languages of the late 90s and early 00s, alongside VB, Delphi, FoxPro, and C#. But this claim doesn't stand up to even the slightest scrutiny.
Both languages/runtimes are decent, stable and good choices for running production systems.
They have different philosophies though, C# is mostly "give the developer a complex toolkit so they can do whatever they want, but keep the runtime simple", while Java is more like "keep the language as simple as possible, and put new features mostly into the runtime making it more complex, but benefiting even old code".
Async vs virtual threads is a clear example of that. The former makes the language much more complex, and has a huge surface area where it may clash with other features, so a developer has to remember all of these. But it's a simple machinery under the hood.
Meanwhile virtual threads don't change the language at all, it's the same as it was with Threads, but under the hood it is a very complex feature.
And in this particular instance I think it is quite clear cut that Java made the correct decision, for the most common use case of these languages having non-blocking IO "automatically" makes for significantly better user experience.
I do think Java is a fine language but I don't really agree that it looks more simple in any way shape or form.
For things like UI programming where you need a main thread or where you do need a cross language OS thread, I think Java is going to end up more complex. Under the hood it is very complex and that _will_ show itself.
So from my perspective it's not virtual threads, it's virtual threads with structured concurrency vs async/await. When you look at it that way, the comparison of complexity is certainly not seamless or simple.
As a person with a lot of .NET experience but has been working on other tech since 6 years, the wow effect I had from using LINQ has never been repeated with anything else.
It felt like magic, maybe too much magic, but so useful nevertheless.
LINQ comes from FP, and was introduced into C# via Haskell, and actually the first version (.NET 3.5) was quite similar to Smalltalk or Common Lisp collections.
.NET do what they do because they believe many people like it, and we do what we do because we believe many people like it. Because different developers like different things, we may both be right. The only explanation to why we do what we do is that we believe it works well for us, and we know what everyone should know, which is that what we do can't be universally liked because developers have different preferences.
But that doesn't mean the preferences are equally distributed. Some people liked Betamax's better picture quality while others liked VHS's better recording times, but they didn't do it in equal numbers. And that's what's funny, because there are two languages doing as well as Java or better (one of them is much more popular), and yet what's almost universal is that when people say "Java is worse than X", X is invariably a language that's doing much worse than Java.
I'm not saying that there isn't much to learn from less popular languages, but the claim "Java is consistently making the wrong decisions compared X" doesn't make sense when X is consistently losing to Java.
And I can even give you the secret to our strategy: Make Java the language that people who choose it regret less than people who choose other languages.
I think you misunderstood my point. I'm not claiming that the most successful products necessarily have all the best features. I am saying that the claim that "team X consistently makes worse decisions than team Y" is hard to support if team X is winning. At least some of their decisions are probably better, and those ones also probably matter more.
Value types kind of definitively don't have null, right? You can have a zero int but not a null int. So nullability is not entirely orthogonal to value types, its an advantage for value types where they are practical.
I didn't say nullability is orthogonal to value types; I said it was orthogonal to the two-projections world, which is what that text in the article was about rather than nullability.
As to value types and null, I'm not sure about the current picture, but the general idea is that you declare what semantic properties you want - identity or not, nullable or not, tearable or not - and then the compiler picks the best technical in-memory representation for each use. For example, the compiler could choose not to flatten variables that could be null in the heap but to flatten them in the stack. That's the general idea, but I'm not sure about the details, some of which may yet change.
More generally than just Java, nullability is often a property not of a type but of a variable. For example, in C, an int may not be null, but a pointer to an int may be. Now, in C, `int` and `int*` are two different types, but that's exactly a distinction that the original projection-spit design made and we wanted to avoid. But you could still end up with a variable that could hold either an integer or a null and another that may hold an integer but not a null, only this is separate from the reference/value projection, which combines both identity and nullability (in C, `int*` is not only nullable, but also has identity).
> More generally than just Java, nullability is often a property not of a type but of a variable
I'm going to hard disagree here. And the syntax proposed in the Null-Restricted Value Class Types JEP is a major step backwards.
I want to banish nulls from my codebase, completely. I can currently do this with a variety of annotations (at the package-info.java level) and tooling, though it's not integrated well with the language.
Forcing exclamation marks into every variable and parameter is a lot of annoying noise that quite simply nobody will do. The default should be non-nullable, especially for value types.
Declaring whole types as non-nullable is less noisy and errorprone than annotating every variable declaration. If you aren't going to give me "declare the whole codebase as non-nullable" then at least give me something coarse-grained.
> the syntax proposed in the Null-Restricted Value Class Types JEP is a major step backwards. Forcing exclamation marks into every variable and parameter is a lot of annoying noise that quite simply nobody will do. The default should be non-nullable, especially for value types.
Then you didn't read the JEP draft (it's not an accepted JEP) carefully. It says, under "future work":
Providing a mechanism in the language to assert that all types in a certain context are implicitly null-restricted, without requiring the programmer to use explicit ! symbols.
In other words, the draft already incorporates your point, but JEPs (both drafts and actual JEPs) follow the pattern we've found to work so well, that features are best delivered piecemeal rather than in a big bang.
Having said that, I don't know the current plans for this matter, as that document is only in Draft status, so saying it's good or bad is pointless, as it's not even a proposal yet, just something being explored.
It's a proposal for a proposal, fine. Consider this my proposed feedback.
I don't think this syntax is desirable as currently proposed, and that one line under "future work" is doing far too much lifting. My sincere hope is that there are people closer to the process that also feel this way, they will provide similar feedback, and the next draft will be something completely different.
Except we like delivering features by pieces, so unless your proposal is to first deliver global flags with no instance-specific control and later add more control (and I think you're not suggesting that), I don't see any difference between what you're suggesting and what that draft is suggesting. That a one-line under "future work" is doing a lot of lifting is just how we usually do it (and it's okay, people always complain, but we've tried the big-bang approach and this one just works better for us).
So consider that draft as an idea for how the site-specific nullability annotations could work rather than an idea for how nullability could work in the language in general.
> how the site-specific nullability annotations could work
That's fine but it's still a bad choice. The problem is that it defaults to everything nullable and adds noise for non-nullable. This is backwards; in the overwhelming majority of software that people use Java for, non-null is the common case and nullability is the exception.
Kotlin and Typescript got this right. Nobody wants! to! write code! like! this! And they won't, so the feature won't get used and we're back to everything being nullable.
Except there's no choice here. It's a draft of an exploration of a portion of a feature.
Drafts are ideas that have not even been submitted for consideration for inclusion in the roadmap. You can find drafts over ten years old that have long since been superseded by other ones or abandoned altogether: https://openjdk.org/jeps/0#Draft-JEPs. Some JDK engineers write JEP drafts when they feel they get close to something they would like to propose, while others write drafts for pretty much any idea they have.
> The problem is that it defaults to everything nullable and adds noise for non-nullable
It doesn't, though. Even if this draft ever becomes a JEP (and I don't know if it or anything like it will), in its present form or another, it would still, like most JEPs, describe only part of the feature. It's perfectly on point for one JEP to describe the explicit nullability annotations, while another describes the defaults. Smaller features than this have been split into two or three JEPs. This is just how Java features have been described and delivered for years now (see how many JEPs patterns were split into: https://openjdk.org/jeps/0).
It's perfectly okay to dislike some design, but I find it strange to assume, based on a draft of a portion of a feature that one of the most experienced and successful programming language design teams in the history of software is likely to get it wrong. Maybe wait until there's an actual proposal and a roadmap for the complete feature before critiquing it? It's like seeing a draft of some building's foundations by a prestigious architectural firm and saying, these idiots forgot to plan a roof.
Yes, but it comes from Java having both runtime and compile-time types; it's harder to make the distinction in languages that don't have runtime types.
In Java, you can ask, `x instanceof T` (and this is a runtime test), which means, is x one of the values in the set of values allowed by T. `null instanceof Integer` is false, even though a variable of type `Integer` can be assigned a null. So you can think of `Integer x` as being `Integer|null x`, i.e. x can hold a null, even though `null instancof Integer` is false.
I think I mostly got this, but just to test it, it would be like in Typescript where I might say:
type Foo = { x: number; }
type Bar = { x: number; y: number }
type FooBar = Foo | Bar;
function baz(x: FooBar) {
if ('y' in x) {
// compiler now knows x is a Bar
}
}
In this case, the variable `x` has a property that is determined by the compiler based on control flow. i.e. it isn't explicitly carried by the type of `x`.
This won't be true in Java, though - in Java, you will have null Integers at least. It seems that int will remain a different thing entirely from Integer, and will remain a JVM-only concept.
But with null-restricted types, Integer! and int has no difference semantically and representation. They plan to introduce null-restricted types in future.
I think user-mode threads are better when the language already has threads. I'm not sure they would have been better for JS. But yeah, this one is probably less controversial than things like properties and extension members, which we also said "yeah, nah" to.
Although the work being done to enable multiple threads in JS is impressive I think it will be hard to make robust in many casss without locks, or fairly strict limits what operations can be performed on objects shared between threads.
The property lookup and modification process in JS is complex enough as is, is not specified in an atomic kind of way, and has many opportunities for user code to be run as part of accessor properties. Enabling it in multithreaded implementations is tricky without opening up deadlocks when modifying property collections, and even with that could likely be broken by some suitably evil code. Ive worked on more than one implementation that offered some degree of multithreaded access and it’s generally only safe when limited to simple properties.
Async / await avoids those issues because none of the places where user code can be executed allow async code, so there is no opportunity for the world to be changed under your feet during something like property access.
What's wrong with what .NET did with threads? Having async tasks sharing the GUI thread seems like a nice feature. Will we be able to use virtual threads and structured concurrency with Swing, e.g. to wait for a background task in an event listener?
An alternative solution to that of fibers to concurrency's simplicity vs. performance issue is known as async/await, and has been adopted by C# and Node.js, and will likely be adopted by standard JavaScript. Continuations and fibers dominate async/await in the sense that async/await is easily implemented with continuations (in fact, it can be implemented with a weak form of delimited continuations known as stackless continuations, that don't capture an entire call-stack but only the local context of a single subroutine), but not vice-versa.
While implementing async/await is easier than full-blown continuations and fibers, that solution falls far too short of addressing the problem. While async/await makes code simpler and gives it the appearance of normal, sequential code, like asynchronous code it still requires significant changes to existing code, explicit support in libraries, and does not interoperate well with synchronous code. In other words, it does not solve what's known as the "colored function" problem.
Regarding Swing, virtual threads are "just" threads so no reason they (and structured concurrency) can't be used.
You still can't block in UI code, right? You don't know whether you're on a virtual thread or the UI thread (even if its virtual) by design. You still have to bifurcate your APIs into blocking and non-blocking, don't you? Virtual threads will help you keeping the CPU fed but it won't handle separating UI and non-UI work, or know when a frame deadline ends.
Have there been Swing specific updates to deal with that?
So does Java provide an API for continuations or just the virtual threads hidden behind the threading API? You can't use threads to wait for something on the UI thread (which is why e.g. SwingWorker exists), but you can with await.
There is no public-facing continuations API afaik.
Structure concurrency/virtual threads seem like a good fit for Swing; just have your event handler fire off virtual thread[s] and do your work and call SwingUtilities.invokeLater to schedule the result to be applied on the event loop thread when you're done. Structured concurrency simplifies managing groups of concurrent tasks, cancelation, etc.
The colorless functions approach has well-known disadvantages though, including providing less control and making interop a pain. It isn't like one approach is the correct one and another is a mistake.
> including providing less control and making interop a pain
This is true in some languages but not in Java. The limitations (and performance cost) are not from the nature of continuations/stackful coroutines/"colourless functions", but from their interaction with other constraints and existing designs in the language. E.g. in Java, virtual threads have zero impact on FFI.
In general, the costs and limitations associated with a feature in language X don't extrapolate to language Y, because they often stem from interaction with existing constraints in language X.
The design of FFI is a very common source of problems for various features. For example, if the FFI is designed such that you frequently pass pointers to to objects to C, that can have a big impact on other features. In Java, you nearly always only pass pointers to "off heap" memory, i.e. memory that's not managed directly by the JVM. While this has no performance cost, you could say that this, in itself, has some convenience cost, except Java programs need to rely on FFI much less than other languages, so the overall cost to convenience is low.
How can green threads have zero impact on FFI in the presence of callbacks across the boundary? I mean, as soon as the other side uses TLS in any way, for example, you have to figure out how to handle that, and it's not free.
In every user-mode thread or stackless coroutine (async/await) implementation I know, the construct is pinned (i.e. can't be preempted) while there's a foreign frame on the stack. There is no advantage to either design on that front.
But 1. there's no speed penalty in Java for doing that, and 2. In Java, calling native functions that block (which is the only time this limitation matters) is rare, especially in high concurrency situations where you'd use virtual threads in the first place.
I was at a conference on scientific programming in Java very early on that Geoff Fox put on up at Syracuse and we had a list of requests from Sun that they didn't give us but Microsoft gave many of them right away.
On the other hand I really like Java's all-virtual approach to inheritance because the .NET model gives programmers more ways to screw up and get confused.
Both languages slipped in generics after 1.0. Java used type erasure in a way that made it so a List<String> is really a List so generics could be retrofitted easily to existing code. .NET's implementation of generics let you do more but caused a rift in the ecosystem between generic and non-generic collections.
I'd say long term Oracle's stewardship of Java has been very good. JDK 8 puts lambdas on your fingertips with a very fluent syntax that belies the idea that Java is terribly verbose. Since then Java has gotten steadily better release after release while maintaining great compatibility.
I work with people who are conservative about updates because they are worried about breaking things but for the last few LTS releases I've said "it ought to be really easy, let's give it a try" and it is really easy and we get performance improvements we can feel.
Java stagnated for quite a while. Seemed like everyone was stuck on Java 6 for about a decade. But JDK8 was a huge step forward. Lambdas, streams, and a date/time API that is the best I've seen.
I think DotNet had a bit of benefit, in that the language was still new enough to do the hard breakage. It was only about 3.5 years between NET1.0 and 2.0 (Where generics were added.)
I was annoyed by it back when I was doing Silverlight/ASP.NET
Thing was a lot of Microsoft APIs for GUIs and whatnot used the List and if you wanted to use the List<X> you had to copy the list or make a wrapper or something. You might say, "just use the List" but at that point (circa 2008) I had to also use the List<X> for some API so I always had to do some conversion.
The way it worked in practice is that all the new built-in collections in System.Collections.Generic implemented the non-generic interfaces as well, so e.g. List<T> implements IList<T>, but it also implements IList (explicitly), and similarly for ICollection and IEnumerable.
Then, when WinForms or WPF wanted a list, you could just give it a List<T> instance, and it would talk to it via IList, boxing and unboxing if necessary.
What you describe happened in the other direction - if you had, say, a generic method operating on IEnumerable<T> or IList<T>, and wanted to pass it a WinForms collection. WinForms generally defined strongly typed collection classes on a case by case basis, but none of them implemented the new interfaces. It was there where you had to wrap things, most often using AsEnumerable<T>().
In what way? If anything Java's main developers (employed by Oracle for the most part, working on the completely open source and free OpenJDK) are extremely knowledgeable and are responsible a big jump in how fast the platform evolves. They have added proper algebraic data types to the language, delivered virtual threads and garbage collectors that decouple pause times from heap size. Like if anything, Java is at the best place it has ever been.
> They have added proper algebraic data types to the language
No they haven't. E.g. they added a class that superficially looks like Option but subtly breaks the rules that Option is meant to follow, ensuring that no-one can ever manage to migrate existing codebases away from using `null`.
Sealed classes/interfaces and records are proper sum and product types.
The stdlib's Option type predates this language update by a long shot, so it doesn't use sealed classes, but it is now possible to have the usual FP "Maybe" type in Java:
```
sealed class Maybe<T> permits Some, None {
record Some<T>(T obj) {}
record None() {}
}
```
(You will probably have to write Maybe.Some and I might have messed up the generic syntax as I wrote it on my phone, but that's mostly how it looks)
First, a record can't extend anything, it's not even valid syntax, so a sealed class can't permit record subclasses. So no, it's not possible to create a Maybe<T> class in Java that can only represent a Some<T> or a None<T> record. You could do it with regular classes, or if it's ok for Maybe<T> to be an interface.
Secondly, regardless of the sealing, nothing in any current or near future of Java prevents you from assigning `null` to any class of any kind you might create. So you can always have `Maybe<T> x = null`, or even `Some<T> x = null`.
None of this will change with the adoption of value classes either. So no, there is absolutely no way in Java to create a real Optional/Maybe type that would guarantee that a variable is either an object of a given type or None. There is probably some way to do it for your specific project using annotation processors, of course, but that is very different from having built-in support.
> So you can always have `Maybe<T> x = null`, or even `Some<T> x = null`.
Yeah and? Practically every type system have escape hatches, like Haskell can also do side effects without the IO monad, does it make the latter useless?
The whole point of using Optional/Maybe is to prevent the possibility of accidemtally creating nulls. If you don't make mistakes, then nullability is not a problem. If you do make mistakes, then a class that only helps when you don't make mistakes is basically useless.
This also has significant impact for serialization/de serialization - a classic place where you get unexpected nulls, that Java Optional/Maybe don't help with at all.
Types are both for the compiler, as well as for the developer. Maybe types are implicit documentation telling the developer that it is meaningful in the application that this field can have a None state.
That's a huge code smell to ever set null to an Optional/Maybe and code reviews, linters, nullness analyzers all should/will flag such.
Like I have never ever had an NPE from an Optional being null. Sure, complete null safety would be better of course, but in this very instance it ain't buying you much.
Given the mess of some .NET frameworks currently, and how bad it has taken for non nullable references to be widely adopted, I don't see those correct decisions on the last releases.
It is all about having AI on the framework, Aspire, multiple Web and Desktop frameworks all over the landscape.
Those interceptors and inline arrays via attributes instead of proper language grammar aren't that great either.
>Those interceptors and inline arrays via attributes instead of proper language grammar aren't that great either.
Yeah. Even when they add new grammar nowadays, it's always just something that trivially sugars away into previous grammar (see: records, `with` clones, extension properties, required, etc).
The moment they need something that it's slightly more complex... Out of scope. Even when it's completely necessary for the thing to be useful in practice.
For example, they added `required`, `record`s and property initializers, giving us good reasons to write `new Foo { A = a, B = b }` instead of `new Foo(a, b)`. A and B must be positive, so you'd write:
public required int A { get; init => field = value > 0 ? value : throw ... ; }
public required int B { get; init => field = value > 0 ? value : throw ... ; }
This is pretty standard C# code that you might see in an example for records.
But then the requirements change: A and B must be positive, or they must both be zero at the same time.
This cannot be expressed at all with initializers. You simply cannot add code that runs after all initializers are called. You're stuck chasing every single initialization of Foo and using a constructor or factory method instead. Shipped it as a public API? Too bad. Should have seen it coming!
The new features are filled with this sort of thing. As if Microsoft never used them beyond the most basic examples. Or maybe they did, and explicitly chose not to fix it and solve later.
I have this idea, that since they went open source, but failed to gain the adoption on UNIX shops they were expecting, there are tons of features to try to make it cool again somehow.
The reality, and I can see this on my bubble, is that the .NET shops are mostly former Microsoft shops now saving Windows licenses by deploying on Linux.
Stuff like MAUI remains pretty much constrained to former Xamarin customers.
Thus minimal APIs, aspire, Blazor, and whatever comes up to support those use cases first.
There are some podcast interviews from David Fowler and Maddy Montaquila where they touch the adoption issue among newer generations.
As someone who works with Java on a daily basis alongside a dozen other technology stacks, let me go out on a limb and say that I believe Oracle has been a stellar steward of the language. Java has been evolving quite nicely and at a reasonable pace, all without breaking the ecosystem or causing fragmentation. It certainly has its drawbacks, but doesn't everything?
I'm honestly happy with java lang's stewardship over the past decade, this particular JEP notwithstanding (it's fine, but the good parts come later.) They're conservative in adopting new features whereas I see every other language bolting on everything under the sun with reckless abandon. I prefer the "let's see what shakes out" and adopt "the good parts" which seems to be Java's approach. Sugar like "var" from kotlin, project loom event loop like nodes, etc.
I had the opposite experience, spent a year with each language, first Java then C#, and to me C# felt like "Java done right". (Which appeared to be the original design goal behind the language!) So I'm curious about your experience.
To me it felt a bit less like a religion and more like a language. It didn't force me to do things a particular way, quite as much. (Still more than I would have liked, though! After all, it's called that[0] for a reason :)
Same for me. I have worked with Java since 1.2.2 and used .NET for something like 10 years (don't remember the versions). Most important differences are:
-Java always has an API, .NET is about extending an existing application (Servlet API vs IIS)
-Java has a nicer IO as .NET has bidirectional streams (You can't wrap streams in .NET).
-Linq is nice but has a huge caveat: if a Linq provider does not implement it fully to falls back to the .NET collections. So trying to 'Skip' and 'Take' on a ActiveDirectory will fall back to collections in memory and cause a crash on a huge AD in production (Yes had the pleasure).
-Java's Eco-system is way bigger.
> -Linq is nice but has a huge caveat: if a Linq provider does not implement it fully to falls back to the .NET collections. So trying to 'Skip' and 'Take' on a ActiveDirectory will fall back to collections in memory and cause a crash on a huge AD in production (Yes had the pleasure).
How do you expect this to work then? If the provider is bad, blaming LINQ for it makes no sense...
You either have a high level of abstraction and possible performance pitfalls - or a low level of abstraction, and also performance pitfalls since the code is less modular, more coupled and harder to read.
LINQ can in many cases improve performance significantly in large applications when used properly, since it avoids N+1 query problems due to implementation hiding/modularity, and allows composing parts of queries across different vertical subsystems of the application (vs. each subsystem doing its own query and then joining them with more boilerplate).
Nothing in Java compares to this. jOOQ and Hibernate (and the rest in the ORM ecosystem) are pale shadows, exactly due to lacking language features (such as reified expression trees), and even then, they only work with databases.
> .NET is about extending an existing application (Servlet API vs IIS)
I don't think this is true anymore since ASP.NET Core. While you can still run under IIS but it's a more typical reverse proxy setup instead of running inside IIS.
> You can't wrap streams in .NET
You've always been able to wrap streams in .NET so I'm not sure what you mean by this
Yeah, me too. Java always seemed to consider design a lot more than C# which seems to have taken more of a kitchen sink approach to language design. That stuff piles up over time (see c++)
First, huge open source ecosystem and culture. Mature open source projects, culture of writing blogs and tutorials (that one will die due to changes in search engines, but it was super nice while it lasted).
Second, working in C# felt clunky, as if every other thing was done to check the checkbox "done" and the author called it the day once it sorta kinda worked. There was some additional syntactic sugar in that language that was nice, but it did not made that much difference in practice and I don't miss it after coming back to java.
Third, I found the obsession with bashing java by people who have no idea how java projects look like and which problems they have annoying.
How .net got so many things right where java did not is a mystery to me, but appreciated (it has its own flaws, of course). Java, in my understanding, is still of core relevance to Oracle, and tied into a lot of contracts that require very little effort from them to maintain. But you are correct in observing that they want to be a datacentre/compute business more and more these days; they may have in fact overcomitted to this due to the AI craze, since shareholders are already complaining.
“In interviews and technical papers, he has stated that flaws in most major programming languages (e.g. C++, Java, Delphi, and Smalltalk) drove the fundamentals of the Common Language Runtime (CLR), which, in turn, drove the design of the C# language.”
Also, some of Java’s design warts may be there because Java was initially envisioned for much smaller devices.
This. C# was basically always meant to be "Java but done right". It came several years later, after Microsoft was legally barred from "EEE"-ing Java and required a direct competitor.
They didn't "steal" anything, iirc; they started as a legitimate licensee and then tried their usual embrace/extend/extinguish as "J++" (the EEE I mentioned). Sun sued for breach of license and won, barring Microsoft from extending Java outside of the (Sun-controlled) process. So they dropped it and built their own version, with blackjack and hookers.
But what I don’t get reading the original article is that they present how to insert struct in an object oriented language as an intractable problem, whereas a good implementation with .net (as far as I can tell) has been out there for nearly 30 years. And C# was shameless about stealing from other languages.
> how to insert struct in an object oriented language as an intractable problem, whereas a good implementation with .net (as far as I can tell) has been out there for nearly 30 years. And C# was shameless about stealing from other languages.
I think (but may be wrong) their concerns are about the insert part. C# always had structs, Java wants to add them in a backward-compatible way. They want, for example, existing generic container classes pulled in from a .jar (i.e. already compiled) to support Java value types.
Well, my old code can have a List<Object>, and I can pass my new type into it and have it do some operations. Let alone with reflection - so backwards compatibility is more complex than that.
As for structs, Java avoids e.g. tearing issues with making them immutable, while it is easy to optimize it to local modification under the hood.
Which recently decided that Go was a better option than C# for the Typescript rewrite, exactly because not all decisions were done correctly to make C# a better fit for the problem.
Go was chosen mainly because it aligned more with how the existing compiler is designed. They did not want to redesign the compiler which eliminated C# as a choice. So Go is apparently just a better fit for quickly porting JavaScript code to.
That was the original motivation yes, although they acknowledged later that the weaker type system from Go required redesigning the data structures anyway.
And as proven in the recent announcement, they had to rewrite parcel from C++ into Go, as they didn't found a comparable library in Go ecosystem.
There is also another interview, where again they mention having used AI as tool for code rewriting as well.
Also to note that it was pointed out that Native AOT wasn't up to the job, again something that both Java and C# failed not having done it properly from day one.
They said the prototyped in a few languages before settling on Go. Based on what you said it sounds like they didn't do a great job at that and stuck with their decision anyway.
> Also to note that it was pointed out that Native AOT wasn't up to the job, again something that both Java and C# failed not having done it properly from day one.
It's been working fine for a few years now. The only problem I know is there is little to no reflection allowed (by design) so a lot of code out there is not compatible with it yet. Not sure if that's what turned the TypeScript team away from it.
The mystery of why .NET got so many things right is simply that C# was built several years later by the exact same Microsoft engineers who had previously worked on extending Java, giving them a perfect blank slate to fix the architectural flaws they had already encountered
virtual thread instead of async/await is a counter example.
Java is more used than C#, they can wait before delivering a new feature (given their leader position) but cannot deliver a flawed implementation that would stay in the language forever. Glad to have virtual threads and the backward compatibility that comes with it instead a Async version of sync methods + async and await keywords all over the code and Task as a return type in my interfaces methods to allow implementations to do non blocking I/O calls if they need.
.NET had green threads (fibers) in its first iteration. They were abandoned because practical use of .NET was also FFI-heavy - WinForms etc - and native code generally doesn't play well with non-native threads. The benefit of async is that it desugars into callbacks with state, which is something that can be easily expressed in terms of the C ABI (which is the de facto interop standard on all mainstream platforms). Which is why you can have async C# code calling into async C++ or Rust code, or for that matter async Python calling into async C#. Given that .NET was historically supposed to be a multi-language runtime, before they went all in on C#, async made a lot of sense.
C# did not ship with async/await, and Java didn't have virtual threads back then. I am specifically referring to the initial choices made in C#'s foundation.
Java made several mistakes. It also made some questionable (yet often defensible) decisions. It's understandable. Type erasure was one I believe was a mistake. It's talked about in the article. Yes, you kept binary compatibility but you that created so many other problems such as not being able to use value types in generics. Notably, C# looked at that and said "nope". Type erasure is also hurting Valhalla here and the issue of value classes in generics is the second phase so is being pushed far into the future.
But a huge mistake (IMHO) was not having nullability part of the type system. You can still do this with type erasure.
Anyway, I read your comment as "nullability isn't complex" (paraphrased) but that's not the author's point. What's complex is having a value class and a regular class of every class and you don't necessary know which one you're dealing with at the language level.
C++ is a great example of this. You can create an object ont he stack or the heap and that's really what we're talking about with that proposal. And that's a nightmare. Combined with pointers it meant you never knew if you could free something or not and that ownership had to be passed around with vague comments like "// retains ownership".
Anyway, the whole article is a great tale of how difficult it is to retrofit things later and how difficult it can be to fix mistakes later (eg java.util.Date).
> Yes, you kept binary compatibility but you that created so many other problems such as not being able to use value types in generics.
This is often given as the defensible reason, but it's not even that true. Java 1.5/5 had several "breaking" changes in it regardless including the newly reserved 'enum' and a whole freaking memory model update.
And besides if any of your dependencies updated for all practical purposes you did, too, since you had to use a newer runtime to run their code regardless, it never really made sense to keep using an older javac out of spite
How would a non-nullable class field work in Java when it can be initiqlized by arbitrary imperative code that can read it while it's being initialized?
The type erasure version of this would look a lot like Hack [1]. So generic arguments would simply have a ? if they allow nulls eg List<?Point>. The list itself couldn't be null unless it was ?List<?Point>.
Now, one can argue that this is just smoke and mirrors with type erasure and it is but you can already put a Date into a List<Point> if you're so inclined because the JVM doesn't know the difference, hence type erasure. So this is no different.
I'm no JVM expert but from reading the article it seems like the chosen solution for value classes is to treat them all as a single L-type in the JVM where each primitive type is its own L-type. If I read the correctly, it means that if you have a Point value class then on the JVM level you'll be able to stuff any value class into there if you're so incline, just like with List<Point>.
Obviously we need to be concerned with fuzzing (moreso in C++) but here really we're just trying to have sensible defaults that aren't guaranteed because we can't design the language how we want from the ground up without making a new language.
Oh and there is a prosopal for this [2]. Personally, I prefer the Hack version.
> Now, one can argue that this is just smoke and mirrors with type erasure and it is but you can already put a Date into a List<Point> if you're so inclined because the JVM doesn't know the difference, hence type erasure.
And that's a massive problem that they're planing to solve with specialized generics.
> If I read the correctly, it means that if you have a Point value class then on the JVM level you'll be able to stuff any value class into there if you're so incline, just like with List<Point>.
I'm not sure what you mean. An L-type is an object reference. E.g. Ljava/lang/String, Lcom/org/CustomObject. The issue you're conflating is the erasure of List<T> to List<Object> and it's L-type Ljava/util/List.
> I prefer the Hack version
Hack/HHVM didn't have to worry about backwards compatibility.
---
The blog post does a pretty high level overview of the implementation, but my understanding of it is the following:
1. They are adding a new bytecode class flag for value classes. Bytecode descriptor for value classes are exactly the same (L-type).
2. Primitive wrapper classes will become value classes.
The difference from the CLR is that the JVM implementation is backward compatible with linked legacy bytecode. As they can accept a value class instance into their methods due to the same L-type. It's just additional metadata added to allow the JVM to stack allocate the class.
---
Separately, to handle generics:
1. Parameterized container classes will be flagged with a new bytecode to enable parametric attributes on initialization with the additional data of the parameters in the Constant Pool. Bytecode descriptor for classes are exactly the same with type-erasure, e.g. List<SomeType> erased to Ljava/util/List.
2. Initialization of parameterized classes are done with the additional metadata of the type argument stored in the Constant Pool.
3. The runtime does monomorphization of the parameterized class.
It doesn't seem too different to what the CLR does, i.e. runtime monomorphization. The difference is the JVM implementation is backward compatible with older type-erased code, i.e. the restrictions in Java due to type-erasure are exactly the same as before and the L-types don't change. It's just additional metadata added to allow the JVM to monomorphize the classes for performance.
---
In summary, value objects and specialized generics are backwards compatible with legacy bytecode. The JVM handles the compatibility. Of course, the newer bytecode is not forward compatible with older JVMs.
Look at how Go did it. Any value type has a defined 0 value, and any variable of field of that type is initialized to 0 by default. So any un-initialized non-null able value type field could have the corresponding 0 value.
That's worse than null. Now every object has an invalid state. It works for Go because Go is trying to keep language complexity low. It has no good design principles behind it other than that. Also the zero value of a reference is null so you still haven't answered how a non-nullable reference field would work.
Sorry, I misinterpreted your question to be about non-nullable value classes, not non-nullable classes more generally. For reference variables, it seems that the a priori best approach would have been to generate a compiler error if the field was read before it was written; since this ship has long since sailed with final fields, it seems that the same approach would have to be taken - the "not null able" guarantee only applies after the class is fully initialized, and you can observe it as null during initialization. This is probably not a huge problem, given that initialization code always has to deal with a class breaking its invariants, since they are only established at the end of initialization.
Regarding the 0 value choice in Go, I don't agree that this is worse than null. It simply applies a design constraint that is not usually very hard to satisfy - that the 0 value of your type must have well defined semantics.
The compiler doesn't solve the halting problem so it doesn't know whether a field is read before it's written.
If you allow a nonnull field to hold null at any point then it's trivial to leak that out and have nonnull variables holding null all over the program, which is obviously something to be avoided.
Maybe you can say that if you read a nonnull field when it's null, that throws an exception. That might have its own knock-on effects since nobody expects reading a field from a valid reference to throw an exception, but it might be the best way.
I think you should require the code to be written in such a way that the compiler can verify the value is never read before initialization. There might be some subtleties in how to do that but I don't think it should be insurmountable.
It's completely insurmountable. It basically means you can't call any functions during initialization. Including the one that creates the object you want to point your nonnull reference to.
Probably with hacks. Did you know a final field in Java can change its value? And I'm not talking about his reflection to make it non-final. With ordinary code only, you can read a final field before it's been initialized, so it still holds its default zero value. For example "final int x = calcX();" and have calcX print the value of x, it will be zero.
There's a whole bunch of specification language describing how constants aren't actually constant in specific situations.
I don't know Kotlin but I assume it does the same thing: until the non-nullable field gets initialized, it holds null and violates the type system.
Kotlin works around this by not exposing the backing field directly; a "field" becomes a "property" which has a getter and setter under the hood. Attempts to read uninitialized properties are compile-time errors. You can turn these into runtime errors using the "lateinit" keyword.
Kotlin still has a hole where you can run code in "init" blocks which are executed sequentially on object construction; in one, you can call a function that is defined after an unmodifiable property, and it will see the uninitiailized value.
Nothing stops me from sticking my dick into a blender either, yet it works fine for most of the things (the blender). Both Java’s notion of final and Kotlin’s nullability work great for 99.999 use cases and you really need to go out of your way to break them.
If you can get a null into a nonnull variable, it can propagate all over the program and people will be defensively checking for it everywhere - final is not like this.
`lateinit var` was not added to Kotlin to handle nullability, but to address specific Android design where system components like Activity cannot realisticly initialize fields in their constructors. Outside of Android it shouldn't be too commonly used.
"lateinit var" predates Android's adoption of Kotlin by years and was added because fields initialized after construction by frameworks are common in many contexts, but having nullability in the language makes that annoying.
I agree, but I have seen the previous proposals/jeps and the discourse around them is rather discouraging. I hope this one can find it's way out of Draft, but I'll only believe it when I see it.
> it is this interpretation that kills off the null-safety debate entirely. Saying you have a variable that cannot be null is not a mentally taxing distinction, especially since everything is labelled thoroughly.
I think you've missed what this is referring to. It isn't about null safety (which is orthogonal) but about having reference/value projections analogous to Integer/int.
What the Valhalla team ended up doing is, instead of having two projections for each type, one with identity and one without, value types never have identity and so Integer and int are synonymous, and the memory layout is determined automatically based on context and optimisation decisions. This is why the semantics of == for the primitive wrappers (like Integer) were changed, as they now don't depend on whether the "reference projection" or the "value projection" is used.
> There is no reason to reduce the optional(!) safety guarantees you can offer with the excuse of "too mentally taxing".
Except they're not, as I can do Integer x = null, but not int x = null. So an Integer is forced to occupy more memory, for very very unclear reasons. And this is also deeply weird - there is no other (mainstream?) language that allows null value types.
That's not quite how it works in Valhalla. Because Integer and int already exists, your declarations above will be interpreted with those meanings, but (assuming some TBD nullability annotation), they will be equivalent to `int? x` and `Integer! x` respectively. In other words, the nullability of a variable is a separate concern from the data type, and other than the different defaults on variable declarations (as these types already exist), Integer and int become the same type.
This may be true, hopefully, in a future version of Java, if the article isn't wrong. In JDK 28 with the Preview feature enabled, int is not nullable and Integer is nullable, and they are thus different types under the hood. Which also means that on most CPU architectures, Long[] will be just as inefficient compared to long[] as it was in any previous version of Java.
> int is not nullable and Integer is nullable, and they are thus different types under the hood
Yes and no, because in Java we have runtime types and compile-time types. The frontend compiler will treat these types as having different defaults on nullability, but they'll compile down to the same representation (when appropriate). I.e. if the compiler sees that some Integer variable is never null, it will compile down to the same thing it would if it were declared an int.
You're right, however, that on the heap, until the language adds nullability information, the compiler cannot generally know that an Integer will never be null (unless it's a final field), so it's likely that, unlike on the stack, you'll get a different representation.
It's not that weird. The goal is to enable existing types to be turned into value types without porting the users, so stdlibs and other libraries can mark types as value types without an API break.
That goal is an ideal and can't be reached perfectly. Converting a type to a value type will break clients that synchronize on them, or rely on identity for some reason. But such cases are rare, and can be weighed up on an individual basis when making the decision about whether to do it. Storing things in a nullable variable on the other hand is very common and changing the rules to prevent it would make every such change a source incompatible breaking change.
Nullable is just a different loadout state in Railway Orientated Programming. So, no reason to put different flavours of state into the language directly, when its a solved thing since (checks slides) 2012. There is just rails - going to A or going to B, depending on the trains loadout.
If you have language-wars about a concept going in and out of existence, that is a hint that there is demand and the language does not properly handle the demand or when it handles it, it creates mental overload.
They just decided to tackle non-nullable value types in a follow-on JEP. I don't think they're saying it's untenable. You don't eat the elephant in one bite and all that.
That said, we've been gnawing on this limb for a while...
> a single type would have two projections: a value variant (flat, never null, behaving like a primitive) and a reference variant (a box that allows null). Across various iterations this was written as Point.val/Point.ref, and later they experimented with the Point! and Point? syntax.
This seems heavier? Having two representations and manually having to refer to .val or .ref?
You can argue that the extra flexibility lets you write safer (non-nullable) code but naively it seems more complex at the language level.
I mean, I appreciate the huge engineering and design challenges here, but C# had non-null value types in 2002. It had generic value types in 2005 and it gained not-null “types with identity” in 2019 and no-one has batted an eyelid. (Indeed the type system support for value types still includes stuff Java isn’t even considering yet.)
Saying the mental model is too hard is basically saying your userbase is stupid. This stuff is not tricky.
> But the difference in memory is fundamental. The JVM can now store the values themselves in the array, laid out densely one after another: 8 bytes per point (plus a possible null flag), in a contiguous block. No headers per element. No pointers. No jumping around the heap.
How much was this article proof-read? Didn't they just get finished talking about how heap flattening won't work for objects with > 64-bit representations? Their `Point` is at least 65 bits (two 32-bit ints plus the null flag). The "plus a possible null flag" and oddly short following statements seem to suggest this was some AI that got sidetracked by trying to make emphatic statements... oh and also the "[IMAGE: the same Point[] array in two variants..." block halfway down the page is unfortunate.
> No headers per element. No pointers. No jumping around the heap.
that smells of AI [1], and thus lazy writing. I'm all in for using AI to help you write, but if you don't put your voice to it then there's no reason to read it.
Don't be all-in. It's important for humans to be able to write for themselves, and also to stand by what's been written in their name, which is much less likely if someone/something else has done the writing.
I learned that exact style of writing in a marketing workshop, pre-AI. It's effective, satisfying, and a random third thing I can't be bothered to come up with right now.
As a proportion of all easily crawled text on the internet, a lot of it will be random marketing copy. That influenced the writing style of early AIs, and since then everyone has trained at least partially on transcripts from every other AI chatbot
Thank you for sharing this. It brought together things I had suspected but not from his perspective. Also pleasant to read something that used rhetorical devices in a cohesive way instead of just as sprinkled on flavor packets.
There was nothing inadvertent about it. A decade of cultivating and harvesting millions of examples of this kind of pseudo-writing from underpaid internet piece-workers preceded LLMs.
Exactly! But AI is here to stay. Sooner or later, even comments on HN will be 100% AI generated. And we won't be here to read them - our AI agents will. /s
That’s right. Because at some point, the volume of AI-generated posts and comments on sites like Hacker News or Reddit will overwhelm the ability of humans to read them all. So the only reasonable way for humans to participate will be to have our own AI readers summarising them, and posting furiously on our behalf!
I really wanted to read this, it seems like a really interested subject. I can even forgive the AI generated images. But after a few paragraphs it became clear this was either fed through an LLM or worse.
Please, if you write a technical blog, or anything really: Stop. Stop letting the AI write for you. Nobody wants to read this.
Especially because signed integers aren't symmetrical. Reserve INT_MIN and you get 8 billion NaN values and multiplying by -1 always gives you a valid location.
Ah, INT_MIN. If I had a nickel every time I saw an implementation of inttostr/strtoint that don't properly handle it, I'd probably have about $5. So I too thought about possibility of it serving as a NaN of signed integers... but I doubt we'll see it any time soon.
Also, apparently, shifting a negative number to the left is UB in C.
Java has always had this juxtaposition in language design where they don't want you to think hard about value types (hence no unsigned types), but the types themselves are precisely defined down to the specific bit pattern representation in bytecode. This is essentially hardcoded into the JVM and its bytecode specification and is too hard to change for compatibility concerns.
Luckily we have Valhalla, which is an admission that Gosling was partially wrong, and programmers who want to have an unsigned nullable non-zero 64-bit integral value type can just make one, and not have to pay outsized memory costs to do so.
If we're done paying homage to Gosling, can we get operator overloading for our fancy value types please? I have no idea if this is on the radar for Valhalla.
In many cases, NonMaxU64 and NonMinI64 (aka SymmetricI64) would be much more useful though. But Rust is aiming to eventually add a more general way to create types with user-defined ranges, such as the "pattern types" feature currently being prototyped.
> On June 15, Oracle engineer Lois Foltan confirmed what a good chunk of the industry had stopped believing: JEP 401: Value Classes and Objects will be integrated into the main OpenJDK repository and is targeting JDK 28.
> The change is so large that the remaining committers were asked to hold off on bigger commits during the integration. The pull request alone adds over 197 thousand lines of code across 1,816 files.
These days I'm having second thoughts about pictures that I am pretty certain can't be AI but just have that look. It's strange but I've noticed it happening more and more.
I mean I’m only answering that because you’re asking, nothing set me off personally there, but now that you ask:
« The pull request alone adds over 197 thousand lines of code across 1,816 files. »
I noticed that both Claude and GPT are fond of those kind of stupid accounting statements that don’t mean a lot in and of themselves, but look impressive in a « wow numbers » way. Which is kind of ironic since counting remains one of their weak points
Yeah its definitely inconsistent level of specificity. It's "roughly" 197 thousand files, and yet at that scale a human would call it 200 thousand lines of code, and then an exact count of files at 1,816 instead of a similar level of estimation.
For instance I might write this "The pull request alone adds nearly 200 thousand lines of code spanning almost two thousand files", or even better just "The pull request alone adds nearly 200 thousand lines of code" because really who cares how those are broken up into files.
As a human (as far as I know...) there is a decent chance I'd write it like that, depending on the exact numbers.
It said "over 197 thousand". That's what I'd probably say for a number in [197000, 197999], or maybe "under 198 thousand depending on where it is in that range.
Saying "nearly 200 thousand" is still 3 digits so doesn't save any space over 197 or 198, and I think with it only being 3 digits most people will assume only the last digit is rounded. 200 ending in a string of 0s does suggest it might be rounded to the nearest 10 or nearest 100, but it just could easily not be.
I'd almost certainly fully write out 1816. If it were common to spell out groups below 1000 like 100s and were going to that I might write it as something like "just over 18 hundred" or "almost 19 hundred", but I almost never see anyone use grouping sizes of less than 1000.
I understand ai hate but I would rather avoid a future where everybody talks in purposely weird and unstructured sentences to avoid being similar to ai
By necessity a lot of people write very similarly to how llm do
No, it’s not the only important thing. The complaints about it should tell you that.
People care about provenance a lot.
Whether it’s a drawing my daughter did of her mother, a Picasso napkin sketch, a worn 1960s Stratocaster, or an blog essay, the provenance is value on top of the correctness of the item.
> Didn't they just get finished talking about how heap flattening won't work for objects with > 64-bit representations
In this initial commit. As was made clear in the JEP, this is just the first deliverable of a huge feature that, like all Java features in recent years, is being delivered piecemeal. Obviously, the point is to flatten larger values (the mechanism is already in the JVM; what remains is exposing the intent of "I allow tearing" in the language).
I'm confused about the 2008 Bloomberg article image in the first slot... right after implying the effort started in 2014. With nothing mentioning anything in there.
Is there a way we can request a "flag as AI garbage" downvote for articles? Or should we just flag them?
After reading a lot of comments in here, there is one thing that always repeats itself in Java/JVM-related comment sections on HN. There are a surprising number of people who have an idea of what the JVM or Java used to be and have very little idea of what it is today. It is a very fit predator in 2026. Does it have its warts? Yes, but the substrate is extremely good.
Agreed - you don't get great JVM takes on HN, it's out of fashion here.
Our work uses modern Java (26 w/ preview features - mainly for StructuredConcurrency), and it's fantastic. Do not regret it one bit, and that's coming from using both Haskell and Python at previous companies.
Many of us work on Java monoliths that started in the 2000s when it was in vogue and we still have to keep them chugging along on Java 8. Personally I'm familiar with all the new features that have come out in the last few years, but for my actual work, java is literally stuck in the past.
The problem in a large codebase is keeping consistency when upgrading.
I upgraded a codebase of approx 100 kloc from Java 7 to Java 8 a couple of years ago. As I didn't want mixed patterns for the same thing throughout the code base I replaced most of the loops with their streaming equivalent. I had the luxury of having the budget for doing so.
Mixing patterns of newer language features alongside older ones can make the code base hard to read.
In this sense, Java is already the next Cobol. I usually ask one or two questions about class loading in interviews (of senior Java devs), the younger ones are frequently stumbling upon these, and they don't even understand why I'm asking this. Good old Tomcat days, when you could run out of PermGenSpace if you weren't careful :)
Good news is, Oracle extended extended extended support for Java 8 will not last forever, and eventually - if you work in a regulated industry - the company WILL have to pull the trigger.
On the other hand, "where there is muck, there is brass", so a little bit of legacy can be beneficial for some.
Yeah, that would be a more nuanced take. The comments I'm indirectly referring to are people who are literally unaware of these features and talk confidently as if they do not exist.
A lot of the comments on here are a bit unfair on what is great work being done and even more awesome work (JEPs) in the pipeline for the future.
If Java was a child, imagine it being brought up by loving parents for the first few years (Sun) then it was thrown in a garage with some other children and neglected by its evil guardian (Oracle)
Neglected and unloved till JDK 8, its basically been playing catch up.
So when people say "oh so its now got structs or value types of X", yes it has but that's because it has been stunted in its development due to big bureaucratic and hostile corporate processes, but its free now and is getting love through the OpenJDK family.
I will continue to enjoy writing once and deploying anywhere!
> If Java was a child, imagine it being brought up by loving parents for the first few years (Sun) then it was thrown in a garage with some other children and neglected by its evil guardian (Oracle)
Whether you like oracle or not, this is simply not a correct description of Java's history. It was brought up by loving parents, who due to financial problems had to put Java into a foster home where she was neglected.
But later it was adopted by new, loving parents (Oracle) and she bloomed and become a healthy and stable adult.
Like, it was Oracle that completed the open-sourcing of the platform, making OpenJDK the reference implementation. They also open-sourced the previously proprietary jfr, mission control etc tools.
They also managed to keep many of the original members of the language team, which is quite rare during these acquisitions, and Java has seen a huge improvement both on the language and runtime front.
Well, Oracle may have done fine, but IIRC open sourcing the JDK was Sun's very penultimate move on its deathbed. Oracle inherited the license to the trademark, but the actual JDK was already free.
It was neglected during its last few years at Sun. Oracle started moving it forward at never before seen pace, while mostly maintaining backward compatibility (unlike .NET that "did things right from the start", which is what .NET Framework/.NET Core/.NET split/rewrite is according to some in this very discussion. And .NET had Java to copy and learn from, but still fucked up.)
Same with MySQL, btw. "Dead" according to this site, risen from the dead under Oracle for those who actually know it.
I have no idea about MySQL, but what I always remind people is that HN is more GQ/Vogue than the NYT. It focuses on novelty and aspiration more than on coverage of what the industry is actually doing. Like others, I enjoy it because it's aspirational/inspirational, but I try not to confuse it with a reflection of reality. E.g. there's little correlation between programming languages that are discussed a lot on HN and those that achieve (or don't achieve) big and long-lasting success.
In fact, much of the software industry, which writes the software that matters to our lives the most and holds most of the value delivered by software in general - the software that processes your credit-card transactions, runs your bank, sorts your mail, routes your phone calls, manages the manufacturing of your car and the shipping of your packages, holds your healthcare information, schedules and tracks your flights, and manages your law enforcement and your government - is barely represented here because the organisations that write most software aren't software companies, and they don't tend to publish technical blogs.
I don't think the issue is nuance. The issue is what people enjoy talking about. E.g. here's what the industry probably looks like in terms of how many people work in different languages: https://www.devjobsscanner.com/blog/top-8-most-demanded-prog... Now compare that to the languages most frequently talked about on HN. The stuff on HN isn't a reflection of the industry, just like Silicon Valley doesn't produce most of the world's software (or most of the world's software value).
People come to HN because they want to hear or talk about things that most people don't usually do; it's more interesting because it's different! I'm not saying they always say positive things, but positive or negative, this is what we like talking about online. This is why people buy GQ or Vogue. If you want to talk about boring work stuff, talk to people at work :)
> If Java was a child, imagine it being brought up by loving parents for the first few years (Sun) then it was thrown in a garage with some other children and neglected by its evil guardian (Oracle).
> Neglected and unloved till JDK 8, its basically been playing catch up.
These two statements are contradictory. The last Java version under Sun was in 2006. Oracle bought Sun in 2010. JDK 7 came out in 2011 and JDK 8 in 2014.
The team largely remained the same, and the main difference was that Oracle ended the neglect and funded us more, which is why Java picked up the pace after the acquisition.
> its basically been playing catch up.
Catch up with who or what? There are only two languages in the world as popular as Java or more: JS/TS, and Python. People who are saying Java is "playing catch up" usually compare it to languages that are doing far, far worse than Java. It's just that people who like certain features think that the language that has them is doing poorly despite them and not because of them. Many times I see people insist that other languages are "doing it right" (or better than Java) even though it is clear that the people who say this are in the minority when it comes to preferred features.
> So when people say "oh so its now got structs or value types of X", yes it has but that's because it has been stunted in its development due to big bureaucratic and hostile corporate processes, but its free now and is getting love through the OpenJDK family.
If anything, the opposite is the case. Managers love to see things ship quickly. It is our technical leadership - all people who were there in the Sun days - who insist we have to move deliberately and carefully and get things right. You can agree or disagree with the decisions, but comparing Java unfavourably to languages that are doing far worse is unconvincing.
Rather, what I think the vibe is because Java is not as popular as it was in, say, 2003. And it certainly isn't. But guess what? No other language is, either, because that time was anomalous not only for Java, but for the entire software ecosystem, which had never been as consolidated and unfragmented before or since.
Yeah. I agree. As a C# fan I discovered one day the change process and release notes. Like C# it does still have strong momentum in the language design space. It was a joy observing the last 10 releases.
Serious question: I remember the old installer, six billion devices or whatever. I’ve heard about Java ME, old set-top boxes and DVD players, etc.
But how much of that is active today. I can’t say I’ve ever seen a job listing for an embedded Java developer or even Java ME in my entire career. Are people actually still using it?
To take your analogy further, not only was it thrown in the garage, but it was used to sue for billions of dollars in child support (Google) so really it had just become a cash grab.
Anyway, I wouldn't even call Java "stunted". It made choices, some reasonable, some not, and those are incredibly hard to fix later. Heck, just look at C++. Semi-compatibility with C is (IMHO) an unfixable 150 foot albatross around its neck and so many versions from C++11 onwards have simply been about making that 150 foot albatross more bearable.
I personally think treating all value classes as a single L-type in the JVM (like primitive types, basically) is a fairly neat solution to a difficult problem. But all this comes down to the original Java 2 decision to implement generics as type erasure to maintain backwards-compatibility, something that C3 NOPEd out of as a result.
You could probably a whole tech thriller on the evolution on Value Types in Java.
I’ve been reading the mailing lists and watched all videos on the topic and it is truly inspiring how much they managed to consolidate the design to something that always looked like java.
But while also going far deeper in granularity and understanding what it even means to be a value type and what optimizations can be done where
> But careful: == looks at internal state, which isn’t always what the object represents, so for “is this the same data” comparisons keep using equals.
So == for value classes will basically be like memcmp(). That is a bit unfortunate, as it breaks encapsulation, exposing implementation details. Client code can use this to do case distinctions based on how a given value is internally represented. In a way, it’s worse than identity comparison, because identity comparison at least doesn’t expose internal state.
Value types are a concept very far away from the "magic black box organism" school of OOP thinking. It's not a novel way of doing classic OOP (does anyone still do that?), it's a way for a language born in OOP ideology get one step further into the post-OOP world.
That’s just not true, you can have a completely value-based language without OOP that still doesn’t leak implementation details of the values, while also supporting UDTs.
OOP isn't just about values vs objects. Yes, the idea that everything needs identity is a big part of the problem. But another big problem is the idea that the implementation and representation of types should be hidden by default. The mindset that there isn't a known and useful data representation for a given type. That everything is done by methods parameterized by a type. It's a misguided idea. There is a place for objects and implementation hiding. But the idea that this should be done on a type granularity is a complete and utter failure.
To see why, consider that to do any useful work, data from different objects (also from different types) has to be combined. To be able to do that in the OOP framework, the encapsulation has to be unwrapped. That's why Java code is littered with getters and setters that don't do any useful work at all, they just make it too painful to get any real work done.
Again, there is a place for objects and implementation hiding, but it's at the highest levels of an architecture where different components get integrated.
All of this would be valid, except that value classes still pretend that their fields can be private.
This also has huge implications in a language that emphasises dynamic loading like Java. And it also flies in the face of all of the pretenses that ABI compatibility is sacrosanct and no feature that breaka it can be considered, that the design team often touts.
Why pretend? "private" on value types just means nothing to see here except when you happen to be one of the functions conveniently namespaced with the struct.
But I'd say that GP's complaint about inequality leaking makes no sense anyways, because what could be more unequal than different implementation, or different internal state implying different behavior down the line? The public subset isn't some arbitrary interface that could have different implementations. And even then, "equals under interface I1" would have to be considered a very special type of "equality", not the general case.
I wanted to comment on this as well. The article mentions it but if you've never used Java in anger (is there any other way?) then readers may not understand the true implications of this because it's a breaking change, something Java rarely does. I'll explain for the non-Java people.
Java separates checking identity and equality for objects. == basically checks if two pointers are the same. Equality is a subjective concept based on an interface (ie equals/hashCode). So this means:
new Integer(1000) == new Integer(1000) // true, used to be false
new Integer(1000).equals(new Integer(1000)) // true
new Integer(10) == new Long(10) // compiler error, used to false
new Integer(10) == new Integer(10) // true
There's a lot going on here. The complication is that in previous versions of Java (and I'm not sure when this changed), integers below a certain value would be replaced with canonical types below a certain value. I think it was 128 but its's been awhile. This led to the difference between 10 and 1000. That's now changed, I suspect because the above comparisons are being implicitly unboxed. That didn't used to happen either. I saw this because the Integer/Long comparison used to return false and it's now a compiler error so there must be unboxing going on.
You may still be able to get the old behavior through variables too.
Anyway, if value classes lose identity then == changes from pointer equality to bitwise equality. That will hopefully resolve a bunch of corner cases like this but it is a breaking change, technically.
Before value classes this would always be false. The only time comparing Integer objects with == could be true is if Integer object was create by going through Integer.valueOf (or obviously if they were the same object reference.) By default the cached values where -127 to 127, but that is tuneable at runtime.
It could also be true if the instances were created through auto-boxing (e.g. arrayList.add(10); arrayList.add(10); arrayList.get(0) == array List.get(1) //would return true, but false if you used 1000 instead of 10).
Yes, because auto-boxing is just compiling to Integer.getValue under the hood, the bytecode for Integer.getValue(1) and ((Integer) 1) is the same. They'll both compile to something like:
it's easier to remember that it originated from the Byte range, where all bytes could be kept in. Character didn't have negative values so it did [0-128) instead. Long and Short are the same as Byte.
Years before the autoboxing/Integer.valueOf() caching stuff (and before generics), (I) used to have IntegerProvider that did similar stuff to higher ranges. Personally, I have considered autoboxing on integers net-negative for Java
If your bags of data have internal state, there's something wrong with your bags of data. I assume that the Java guys thought far enough to either exclude padding from comparisons or force padding bytes to be zero.
It should work even for strings: They will surely continue to be heap-allocated, and memcmp-ing pointers (inside the new "structs") is exactly an identity comparison.
There’s nothing wrong with having non-normalized representations, that’s why there is equals().
For example, you might have a value class for representing (limited-precision) fractions using two longs internally, for the numerator and denominator. For efficiency trade-off reasons, you don’t want to always shorten the fraction. But now client code can distinguish 2/3 from 4/6 using ==.
Scenarios of that sort are conceivable where this actually leaks sensitive information. In any case, it creates dependencies on implementation details where you don’t want to have them.
When designing a value class, you are now in the dilemma of either always having to normalize the representation, costing performance, or having your class be a funnel for leaking implementation details.
Java can also distinguish a 2/3 object from a 4/6 object using == when they are not value types. It can even distinguish a 2/3 object from a different 2/3 object.
The difference, as I tried to explain, is that identity comparison does not expose the internal representation. So while you can know that two objects with the same value are different objects, you can't know whether they internally represent the value as 2/3 or 4/6. With value classes, however, the latter can expose information about the provenance of a value.
Well. I'd be upset if custom operator==() for plain-old-data structs was removed from C++, but Java never had it to begin with, so for Java, it just means that you have to fall back to using traditional classes (or compare using something other than ==) if you need such "fancy" features.
> we want the JVM to be able to treat them as efficiently as primitives.
They want basically to solve the main Java design flaw with (almost) everything is a reference paradigm. C++ and Rust have had value-types from day one.
> 64 bits, including the null flag
So, this basically makes every value-object optional, adds extra overhead and makes code less safe to null pointer dereference errors.
> but a class with, say, two int fields or one double may not fit in an atomic write and end up as an ordinary object on the heap anyway
So, the whole optimization is applied only for very small structs with no more than two scalars (or so). Did it worth to spend 10+ years of development to achieve this?
I'd really like to see someone trace related developments in C#, Swift, Java, and Rust, since they all have been racing to catch up to hardware, and I believe they are cross-pollinating.
(My concern is how all this will affect the FFI memory shares.)
Not sure I would call them the same - not too familiar with Swift but for rust you probably mean types implementing the Copy trait?
But Java's value types are a higher level semantic feature, these objects may do a Copy or a Clone based on heuristics. So probably not the exact analogue but of course rust being a lower level language it can express where and when memory is allocated.
C# actually has a fair amount of gotchas and Java aims to make these explicit. So where C# mostly copied C from a low level perspeCtive, the Java guys approached this high level and analyzed in detail which constraints give you what kind of benefit.
So where in other languages, the struct/class taxonomy is binary, Java allows more granular control, reflection the semantics of the underlying domain. Snd as it turns out, structs have a wide range of footguns, especially in a parallel context.
Part of the reason Java hasn't reified generics is because C# did and it was a real big headache that also limited non-C# languages on the C# runtime (CLI?). Everything had to be recompiled to work with newer C# runtimes. While it's pretty easy to run a bunch of language on the JVM (Javascript, python, ruby, clojure) doing the same for C# is somewhat a nightmare, particularly for non-type aware languages.
For example, Imagine you have an api like `void do(List<Foo> foos)`. In the erasure environment of the JVM that looks like `void do(List foos)`. From python it's pretty easy to call with a `foos = [Foo()]`. But not so much if your python implementation needs to figure out how and if it can coarse it's `List` type into a `List<Foo>` type.
I don’t think that’s the case. You can absolutely implement a type-erased language on top of the CLR. Your language will just have the same constraints of a type-erased language like Java.
Having reified generics in the CLR just lets you store more type information. There isn’t much of a trade off for CLR end-users.
Compare this to the constraints and workarounds that Kotlin and Scala have due to type-erasure on the JVM.
Not necessarily. You can ignore the reified generic system in the CLR and monomorphize it in the CIL output for your language. Debugging for users is usually a nightmare though due to the monomorphization. The benefit of a type-erased runtime is the interop between the languages built on the runtime.
The monomorphization of CLR generics is what NativeAOT does, though it doesn't support some C# features.
TypeScript is essentially C#, but with type-erasure and lacking the low-level struct & pass-by-reference features.
I do think the C#/CLR struct implementation is better though.
I mean, the language is what it is. But, it definitely constrains the language developers. Especially when considering interop with other JVM languages.
That being said, it is easier to write a language on top of the JVM with good interop, since there are less ways to implement features. Essentially, your language has to interop with Java.
And it is harder to have good interop between CLR languages because there are more ways to implement features. Essentially, your language has to interop with C#.
The DLR is just a shared library. It never changed anything about the CLR under the hood nor did it change anything about how Generics worked in the CLR (being the most relevant part of the thread here). IronPython could instantiate Generics just fine, and did just fine working with them.
The DLR is not "abandoned" so much as "complete". Everything did survive the transition into modern .NET and IronPython 3.4.2 runs just fine on .NET 6+ [1]. (For those trapped on the ugly side of the Python 2/3 split, even IronPython 2.7.12 runs on .NET 6.) Most of the "magic" of the DLR is shared with C# Linq in interesting ways (the System.Linq.Expressions AST) and sort of "has to survive" if only to properly support IQueryable<T> (and wilder relatives like IQbservable<T>, the Q is not a typo) even if most people aren't actively using DLR languages today (nor that much usage of C#'s `dynamic` keyword).
IronPython is a community supported (truly open source) language so doesn't get as much attention now as it did in the brief "first party" support era, so some may call that "abandoned" but F# has always lived in that gray space where it is primarily "community supported" more than "officially supported" by a dedicated team at Microsoft.
IDynamicMetaObjectProvider mostly just caches and returns System.Linq.Expressions for various asks, so again most of the JIT awareness is still just System.Linq.Expressions awareness.
The COM support is by implementing IDynamicMetaObjectProvider in a cross-language reusable base class.
The C# `dynamic` keyword adds some smarts about IDynamicMetaObjectProvider to the C# compiler, but those smarts were never seen to be needed as a low level tool in the CLR itself. And again, once the C# compiles the IDynamicMetaObjectProvider calls, those mostly just result in System.Linq.Expressions for the JIT compiler to optimize in the same way it optimizes other usages of Linq.
Yeah, that’s a different issue. Statically-typed languages, including type-erased languages, are fine on the CLR. Dynamically-typed languages are a different beast.
I suppose DLR would be comparable to GraalVM/Truffle.
The difficulty of implementing a dynamically-typed language directly on the CLR and JVM are about the same. Though, it would probably be more efficient on the CLR with access to lower level operations for memory management.
I think an interesting project would be to implement a CIL interpreter on GraalVM.
DLR inspired the addition of invokedynamic opcode on the JVM, which is actually the foundation for how lambdas get generated, many still think nested anonymous classes are used.
GraalVM already handles LLVM bitcode, much cooler than plain MSIL.
And here there is another example where Java ecosystem ends up being better.
MSR had a compiler framework similar to GraalVM, called Phoenix, it was going to replace VS, LLVM style, instead it died and what is left are a couple of research papers.
The class gets generated to capture the `s` variable. Indy gets used in the `filter` method because the incoming lambda or method reference could be several types of method calls. For example, a constructor, an instance method, or a static method (I believe there are few more in the JVM bytecode).
What won't generate a new anonymous class is this sort of lambda
stream.filter(i->"foo".equals(i));
That will generate a new method on the parent class which ultimately gets called. Since nothing is captured it can be directly called without a new instance being created.
I was wrong, it looks like the case I gave is one which doesn't result in a new anonymous class being generated. Instead the lambda metafactory gets involved to avoid that allocation.
I apparently didn't see what I thought I saw. I thought that I had seen new `lambda.$1` classes being created in call stacks when debugging. Maybe I did, but the lambda was serializable (we have that in some unfortunate places in our code base).
There are still cases where new classes get generated, but that's pretty much just for serialization.
I've been let down by structs in C# repeatedly. First of all, there are no constructor guarantees and you can never fully avoid them representing an illegal state. Which, wouldn't be so bad if there was some kind of post-construction validation, but this also isn't part of the language.
This is fine if you hand-roll all your code yourself, but I often use mapping libraries to lower the code footprint and the problems resulting from schema changes are subtle and fly under the radar. This is different from classes with hard construction guarantees, which Java would offer with their "integrity by default" mantra. Where you can opt out of integrity for performance benefits (which is also part of the design).
And Nullability in C# is an absolute nightmare. The type system has completely different rules for nullable types that generalize over classes and structs and there is no generic such as a "Nullable type".
It's just lots of minor annoyances that don't form a cohesive whole.
I hate to say it. But thats user error. The struct paradigm is different from classes. Structs are meant to be plain-old data types; simply a typed span of memory.
Structs are values, classes are entities with encapsulation.
The shape of the state would be structural. Whether or not the data in that shape is valid is behavioral.
Structs are useful when working with spans of memory.
Another example of a good usage of struct is Guid, which is 128 bits of data packed together.
The C# equivalent to Java ‘value class’ would be a class with a struct encapsulated for data. The data is flattened and allocated on the heap like Java. Similarly, escape analysis could stack allocate the class at runtime.
This is what makes the nuances of Valhalla's Value types so compelling. The idea are granular structs with "Integrity by default", where you can selectively give up constraints on class design to get performance characteristics.
Structs in most languages simply bunch a couple constraints together to get another set of performance benefits, but there's no law stating that they couldn't be singled out. In the design of Valhalla, it states that types can come in 4 buckets:
2: Value Based classes (no mutability, but full integrity and dense memory layout)
3: Implicitly constructed values (forced empty default constructor for swift bulk array initialization)
4: Tearable Values (No cross-field integrity during runtime for parallel access)
And I bet that for a vast majority of developers, #4 will come to a shocking surprise, thinking "values are threat safe" because they are told to use immutables.
This way of splitting up structs is the real interesting part of Valhalla, but this shitty AI-generated article buries everything interesting.
Imo #4 is why it’s not that useful. If the data is larger than an atomic read/write op the data isn’t flattened and it’s a regular object with value equality and immutability.
You have to opt into force flattening, and then it’s the same as a struct, except it’s still heap allocated without escape analysis. You still have to implement synchronization to prevent tearing.
Static code analysis can give you a warning for potential tearing of structs.
DotNext.Threading provides Atomic<T> to enable high-performance atomic operations on structs without heap allocation.
The design of value classes just seems counteractive to its purpose: memory management. If I want to manage contiguous blocks of memory, let me manage contiguous blocks of memory. If I want to allocate something on the stack, let me allocate something on the stack.
The paradigms of struct vs object are too different and they’re trying to combine them into one.
It is beyond me why I would get downvoted for legitimately pointing out shortcomings. I find it honestly frustrating how some people believe that “their language is best”. Until you point out real existing inconsistencies…
Why would you presume the parent is "just handwaving"? It's odd how people in the .NET community struggle to earnestly engage in conversation with Java folk. The reverse isn't true.
Like @layer8 said, pass by copy and pass by value are the same.
C# copies C++ behavior where you can pass a struct by value or reference, and you can mark the parameter as readonly. C# also has in/out parameters. Essentially, you can program in C# exactly like you would in C++.
The footgun with C# structs are that you can accidentally box them onto the heap. To avoid that you can define `ref struct`s that cannot be boxed. `ref struct`s follow the C# disposable pattern.
I don’t see a difference between pass by copy and pass by value.
The mutability difference is that part of a struct can be modified in place, which value classes can’t: the value of a complete value-class variable (or array slot) can only be modified (reassigned) as a whole. This is presumably because object references to value-class objects can be created, and those objects should be immutable so their identity doesn’t matter.
My point is that pass by copy and pass by value do the same thing, they copy the value representation. In other words, pass by copy means exactly pass by value.
Actually, Java only has pass-by-value, even for reference types. (The same way as C does).
People really misuse/misunderstand this term: Java objects are passed by their pointers ("references") being copied.
The alternative is pass by reference, which is done by e.g. c++, rust, who actually have references (Java doesn't). A good litmus test is whether you can write a swap method that actually changes your local variables.
I think that's mostly a semantic difference - Java avoided the problem of strange lifetimes, captures, tearing by fixing the semantics as immutable value objects, while C# has to deal with these issues.
But under the hood it can (and will) do a modification in place.
The C# equivalent to Java ‘value class’ would be a class with a struct encapsulated for data. The data is flattened and allocated on the heap like Java. Similarly, escape analysis could stack allocate the class at runtime, and they can be scalarized like C# structs.
Java ‘value class’ only flattens if the total size of the class data fits within an atomic read/write op. You can force it to flatten, but you may have tearing like C# struct.
The ramifications for backwards compatibility is that the JVM won't have CLR features such as stackalloc (allocation of blocks of memory on stack), ref parameters (pass-by-reference of stack allocated value types), and all the other low-level/high-performance programming features available in the CLR.
Why couldn't it be done? Like sure, it won't happen in every case (e.g. too big value classes), but for a typical local variable of a value type, it's a trivial optimization to make it stack allocated. Even now it happens quite often (requires escape analysis), but the semantics change of value classes allows for it to be done "freely".
C# stackalloc returns a ‘ref struct’ which has certain restrictions and would be a Q-world type.
Java chose to go with an L-world implementation where everything is still a reference type on the heap, but memory management is more efficient via flattening. That’s why it’s a ‘value class’ and not a ‘struct’.
Primitive wrappers are scalarized into registers.
Stack allocated value types would have different semantics and is incompatible with the L-world implementation. Sure, they could implement it, but it would be the Q-world implementation that they decided to forego.
They can do automatic stack allocation for optimization via escape analysis as you mentioned. But, stackalloc is user allocated.
Functionally they don't - java is just catching up with (by now) ancient practice.
The false dichotomy of
> A struct in C# has identity and mutation, so the semantics of copying on assignment or passing have to be precisely defined, which gives a heavier model for the programmer and less freedom for the runtime.
Doesn't really match with what they're describing. While yes, it will not have identity in a java class ref sense, it of course will still have identity in being a unique structure in memory at a certain address. This is just splitting hairs about Java nomenclature.
> it of course will still have identity in being a unique structure in memory
No, it will not. The design allows multiple objects to share one structure in memory across multiple records, or not have such a structure at all (see Scalarization in the article).
I don't wanna badmouth Java people, but how they push the idea that this thing is some sort of genuine breakthrough that took multiple PhDs years of cutting-edge research to implement, when in fact they basically copied what .NET did from basically year 1, is not a good look.
Again, not trying to turn this into a .NET vs Java thing, I'd have been much happier if they reached some new and interesting conclusions.
Well, it is - because they had to make it with almost perfect backwards compatibility for one of the most popular languages with trillions of lines of code produced over decades.
Sure, adding it to a new language is not hard. Adding it to Java which has primitives, generics and boxing, finding ways that seamlessly cover the differences between objects and primitives, while trying to plan for the future is hard.
As a general note, if you come to the conclusion that one of the best designer teams on Earth "basically copied what .NET did from year 1 is not a good look", then maybe your mental model needs adjusting on how these stuff works? Java has a public mailing list, you can browse through the related discussions. Implementation is the least of these things. But I can assure you they most definitely know what they are doing.
> because they had to make it with almost perfect backwards compatibility for one of the most popular languages with trillions of lines of code produced over decades.
At what cost? A key benefit of value types is improved performance but AFAIK Valhalla doesn't even let you pass them by reference. Efficiently passing them through registers is great but won't help you out with larger value types.
Correct me if I'm wrong, but Rust editions are a source code-level feature. So given you have the source code of newer and older rust code, you can compile them together.
That's materially distinct from Java's model of basically dynamic loading already compiled class files. Though class files do have "editions", and there are extra code to deal with different versions. But still, it should be possible to e.g. send a new value class to an old library's class that has never heard of them, and that should just work.
The important thing is that Rust editions affect semantics and name resolution. In such an analogy, JVM bytecode is the equivalent of Rust code - various semantics are baked in, but stuff like name resolution isn't (at least not completely).
Except of course they are breaking backwards compatibility, in relatively subtle ways, for anything that uses the standard library wrapper types. So every use of Integer, Boolean , etc is an opportunity for either a compilation error or a runtime bug.
>I don't wanna badmouth Java people, but how they push the idea that this thing is some sort of genuine breakthrough that took multiple PhDs years of cutting-edge research to implement, when in fact they basically copied what .NET did from basically year 1, is not a good look.
Oversimplifying a big semantic and backend change to a huge codebase on which some of the most crucial customer and government and business systems depend on, and which has to be made as seamless, correct, and performant as possible, to "they just copied .NET", just because .NET has the same functionality, is an even worse look.
It's a "HN "Dropbox is just rsync + some scripts"-style bad look.
This is exactly what made it so difficult. It is much easier to have a feature like this from year 1 than to add it to a language that has grown and evolved for 18 years already.
I agree with this sentiment. The work they put in deserves a lot of respect, and took a lot of effort, no doubt. It's just the framing they push to the public that could use some work.
Footnote 6 "How is this different from struct in C#" is inaccurate. Since the article is littered with AI-generated images, I assume the writing, or at least the research, is littered with hallucinations?
> [IMAGE: the same Point[] array in two variants: “before” (an array of arrows → scattered boxes with headers) and “after” (a uniform strip of number pairs)]
The `Point[]` in the image tag of your LLM output crashed your image generation post processing.
As I understand it, this is anyway an extremely limited perf enhancement - for any class whose data size isn't guaranteed to be atomically writable on your CPU, after including the nullability overhead, it doesn't do anything, basically. On a CPU where 64 bits is the max guaranteed atomic read/write, even Point[] will not get optimized, since you need at least 65 bits of memory for a point value (since it has two 32 bit int fields, and it needs an extra bit to specify if it's null or not - so in practice it will take up 72 bits at the very least, possibly more with alignment requirements). But even after fixing this, if you have 3D points or if you need 64bit coordinates, your value type 3DPoints will still be individually heap allocated and your 3DPoint[] will store pointers to them, just like today, on most processors.
Given that the JVM could already do escape analysis and allocate regular classes on the stack in certain scenarios, it's very unclear what benefit, if any, this will bring for normal processors for anything except the base wrapper types - even after implementing generic support and nullability for value types in a future JVM.
The core insight there is to separate value semantics (no identity) from reference (itself) semantics (nullability). While this particular change can bring very limited amount of improvements it’s still does some - probably smaller to no object header + more guaranteed optimizations for variables on stack.
It’s when they land next part (nullability) it will shine fully - particularly on the intersection of not null and value. Alternatively if they introduce tearable semantics it will also shine - it would be possible to still optimize array of value classes, even if they are nullable (for example by having correspondent nullability mask).
So they are taking right step in a right direction. They are just trying to land this incrementally.
It seems to me that the "and a null flag" is adding a tremendous amount of unneeded complexity. Supporting null seems to be about avoiding C#'s ref/in/out solution. I suppose that, from a JDK dev's perspective, that's a reasonable requirement. I just hope that we actually get non-null.
I'm not sure the no-tearing rule is particular helpful either. Like, this is something folks get wrong all the time in regular java. There's plenty of places where we use unsynchronized classes and expect synchronization to occur in the containing class or other explicit lock. If atomic operations are a requirement, and non-atomic value types get turned into references, then value types seem pointless.
I fear we're getting something called "Value types" with none of the actual benefits of value types. Like "we heard you want something called value types so here you are". No, we wanted a way to declare arrays of structured values without having to deref pointers, or to store structures inline as a field within an object. What I've read seems to be not that unless the structure's total size is 63 bits...
Yup. That's a big disappointment they could not cram universal generics faster. But I get the problem - they have to preserve backwards compatibility. I can take 30 y.o. Java 1.0 JAR and run it on Java 27 and it will work.
> There’s a catch worth knowing about here, though: flattened data has to be readable and writable atomically (otherwise it risks “tearing” under concurrent access).
I really hope they give an escape hatch for this. It will make it really hard to extract a lot of the benefit of valhala if you can't make a thread unsafe value class. It's also one of those problems that will be quite hard to run into. You basically need something like this
class Bar {
static Foo value[] = new Foo[10];
static void setFooFromManyThreads(Foo foo) {
value[0] = foo;
}
value record Foo(int x, int y, int z) {};
}
Not something you typically run into and generally already a thread safety problem.
The solution is also simple, a `synchronized{}` block will fix it if you need to have a tearable class that's written from multiple threads.
But the other thing is that for SIMD operations, you really need flattening, and that really does typically mean having something like `Foo(double x, double y, double z)` in play. It'd be a shame if the way we have to do this is a struct of arrays.
I actually don't understand the tearing they're talking about. If the fields are final then you can't modify the Value Type anyway? And a simple write-lock bit for fat Value Types would solve everything while maintaining most of the performance benefits (both on read and write)
The problem is concurrent access. A write bit on the value doesn't really help as you have to check and update the bit using atomic instructions. But you'd also need to reserve that bit for every read as concurrent access wouldn't be safe.
That's the tearing problem.
It gets worse because things you can't generally do in the JVM can happen. For example, if your value class contains a reference to an object but that reference just so happens to split a tear, it's possible one thread to see an invalid reference while another thread is writing that object. That could be fixed with some added padding based on the architecture to make sure stored references aren't tearable.
References can't tear in Java, per the specification (long and double could actually, the spec only talks about references and 32-bit slots being tear-free - though actually almost all implementations have them atomic as it's practically free on 64-bit CPUs). That would basically make the platform memory unsafe so I'm fairly sure they would make sure references are always written atomically.
But tearing may still cause a logical issue of course. (Think of a date class where the day may still be 31 but the month was set to Feb on another thread).
Interestingly Go is memory unsafe on this issue, slices can tear and later code can read into an incorrect offset from the pointer. Java abstracts away pointers, so this issue is non-existant there.
Tons of armchair critics but dang this is freaking cool!!! Thanks everyone for working on this an THANK YOU for moving slow and getting the design right!
I'll be interested in seeing the fallout of the (unavoidable) compat issue:
If I have a function that has a value `x` that erases to `java.lang.Object` (e.g. a parametric function with no lower bound); then it used to be safe to check for nullity and then synchronize on the object.
This is no longer safe: This can now throw `IdentityException` into your face. (it was _never_ a good idea)
In other words, a lot of old code must be reviewed.
I suspect that `-XX:DiagnoseSyncOnValueBasedClasses=2` will need to stay (with the semantics: if user tries to synchronize on identity-less object, then log a JFR event and make it a NOP, don't throw an exception)!
The current JEP text is a little too ambiguous to figure out whether that is the plan, anyways.
I understand the rationale for value classes, but the implementation is flawed.
What will this code print:
Point a = new Point(10, 10);
Point b = a;
a.x = 100;
System.out.println(b.x);
Until now the answer was obvious. Now with the addition of value classes, the answer depends on whether Point is a value class or a reference class. So readability suffers with this design.
This is a violation of the principle of uniformity. In The Psychology of Computer Programming, Weinberg explains that uniformity is a psychological principle which says that users/programmers expect that things that look similar should do similar things, and conversely that things that look different should do different things.
If a programming language lets two constructs look nearly identical at the use site while having meaningfully different semantics, it increases the cognitive burden on the reader. Programmers must inspect the type declaration or rely on tooling to understand whether assignment, equality, identity, and mutation behave like ordinary reference objects or like values. That can make code harder to reason about and maintain.
This could have been fixed by requiring the use of the "value" keyword not just at declaration time but also at use time like this:
value Point a = new Point(10, 10);
Point b = a;
a.x = 100;
System.out.println(b.x);
If that's true then it is a significant improvement over structs in C#.
But the distinction still matters. Value-vs-reference semantics affect equality, identity, nullability, arrays, collections, boxing, and performance.
So this is not just an implementation detail. If a language hides that distinction at the use site, it increases the burden on the reader and makes code harder to reason about.
C# has Properties that make setters look like fields anyway. There's no ambiguity between value and object in C# because there is no promise that that syntax only sets a field. Love it or hate it, you just need to know what you're calling.
based on the goals from JEP 401 [1], this is not possible, as value classes are meant to "Allow developers to opt in to a programming model for immutable data(...)"
How are people still defending type erasure? Sure, it was “defensible” in the sense that there were reasons the choice was made. But it was clearly a bad choice (to many people at least) when it was made and the effects are still rippling through the ecosystem. With the benefit of hindsight, it’s even more clear that the naysayers were correct and the harm to the Java ecosystem from type erasure is worse than the harm from creating parallel libraries would have been.
If sane generics had been introduced, the non-generic collection types would be a historical oddity by now and we wouldn’t be talking about how a future enhancement is going to undo the erasure decision.
It would perhaps make Java look a little bad to say that, in 1995, the prevailing attitude in certain circles was "If it's too slow, just wait for faster hardware - Moore's Law forever baby!"
(Of course, Sun was selling, at the time, relatively fast hardware - the slower the software, the faster the required hardware)
Yeah, when I read that, I thought "this guy was either born wayyy after 1995, or he doesn't know the first thing about computer hardware history, or both". 1995 was the year the Pentium Pro was launched, which was (one of?) the first CPU(s) to integrate the L2 (!) cache into the same package as the CPU - they were still separate chips, but the interconnection could be made faster by putting them into the same package.
Yeah, 1995 is much too late. I'd say somewhere about 1990. Maybe you can go as early as the i386 and 68030 in the late 1980s but I'd be hesitant to include them.
Yes, this also stood out to me. I usually think of CPUs and memory having parity in the early 80s, but I never bothered to check for sure. I do remember some early computer architects writing about memory being faster than the CPU!
The Z80 took 3 cycles to load from memory. A register to register transfer took 4 cycles (including fetching the instruction). Only one of those cycles was instruction execution.
I think the only reasonably mainstream scenario where the CPU would be significantly slower than memory would be the serial CPU designs such as the PDP-8/s.
That said, at the time people were doing cool stuff with 8-bit CPUs, they weren't running software remotely like what we're discussing here. That would have been done on a VAX, which had instruction and data caches.
What really happened, that the article is alluding to is that memory didn't get much faster in absolute terms since the 1980s. CPUs on the other hand did.
E.g. in the 1980s we had 60ns DRAM. Today DDR5 I believe allows about 10ns random access reads best case (6X). Over the same period CPU clock speeds have increased from about 8MHz to 5GHz (600X).
Early 80s is also what I remember, mainly from articles about old CPUs on HN - like the zero page on the 6502 that served as a sort of L2 register file.
I think this is quite similar to julia's handling of a struct. An array of mutable structs is just an array of pointers, where every pointer directs to the underlying structure. However with an array of structs (immutable is the default), there is no such indirection. The value of all fields are stored as array element (unless you have an array of heterogeneous elements).
If you want to change an element of such an array you need to create a new immutable struct which in practice it is quite fast, but a bit verbose to write.
It's still too unpredictable trying to be transparent IMHO.
Scalarization can fail in surprising ways just due to what a maximal atomic write can be on the target platform, and then it fall back to heap allocated objects.
Even if there's type erasure.
I much rather have the compiler balk at me than let me write something that may or may not work as expected.
This beaurcratic development feels like turning a super-tanker that's connected to a hundred other super-tankers. While I accept the priority of back-compatibility, I personally lack the working memory to manage it, while creative problem-solving.
I love a long form programming deep dive. I have questions, probably basic ones that belong in undergrad CS but it’s been … a while.
1. Can someone remind me why it was so important/intentional at the start of the language that every object has identity?
2. Why is it important that we not synchronize on these value objects?
Great write-up. Java is getting so good. The improvements over the last decade have been unbelievable.
The negativity here is bizarre. Just a reflex I suppose.
And I notice, people aren't aware more things are being planned for. For example, the carrier classes being proposed, they will separate state description with state representation and this is where value classes will shine syntactically.
I found a solution for what seems to be the same problem, in a different language: a particular type of lists, where the class metadata is stored once and the data for each instance is contiguously stored in a flat array.
Not sure if it covers exactly the same terrain, but perusing the article, it seems to be the case, with a single instance being the degenerate case.
Am I understanding this correctly: a value type really only works when it fits on a 64 bit "cache line", and when larger, it falls back to normal heap allocated objects as before? Seems extremely limiting, no? Great for a boxing optimization, but not much else unless you're deal with very small data types regularly...
That's true for arrays of these value classes. Scalarization would help for larger local values though, since those would avoid pointer indirection for purely local values.
Larger types are supported, there is A notion of tearing. According to JVM spec even long and double could tear, not sure about practical implications though
stopped reading when i saw the AI illustration. wholly unnecessary, and it feels insulting to be fed slop like this...
if you really want a fun drawing get a human artist to do it. it doesn't need to be complicated, for example https://www.code-cartoons.com/ is mostly just stick figures and does an excellent job
but you don't even need any of that, a mermaid diagram would have worked perfectly fine too. instead you chose to use a technology that is known to be harmful
I simply do not trust articles that use slop imagery like this. I assume the text of this article (and realistically, most articles posted here) is also slop, but it's often difficult to tell.
If you don't have the time or put in the effort to make your article, I'm not going to spend time and effort reading it. You really don't need some generic cartoon guy hovering over your graphs, draw them in MS paint or something.
> The difference in the code is exactly one word: value.
What is unclear to me is why the decision to use a Point instance as a value or as a reference is made in the class definition rather than by the caller.
> Point[] point = new Point[10];
For the same class, I might need an array of values in one place and an array of references elsewhere within the same codebase.
It would really break the GC or the type system if you did that. If you return a single point out of a 100k long array, it has to pin the array? How do you track the GC root? Struct array elements need back pointers?
Conversely, if it auto-copies now you have to contend with runtime state changing the pass semantics?
Looking into the negative comments is quite amusing. Not only do most of them contain technical inaccuracies, but of course, they also need to mention how great .NET supposedly has been from the beginning and how Java supposedly copied everything.
Let's take a stroll down memory lane. First of all, .NET literally started as a Java copy. On top of it, a non-cross-platform one for almost two decades! After having shamed Linux for so long Microsoft finally started porting .NET to other platforms in a non-backward compatible way. A lot of .NET proponents will tell you porting from legacy .NET to .NET Core (which was renamed once again to .NET) would be a quick fix, but it isn't. For example, the shop I used to work in had some important cryptographic libraries which were very painful to port. And then, there's .NET's simplistic garbage collector, which can be quite annoying because it tries to be a one-fit-all solution that basically cannot be tweaked at all, often resulting in unresolvable latency problems. There’s a lot of other stuff, like its ghetto-like ecosystem and the insane fragmentation of GUI libraries.
I also don't get the C# praise. Over the years, it has become quite the bloated language. It feels like Microsoft tries to implement every feature possible without realizing that an enterprise language is supposed to be streamlined. Async/await? Very ugly, very annoying. Java has solved this a lot better with virtual threads and structured concurrency.
I could go on, but these "language wars" are silly and pointless. Both platforms have their pros and cons. Besides, I have a lot of bad things to say about the JVM as well, but it's nice to see Valhalla finally beocming reality. Too late for me personally though.
I keep telling you what's what and you do nothing but gaslight me by trying to turn my words on me.
Language wars are silly and pointless. Someone tells me he/she uses language xyz, I basically don't care, do whatever works for you ,but God forbid you cross a .NET proponent. In case you haven't noticed, this is a post about Java. You mention Java, and the first thing that happens is a bunch of .NET maniacs popping up out of nowhere, telling you how Java copied this feature or how C# had that feature for years. What is this?
I just got my projects up to JDK 21 a few months ago. Working on trying to get one upgraded to JDK 25 now and now they're talking about delivering JDK 28 in less than a year from now. How are you supposed to keep up with these rapid updates?
JDK 21 is a few years old now, so you were a few years behind. JDK 25 was released last year, which makes for the next stable LTS for a while. JDK 28 is expected in 2028, and these features are not going to be enabled by default for years after that.
Java is generally backwards compatible, so unless you're using fat frameworks that use shady internals or known-deprecated APIs, you should generally be fine immediately upgrading to the latest LTS, possibly even non-LTS versions if you have confidence in your stack.
How much stuff actually broke? I feel like you can treat Java upgrades as minor upgrades most of the time, maybe you have to rebuild a few binaries but I'd be shocked if it required significant code changes.
The article has a section about that.
For me, a struct in C/C# can be modified and is passed by copy while a value class can not be modified and is passed by value.
I do not think you can do stack allocation in Java.
I'm a little unclear as to when and under what conditions this results in non-heap objects, now (<= 64-bits?) and in the future (???). I thought that was the _ENTIRE_ point of this project, so I was surprised to see they can be null (did that change from before?). If it is always and forever limited to 64-bits, I fail to see the point of this entire project, as it would have been far simpler to add syntactic sugar (simply pass primitives underneath the covers) as Scala did to create value types vs. JVM changes.
I get that this makes objects behave like primitive types. Maybe thats reason enough. But is it necessary for the performance boost and de-fluffing the objects? Seems like an orthogonal objective
> There’s a catch worth knowing about here, though: flattened data has to be readable and writable atomically (otherwise it risks “tearing” under concurrent access).
Isn't this a race condition and "undefined bahvior"..? Having to limit yourself to atomic sizes seems like a huge limitation, to accomodate what is most likely buggy code. Is all the effort only gunna help lil toy ColorRGB examples?
> The points array is a million pointers. Each pointer leads to a separate Point object lying somewhere on the heap.
Does this happen in actuality? One would assume the allocator tries to put stuff sequentially on the heap? Its not a guarantee as with these Value Types, but I'd think you could get similar-ish perf with prefetching in cache. I dunno whats happening under the hood.. But when writing Clojure apps the JVM always reserves absurd amounts of heapspace on my machine (to my annoyance). Id assume it can find some place to do contiguous allocations..
Which i guess gets me to my last question... where are the benchmarks broski? It all sounds great, but does it actually yield the insane speedups promised?
Great article, well written. But a benchmark would have been a nice "punchline"
> is it necessary for the performance boost and de-fluffing the objects?
Yes. The one part of the JVM GC that can't run concurrently is heap compaction; objects that can be moved by copying and then deleting would be a huge help for that. And it would be awkward to say the object has an identity but can't be wait/notify'd, at which point you need somewhere for the monitor to go.
> Does this happen in actuality? One would assume the allocator tries to put stuff sequentially on the heap?
Yes. Of course it tries, but semantically the pointers are just pointers and the prefetcher can guess but the system still has to chase them.
> I get that this makes objects behave like primitive types. Maybe thats reason enough. But is it necessary for the performance boost and de-fluffing the objects? Seems like an orthogonal objective
It feels like an orthogonal objective and honestly arbitrary distinction, yes.
> Isn't this a race condition and "undefined bahvior"..? Having to limit yourself to atomic sizes seems like a huge limitation, to accomodate what is most likely buggy code.
I think they meant it like the appearance of atomic behavior from a java multithreading view.
> Does this happen in actuality?
Yes, it does happen. Having guarantees on this front leads to better performance.
> But when writing Clojure apps the JVM always reserves absurd amounts of heapspace on my machine (to my annoyance)
> Is all the effort only gunna help lil toy ColorRGB examples
Arguably flattening mostly makes sense for these only.
And yeah, you are right that allocations happen on something called a thread local allocation buffer, which is basically just a pointer bump in cost and objects allocated one after the other should be physically close in memory for the most part (though an object's creation may require a bunch of other object's creation that would sit in-between). But these have headers, so not as dense as they could be (though due to GCs being generational, they may end up actually closer in the next gen? The in-between temporary objects wouldn't survive for the most part)
There are plenty of cases where flattening an object that takes 64bits would make sense.
The current code will help with `Integer[]`, `Char []`, etc, as well as combinations of `byte`, `char`, and `int`. Past that it doesn't really help much.
It would be fantastic if we could also flatten something like `Pair` or `Tuple`. However, even with compressed pointers, that is 64 bits, so that, plus the `null` bit, means it can't be flattened, which is a real shame. For various reasons, I have `List<Long>` in numerous places in my code, It would be great if that could also be flattened. However, since a Long is 64 bits, it _also_ can't be flattened. https://openjdk.org/jeps/8316779 would go a long way to to helping here, since then at least the null bit could be thrown away, which would allow more things to be flattened.
And then, if you want to go Wishlist land, something that would allow SSO (Small String Optimisation) would also be awesome, but that would require something akin to unions in Java, which we can _kind_ of do with sealed classes, but, since String is a final class, can't be retrofitted back into the language.
Does anyone know if Valhalla will flatten "simple" sealed classes, where every sealed class is small enough to be flattened? Since that would also be a powerful example to share.
Is there some reason there isn't simply a write-lock/semaphore on Value Types that are over 64bits? The overhead should beat pointer-chasing. I mean maybe someone wants to concurrently write to values from different threads with no coordination, but that's not super common. As you illustrate, having "fat" Value Types would open up a lot of potential.
In the current setup will a Pair Value Type be a compiler error, or will it silently just have bad perf?
It's because the author is comparing that incident to how they were prepared with the bulk of their analysis in advance. Ready to publish as soon as it happened.
wow, basic stuff c++ had since the 80s.
congrats.
clap, clap, clap.
now can someone please make this app that is running with -Xmx360m not use 700mb of resident memory ? asking for a friend.
The gap between demo and production is always bigger than it looks. Things that work great on the examples in the README tend to fall apart on edge cases that aren't covered. Worth running it against your actual data before committing to it.
The one that immediately springs to mind is C#. Of all the mainstream languages it is probably the one most similar to Java. It can be compiled into platform-independent bytecode (like Java) or into native code using Native AOT. Relevant to the subject of this article, it has had support for structs (user-defined value types) since C# 1.0 in 2002.
> Before we pop the champagne, though: this is preview, disabled by default, and, as Brian Goetz was quick to cool everyone down, “only the first part of Valhalla.” Goetz added a great observation that the “they’ll never ship it” crowd will now smoothly switch over to “but they didn’t ship the most important part” (and a joke has been going around the community for years that we’ll sooner end up in Valhalla ourselves, the Norse-afterlife one, than the project ships).
I don’t know if this is fair way to try to disarm your critics. The only thing that’s remained after this decade is the slogan so it’s a real ship of Theseus question if Valhalla has shipped since what’s delivered doesn’t achieve it. Congrats on the accomplishment, but from looking at what ended up, I’m not sure it’s a huge improvement.
> The trouble is that this optimization is unpredictable and fragile.
Is this describing escape analysis or value classes? Because the list of exclusions where this does anything is so large and the conversion to a heap type under the hood is so transparent and opaque, I think it can describe this technique as well.
Also, the whole “works like an int” motto is violated - int is never null, int-> integer boxing is explicit and well understood.
> In the new model, the wrapper classes themselves become value classes (when preview is on, Integer, Long, Double, and company lose their identity
Oh neat, they sidestep that by changing the definition of an int. I’m sure it’ll be trivial to turn this on in the wild on code that may be relying on identity for boxed numerics. I think this alone shows this project can’t ever be turned on by default and now we’ll have a decade of two Java languages (one with value types and one without) as they try to convince everyone to migrate and then just turn it on (ie python3).
So much opportunity squandered and dismissing critics as always having something to complain about is a neat way to sidestep legitimate criticism that this approach is not going to work out for Java.
I appreciate the hard work that went into the things that did make it into Valhalla eventually, but:
> The model was powerful, but also mentally heavy
No it isn't! it is this interpretation that kills off the null-safety debate entirely. Saying you have a variable that cannot be null is not a mentally taxing distinction, especially since everything is labelled thoroughly.
> The team, faithful to the lesson “simplify the model for the user, even at the cost of the performance ceiling,” ultimately dismantled this dualism.
but it would have simplified it for the user.
The whole attitude and process around this and the other topics gives me very little faith that Java can be steered in a sensible direction here. The type system of a programming language is supposed to give convenient guarantees to the developer on a CPU that can only do numbers. There is no reason to reduce the optional(!) safety guarantees you can offer with the excuse of "too mentally taxing".
Hell, they even get there half way by recognising:
> the language model and the JVM model don’t have to overlap one hundred percent
> The whole attitude and process around this and the other topics gives me very little faith that Java can be steered in a sensible direction here.
I agree. The stewardship of Java seems rather lacking - particularly when compared to that of .net, where MS etc. mostly seemed to make the correct decisions from the start.
Does Java even have any value or mindshare at Oracle nowadays? The company seems to be a datacentre/compute business at this point, with appendiges for its legacy activities and a vast overhang of debt.
I sometimes wonder if the only parts of Oracle that are still profitable are the Legal and Lawnmower divisions.
First, your parent comment misunderstood what the section they were critiquing is referring to. It's not about nullability (which is orthogonal) but about reference/value projections.
Now, as a member of the Java team (although I'm not directly involved in Valhalla), I'm obviously biased so let me just say that both designers and fans of programming language features would do well to remember two things:
1. Opinions about features are almost never universal, even among experts, and almost each of them is about a tradeoff where different people prefer different sides. It is rare that some scientific study settles the issue.
2. These preferences are often not evenly split. Even when both sides are equally confident that their preference is the right one, sometimes 80% or 90% of programmers share a preference. The people with the strongest opinions are more often than not in the minority, because most programmers don't think so much about the programming language (nor, I would say, should they).
All of the language differences between .NET and Java fall in this "non-consensus" zone, and at least in one area I was deeply involved with, virtual thread, I can say that we thought that whatever we do we mustn't do what .NET did and that what they chose didn't work out well for them at all.
This is great advice and it applies to a lot more than just language features. Different architecture, deployment setups, QA approaches are all like this. It's always "approach A is no good", "but company X uses approach A and they're doing very well", "yeah but look at all of these problems they have". Maybe a fair argument but the approach B people also have their fair share of problems...
What's funny is that the only languages in the same popularity league as Java are Python and JS/TS (and possibly C and C++ if you want to extend things to more domains) yet I rarely ever hear people saying Java should be more like these languages. It's because many of the people who dislike Java also don't like any of the most popular languages (even those who like, say, Python better don't think Java should be more like Python).
These people may point out that languages become more or less successful not because of the things these people care about but because of other factors. And they're right, but then the question is, shouldn't a smart product team focus more on the things that actually matter more to more people?
Programming languages are tools, and so their value is not intrinsic, but comes from the value of the software they're used to create. Now, some people claim that Java's success is largely the result of it being one of the most hyped languages of the late 90s and early 00s, alongside VB, Delphi, FoxPro, and C#. But this claim doesn't stand up to even the slightest scrutiny.
I definitely see people asking for features from c++. In part because virtually every feature is in c++.
That tends to be a reason to say no- remember the vasa!
GUI frameworks have similar arguments around their design choices.
This is pretty funny...
"All differences are opinions....except what .net did. Those are wrong!"
I personally think Java continues to to waste a lot of time and come to a slightly more verbose and worse solution again and again.
Structured concurrency is like c# async/await with less sugar. Streams are just LINQ but worse.
It's probably exactly because of the "not like .NET! We must be different to explain being late" mentality.
Both languages/runtimes are decent, stable and good choices for running production systems.
They have different philosophies though, C# is mostly "give the developer a complex toolkit so they can do whatever they want, but keep the runtime simple", while Java is more like "keep the language as simple as possible, and put new features mostly into the runtime making it more complex, but benefiting even old code".
Async vs virtual threads is a clear example of that. The former makes the language much more complex, and has a huge surface area where it may clash with other features, so a developer has to remember all of these. But it's a simple machinery under the hood.
Meanwhile virtual threads don't change the language at all, it's the same as it was with Threads, but under the hood it is a very complex feature.
And in this particular instance I think it is quite clear cut that Java made the correct decision, for the most common use case of these languages having non-blocking IO "automatically" makes for significantly better user experience.
I do think Java is a fine language but I don't really agree that it looks more simple in any way shape or form.
For things like UI programming where you need a main thread or where you do need a cross language OS thread, I think Java is going to end up more complex. Under the hood it is very complex and that _will_ show itself.
So from my perspective it's not virtual threads, it's virtual threads with structured concurrency vs async/await. When you look at it that way, the comparison of complexity is certainly not seamless or simple.
As a person with a lot of .NET experience but has been working on other tech since 6 years, the wow effect I had from using LINQ has never been repeated with anything else.
It felt like magic, maybe too much magic, but so useful nevertheless.
Java is getting that power in a different, more orthogonal way, IMO, through Project Babylon: https://openjdk.org/projects/babylon/
LINQ comes from FP, and was introduced into C# via Haskell, and actually the first version (.NET 3.5) was quite similar to Smalltalk or Common Lisp collections.
.NET do what they do because they believe many people like it, and we do what we do because we believe many people like it. Because different developers like different things, we may both be right. The only explanation to why we do what we do is that we believe it works well for us, and we know what everyone should know, which is that what we do can't be universally liked because developers have different preferences.
But that doesn't mean the preferences are equally distributed. Some people liked Betamax's better picture quality while others liked VHS's better recording times, but they didn't do it in equal numbers. And that's what's funny, because there are two languages doing as well as Java or better (one of them is much more popular), and yet what's almost universal is that when people say "Java is worse than X", X is invariably a language that's doing much worse than Java.
I'm not saying that there isn't much to learn from less popular languages, but the claim "Java is consistently making the wrong decisions compared X" doesn't make sense when X is consistently losing to Java.
And I can even give you the secret to our strategy: Make Java the language that people who choose it regret less than people who choose other languages.
I like Java too but this is pure cope. By this logic Python's threading model is the best.
I think you misunderstood my point. I'm not claiming that the most successful products necessarily have all the best features. I am saying that the claim that "team X consistently makes worse decisions than team Y" is hard to support if team X is winning. At least some of their decisions are probably better, and those ones also probably matter more.
Nothing funny there. They shared their opinion as an example. Yes it differs from others, that’s what they was talking about.
Value types kind of definitively don't have null, right? You can have a zero int but not a null int. So nullability is not entirely orthogonal to value types, its an advantage for value types where they are practical.
I didn't say nullability is orthogonal to value types; I said it was orthogonal to the two-projections world, which is what that text in the article was about rather than nullability.
As to value types and null, I'm not sure about the current picture, but the general idea is that you declare what semantic properties you want - identity or not, nullable or not, tearable or not - and then the compiler picks the best technical in-memory representation for each use. For example, the compiler could choose not to flatten variables that could be null in the heap but to flatten them in the stack. That's the general idea, but I'm not sure about the details, some of which may yet change.
More generally than just Java, nullability is often a property not of a type but of a variable. For example, in C, an int may not be null, but a pointer to an int may be. Now, in C, `int` and `int*` are two different types, but that's exactly a distinction that the original projection-spit design made and we wanted to avoid. But you could still end up with a variable that could hold either an integer or a null and another that may hold an integer but not a null, only this is separate from the reference/value projection, which combines both identity and nullability (in C, `int*` is not only nullable, but also has identity).
> More generally than just Java, nullability is often a property not of a type but of a variable
I'm going to hard disagree here. And the syntax proposed in the Null-Restricted Value Class Types JEP is a major step backwards.
I want to banish nulls from my codebase, completely. I can currently do this with a variety of annotations (at the package-info.java level) and tooling, though it's not integrated well with the language.
Forcing exclamation marks into every variable and parameter is a lot of annoying noise that quite simply nobody will do. The default should be non-nullable, especially for value types.
Declaring whole types as non-nullable is less noisy and errorprone than annotating every variable declaration. If you aren't going to give me "declare the whole codebase as non-nullable" then at least give me something coarse-grained.
> the syntax proposed in the Null-Restricted Value Class Types JEP is a major step backwards. Forcing exclamation marks into every variable and parameter is a lot of annoying noise that quite simply nobody will do. The default should be non-nullable, especially for value types.
Then you didn't read the JEP draft (it's not an accepted JEP) carefully. It says, under "future work":
Providing a mechanism in the language to assert that all types in a certain context are implicitly null-restricted, without requiring the programmer to use explicit ! symbols.
In other words, the draft already incorporates your point, but JEPs (both drafts and actual JEPs) follow the pattern we've found to work so well, that features are best delivered piecemeal rather than in a big bang.
Having said that, I don't know the current plans for this matter, as that document is only in Draft status, so saying it's good or bad is pointless, as it's not even a proposal yet, just something being explored.
It's a proposal for a proposal, fine. Consider this my proposed feedback.
I don't think this syntax is desirable as currently proposed, and that one line under "future work" is doing far too much lifting. My sincere hope is that there are people closer to the process that also feel this way, they will provide similar feedback, and the next draft will be something completely different.
Except we like delivering features by pieces, so unless your proposal is to first deliver global flags with no instance-specific control and later add more control (and I think you're not suggesting that), I don't see any difference between what you're suggesting and what that draft is suggesting. That a one-line under "future work" is doing a lot of lifting is just how we usually do it (and it's okay, people always complain, but we've tried the big-bang approach and this one just works better for us).
So consider that draft as an idea for how the site-specific nullability annotations could work rather than an idea for how nullability could work in the language in general.
> how the site-specific nullability annotations could work
That's fine but it's still a bad choice. The problem is that it defaults to everything nullable and adds noise for non-nullable. This is backwards; in the overwhelming majority of software that people use Java for, non-null is the common case and nullability is the exception.
Kotlin and Typescript got this right. Nobody wants! to! write code! like! this! And they won't, so the feature won't get used and we're back to everything being nullable.
> it's still a bad choice
Except there's no choice here. It's a draft of an exploration of a portion of a feature.
Drafts are ideas that have not even been submitted for consideration for inclusion in the roadmap. You can find drafts over ten years old that have long since been superseded by other ones or abandoned altogether: https://openjdk.org/jeps/0#Draft-JEPs. Some JDK engineers write JEP drafts when they feel they get close to something they would like to propose, while others write drafts for pretty much any idea they have.
> The problem is that it defaults to everything nullable and adds noise for non-nullable
It doesn't, though. Even if this draft ever becomes a JEP (and I don't know if it or anything like it will), in its present form or another, it would still, like most JEPs, describe only part of the feature. It's perfectly on point for one JEP to describe the explicit nullability annotations, while another describes the defaults. Smaller features than this have been split into two or three JEPs. This is just how Java features have been described and delivered for years now (see how many JEPs patterns were split into: https://openjdk.org/jeps/0).
It's perfectly okay to dislike some design, but I find it strange to assume, based on a draft of a portion of a feature that one of the most experienced and successful programming language design teams in the history of software is likely to get it wrong. Maybe wait until there's an actual proposal and a roadmap for the complete feature before critiquing it? It's like seeing a draft of some building's foundations by a prestigious architectural firm and saying, these idiots forgot to plan a roof.
> More generally than just Java, nullability is often a property not of a type but of a variable.
This is a tangent, but I'm not sure I follow this. Can you give an example to make this clear?
Yes, but it comes from Java having both runtime and compile-time types; it's harder to make the distinction in languages that don't have runtime types.
In Java, you can ask, `x instanceof T` (and this is a runtime test), which means, is x one of the values in the set of values allowed by T. `null instanceof Integer` is false, even though a variable of type `Integer` can be assigned a null. So you can think of `Integer x` as being `Integer|null x`, i.e. x can hold a null, even though `null instancof Integer` is false.
I think I mostly got this, but just to test it, it would be like in Typescript where I might say:
In this case, the variable `x` has a property that is determined by the compiler based on control flow. i.e. it isn't explicitly carried by the type of `x`.In case you want to edit it back in: in the 3rd paragraph second sentence, the star in your int* got gobble up by formatting to italics.
You can have a null int, it's called Integer.
What was taken away is the other, identity-having functionality of Integer and similar (e.g. no synchronization).
This won't be true in Java, though - in Java, you will have null Integers at least. It seems that int will remain a different thing entirely from Integer, and will remain a JVM-only concept.
But with null-restricted types, Integer! and int has no difference semantically and representation. They plan to introduce null-restricted types in future.
> All of the language differences between .NET and Java fall in this "non-consensus" zone
Curious if you think fibers vs async/await is still in this zone (amongst experts). It seems fibers are objectively better. But I'm no expert*
I think user-mode threads are better when the language already has threads. I'm not sure they would have been better for JS. But yeah, this one is probably less controversial than things like properties and extension members, which we also said "yeah, nah" to.
https://github.com/oven-sh/WebKit/pull/249
Although the work being done to enable multiple threads in JS is impressive I think it will be hard to make robust in many casss without locks, or fairly strict limits what operations can be performed on objects shared between threads.
The property lookup and modification process in JS is complex enough as is, is not specified in an atomic kind of way, and has many opportunities for user code to be run as part of accessor properties. Enabling it in multithreaded implementations is tricky without opening up deadlocks when modifying property collections, and even with that could likely be broken by some suitably evil code. Ive worked on more than one implementation that offered some degree of multithreaded access and it’s generally only safe when limited to simple properties.
Async / await avoids those issues because none of the places where user code can be executed allow async code, so there is no opportunity for the world to be changed under your feet during something like property access.
https://tc39.es/proposal-structs/
Structs, Shared Structs, and Synchronization Primitives
There are a few things that would be required to make it all work, this would be one of them.
I'd be very surprised if Google go for it.
What's wrong with what .NET did with threads? Having async tasks sharing the GUI thread seems like a nice feature. Will we be able to use virtual threads and structured concurrency with Swing, e.g. to wait for a background task in an event listener?
Regarding "What's wrong with what .NET did with threads?", see https://cr.openjdk.org/~rpressler/loom/Loom-Proposal.html (relevant part below):
Regarding Swing, virtual threads are "just" threads so no reason they (and structured concurrency) can't be used.Regarding coloring...
You still can't block in UI code, right? You don't know whether you're on a virtual thread or the UI thread (even if its virtual) by design. You still have to bifurcate your APIs into blocking and non-blocking, don't you? Virtual threads will help you keeping the CPU fed but it won't handle separating UI and non-UI work, or know when a frame deadline ends.
Have there been Swing specific updates to deal with that?
So does Java provide an API for continuations or just the virtual threads hidden behind the threading API? You can't use threads to wait for something on the UI thread (which is why e.g. SwingWorker exists), but you can with await.
There is no public-facing continuations API afaik.
Structure concurrency/virtual threads seem like a good fit for Swing; just have your event handler fire off virtual thread[s] and do your work and call SwingUtilities.invokeLater to schedule the result to be applied on the event loop thread when you're done. Structured concurrency simplifies managing groups of concurrent tasks, cancelation, etc.
Look at their structured concurrency stuff. But IMO it ends up gaining not too much over async/await with worse syntax.
The colorless functions approach has well-known disadvantages though, including providing less control and making interop a pain. It isn't like one approach is the correct one and another is a mistake.
> including providing less control and making interop a pain
This is true in some languages but not in Java. The limitations (and performance cost) are not from the nature of continuations/stackful coroutines/"colourless functions", but from their interaction with other constraints and existing designs in the language. E.g. in Java, virtual threads have zero impact on FFI.
In general, the costs and limitations associated with a feature in language X don't extrapolate to language Y, because they often stem from interaction with existing constraints in language X.
The design of FFI is a very common source of problems for various features. For example, if the FFI is designed such that you frequently pass pointers to to objects to C, that can have a big impact on other features. In Java, you nearly always only pass pointers to "off heap" memory, i.e. memory that's not managed directly by the JVM. While this has no performance cost, you could say that this, in itself, has some convenience cost, except Java programs need to rely on FFI much less than other languages, so the overall cost to convenience is low.
How can green threads have zero impact on FFI in the presence of callbacks across the boundary? I mean, as soon as the other side uses TLS in any way, for example, you have to figure out how to handle that, and it's not free.
In every user-mode thread or stackless coroutine (async/await) implementation I know, the construct is pinned (i.e. can't be preempted) while there's a foreign frame on the stack. There is no advantage to either design on that front.
But 1. there's no speed penalty in Java for doing that, and 2. In Java, calling native functions that block (which is the only time this limitation matters) is rare, especially in high concurrency situations where you'd use virtual threads in the first place.
.NET made different decisions.
I was at a conference on scientific programming in Java very early on that Geoff Fox put on up at Syracuse and we had a list of requests from Sun that they didn't give us but Microsoft gave many of them right away.
On the other hand I really like Java's all-virtual approach to inheritance because the .NET model gives programmers more ways to screw up and get confused.
Both languages slipped in generics after 1.0. Java used type erasure in a way that made it so a List<String> is really a List so generics could be retrofitted easily to existing code. .NET's implementation of generics let you do more but caused a rift in the ecosystem between generic and non-generic collections.
I'd say long term Oracle's stewardship of Java has been very good. JDK 8 puts lambdas on your fingertips with a very fluent syntax that belies the idea that Java is terribly verbose. Since then Java has gotten steadily better release after release while maintaining great compatibility.
I work with people who are conservative about updates because they are worried about breaking things but for the last few LTS releases I've said "it ought to be really easy, let's give it a try" and it is really easy and we get performance improvements we can feel.
Java stagnated for quite a while. Seemed like everyone was stuck on Java 6 for about a decade. But JDK8 was a huge step forward. Lambdas, streams, and a date/time API that is the best I've seen.
I think DotNet had a bit of benefit, in that the language was still new enough to do the hard breakage. It was only about 3.5 years between NET1.0 and 2.0 (Where generics were added.)
I was annoyed by it back when I was doing Silverlight/ASP.NET
Thing was a lot of Microsoft APIs for GUIs and whatnot used the List and if you wanted to use the List<X> you had to copy the list or make a wrapper or something. You might say, "just use the List" but at that point (circa 2008) I had to also use the List<X> for some API so I always had to do some conversion.
The way it worked in practice is that all the new built-in collections in System.Collections.Generic implemented the non-generic interfaces as well, so e.g. List<T> implements IList<T>, but it also implements IList (explicitly), and similarly for ICollection and IEnumerable.
Then, when WinForms or WPF wanted a list, you could just give it a List<T> instance, and it would talk to it via IList, boxing and unboxing if necessary.
What you describe happened in the other direction - if you had, say, a generic method operating on IEnumerable<T> or IList<T>, and wanted to pass it a WinForms collection. WinForms generally defined strongly typed collection classes on a case by case basis, but none of them implemented the new interfaces. It was there where you had to wrap things, most often using AsEnumerable<T>().
[dead]
> The stewardship of Java seems rather lacking
In what way? If anything Java's main developers (employed by Oracle for the most part, working on the completely open source and free OpenJDK) are extremely knowledgeable and are responsible a big jump in how fast the platform evolves. They have added proper algebraic data types to the language, delivered virtual threads and garbage collectors that decouple pause times from heap size. Like if anything, Java is at the best place it has ever been.
> They have added proper algebraic data types to the language
No they haven't. E.g. they added a class that superficially looks like Option but subtly breaks the rules that Option is meant to follow, ensuring that no-one can ever manage to migrate existing codebases away from using `null`.
Sealed classes/interfaces and records are proper sum and product types.
The stdlib's Option type predates this language update by a long shot, so it doesn't use sealed classes, but it is now possible to have the usual FP "Maybe" type in Java:
``` sealed class Maybe<T> permits Some, None { record Some<T>(T obj) {} record None() {} } ```
(You will probably have to write Maybe.Some and I might have messed up the generic syntax as I wrote it on my phone, but that's mostly how it looks)
Or just do as Kotlin and embrace null, but in a type aafe way.
"Funnily", having nullable types be practically `T | Null` gives you union types, not sum types (the latter is, importantly are a disjunct union!)
The main difference is that (T | Null) | Null = T | Null, while Maybe<Maybe<T>> is different from Maybe<T>
Your point being?
Except this is completely wrong.
First, a record can't extend anything, it's not even valid syntax, so a sealed class can't permit record subclasses. So no, it's not possible to create a Maybe<T> class in Java that can only represent a Some<T> or a None<T> record. You could do it with regular classes, or if it's ok for Maybe<T> to be an interface.
Secondly, regardless of the sealing, nothing in any current or near future of Java prevents you from assigning `null` to any class of any kind you might create. So you can always have `Maybe<T> x = null`, or even `Some<T> x = null`.
None of this will change with the adoption of value classes either. So no, there is absolutely no way in Java to create a real Optional/Maybe type that would guarantee that a variable is either an object of a given type or None. There is probably some way to do it for your specific project using annotation processors, of course, but that is very different from having built-in support.
It's probably a typo. He meant sealed interface. I think that should be quite obvious.
Mistyped, it's sealed interface.
> So you can always have `Maybe<T> x = null`, or even `Some<T> x = null`.
Yeah and? Practically every type system have escape hatches, like Haskell can also do side effects without the IO monad, does it make the latter useless?
The whole point of using Optional/Maybe is to prevent the possibility of accidemtally creating nulls. If you don't make mistakes, then nullability is not a problem. If you do make mistakes, then a class that only helps when you don't make mistakes is basically useless.
This also has significant impact for serialization/de serialization - a classic place where you get unexpected nulls, that Java Optional/Maybe don't help with at all.
Disagree.
Types are both for the compiler, as well as for the developer. Maybe types are implicit documentation telling the developer that it is meaningful in the application that this field can have a None state.
That's a huge code smell to ever set null to an Optional/Maybe and code reviews, linters, nullness analyzers all should/will flag such.
Like I have never ever had an NPE from an Optional being null. Sure, complete null safety would be better of course, but in this very instance it ain't buying you much.
This is what your choices are with regard to communicating to the compiler and other developers.
Use a regular class to signal that you may or may not have a value.
Wrap it in an optional to signal that you may or may not have a value.
See the problem?
Since they plan to have null-restricted types, then I don't see any issue.
> plan to
Well wasn't that the argument above, that the stuff they added so far isn't proper at least in part because they didn't fix that problem yet?
> yet But up the comment section, someone thinks they won't be there 'in the future'
The comment that says it won't be there in the near future? That's seems like a reasonable claim to me.
And a promise to eventually fix a busted implementation doesn't undo it being busted for a significant amount of time.
optional is not how algebraic data types are implemented in Java. Basically it's the combination of sealed types and records.
Until they implement member patterns. https://openjdk.org/projects/amber/design-notes/patterns/tow...
Given the mess of some .NET frameworks currently, and how bad it has taken for non nullable references to be widely adopted, I don't see those correct decisions on the last releases.
It is all about having AI on the framework, Aspire, multiple Web and Desktop frameworks all over the landscape.
Those interceptors and inline arrays via attributes instead of proper language grammar aren't that great either.
>Those interceptors and inline arrays via attributes instead of proper language grammar aren't that great either.
Yeah. Even when they add new grammar nowadays, it's always just something that trivially sugars away into previous grammar (see: records, `with` clones, extension properties, required, etc).
The moment they need something that it's slightly more complex... Out of scope. Even when it's completely necessary for the thing to be useful in practice.
For example, they added `required`, `record`s and property initializers, giving us good reasons to write `new Foo { A = a, B = b }` instead of `new Foo(a, b)`. A and B must be positive, so you'd write:
This is pretty standard C# code that you might see in an example for records.But then the requirements change: A and B must be positive, or they must both be zero at the same time.
This cannot be expressed at all with initializers. You simply cannot add code that runs after all initializers are called. You're stuck chasing every single initialization of Foo and using a constructor or factory method instead. Shipped it as a public API? Too bad. Should have seen it coming!
The new features are filled with this sort of thing. As if Microsoft never used them beyond the most basic examples. Or maybe they did, and explicitly chose not to fix it and solve later.
I have this idea, that since they went open source, but failed to gain the adoption on UNIX shops they were expecting, there are tons of features to try to make it cool again somehow.
The reality, and I can see this on my bubble, is that the .NET shops are mostly former Microsoft shops now saving Windows licenses by deploying on Linux.
Stuff like MAUI remains pretty much constrained to former Xamarin customers.
Thus minimal APIs, aspire, Blazor, and whatever comes up to support those use cases first.
There are some podcast interviews from David Fowler and Maddy Montaquila where they touch the adoption issue among newer generations.
As someone who works with Java on a daily basis alongside a dozen other technology stacks, let me go out on a limb and say that I believe Oracle has been a stellar steward of the language. Java has been evolving quite nicely and at a reasonable pace, all without breaking the ecosystem or causing fragmentation. It certainly has its drawbacks, but doesn't everything?
I'm honestly happy with java lang's stewardship over the past decade, this particular JEP notwithstanding (it's fine, but the good parts come later.) They're conservative in adopting new features whereas I see every other language bolting on everything under the sun with reckless abandon. I prefer the "let's see what shakes out" and adopt "the good parts" which seems to be Java's approach. Sugar like "var" from kotlin, project loom event loop like nodes, etc.
Type inference was on DLang far before that Kotlin even existed. The only difference it's that reuses "auto" keyword.
I mean, type inference goes decades before Dlang.
> particularly when compared to that of .net, where MS etc. mostly seemed to make the correct decisions from the start.
Wut? I did worked on .net projects and all it achieved was making me like java a lot more then previously.
I had the opposite experience, spent a year with each language, first Java then C#, and to me C# felt like "Java done right". (Which appeared to be the original design goal behind the language!) So I'm curious about your experience.
To me it felt a bit less like a religion and more like a language. It didn't force me to do things a particular way, quite as much. (Still more than I would have liked, though! After all, it's called that[0] for a reason :)
[0] https://www.reddit.com/r/ProgrammerHumor/comments/ddc4b0/mic...
Same for me. I have worked with Java since 1.2.2 and used .NET for something like 10 years (don't remember the versions). Most important differences are:
> -Linq is nice but has a huge caveat: if a Linq provider does not implement it fully to falls back to the .NET collections. So trying to 'Skip' and 'Take' on a ActiveDirectory will fall back to collections in memory and cause a crash on a huge AD in production (Yes had the pleasure).
How do you expect this to work then? If the provider is bad, blaming LINQ for it makes no sense...
You either have a high level of abstraction and possible performance pitfalls - or a low level of abstraction, and also performance pitfalls since the code is less modular, more coupled and harder to read.
LINQ can in many cases improve performance significantly in large applications when used properly, since it avoids N+1 query problems due to implementation hiding/modularity, and allows composing parts of queries across different vertical subsystems of the application (vs. each subsystem doing its own query and then joining them with more boilerplate).
Nothing in Java compares to this. jOOQ and Hibernate (and the rest in the ORM ecosystem) are pale shadows, exactly due to lacking language features (such as reified expression trees), and even then, they only work with databases.
> .NET is about extending an existing application (Servlet API vs IIS)
I don't think this is true anymore since ASP.NET Core. While you can still run under IIS but it's a more typical reverse proxy setup instead of running inside IIS.
> You can't wrap streams in .NET
You've always been able to wrap streams in .NET so I'm not sure what you mean by this
Yeah, me too. Java always seemed to consider design a lot more than C# which seems to have taken more of a kitchen sink approach to language design. That stuff piles up over time (see c++)
Agreed. I jumped on the .NET bandwagon in 2000 and was on it for several years but ended up going back to Java by 2005.
What do you like about Java compared to C#?
First, huge open source ecosystem and culture. Mature open source projects, culture of writing blogs and tutorials (that one will die due to changes in search engines, but it was super nice while it lasted).
Second, working in C# felt clunky, as if every other thing was done to check the checkbox "done" and the author called it the day once it sorta kinda worked. There was some additional syntactic sugar in that language that was nice, but it did not made that much difference in practice and I don't miss it after coming back to java.
Third, I found the obsession with bashing java by people who have no idea how java projects look like and which problems they have annoying.
How .net got so many things right where java did not is a mystery to me, but appreciated (it has its own flaws, of course). Java, in my understanding, is still of core relevance to Oracle, and tied into a lot of contracts that require very little effort from them to maintain. But you are correct in observing that they want to be a datacentre/compute business more and more these days; they may have in fact overcomitted to this due to the AI craze, since shareholders are already complaining.
> How .net got so many things right where java did not is a mystery to me
Part of the reason for that is that Java is older. https://en.wikipedia.org/wiki/C_Sharp_(programming_language)...:
“In interviews and technical papers, he has stated that flaws in most major programming languages (e.g. C++, Java, Delphi, and Smalltalk) drove the fundamentals of the Common Language Runtime (CLR), which, in turn, drove the design of the C# language.”
Also, some of Java’s design warts may be there because Java was initially envisioned for much smaller devices.
This. C# was basically always meant to be "Java but done right". It came several years later, after Microsoft was legally barred from "EEE"-ing Java and required a direct competitor.
> It came several years later, after Microsoft was legally barred
That is an eloquent way of re-writing the history of Microsoft stealing Java and not being allowed to get away with it.
They didn't "steal" anything, iirc; they started as a legitimate licensee and then tried their usual embrace/extend/extinguish as "J++" (the EEE I mentioned). Sun sued for breach of license and won, barring Microsoft from extending Java outside of the (Sun-controlled) process. So they dropped it and built their own version, with blackjack and hookers.
> So they dropped it and built their own version, with blackjack and hookers.
This cracked me up
But what I don’t get reading the original article is that they present how to insert struct in an object oriented language as an intractable problem, whereas a good implementation with .net (as far as I can tell) has been out there for nearly 30 years. And C# was shameless about stealing from other languages.
> how to insert struct in an object oriented language as an intractable problem, whereas a good implementation with .net (as far as I can tell) has been out there for nearly 30 years. And C# was shameless about stealing from other languages.
I think (but may be wrong) their concerns are about the insert part. C# always had structs, Java wants to add them in a backward-compatible way. They want, for example, existing generic container classes pulled in from a .jar (i.e. already compiled) to support Java value types.
The problem is how to do it without breaking ABI, 30 years of Maven Central is very relevant, Java isn't doing a Python over value types.
But if you define a new type, how is that breaking backward compatibility?
Well, my old code can have a List<Object>, and I can pass my new type into it and have it do some operations. Let alone with reflection - so backwards compatibility is more complex than that.
As for structs, Java avoids e.g. tearing issues with making them immutable, while it is easy to optimize it to local modification under the hood.
Because that is missing the point.
All the types that are value types in semantics, e.g. Optional, should be proper value types on Valhalla.
Additionally, they should be compatible with existing code that expects them as parameters, fields,.... without being recompiled from source.
If it is a complete new type without backwards compatibility, no one is going to adopt it, other than a few niche cases.
Dlang this this before. You have classes and struts, with different semantics.
Unfortunately D will remain a niche language due to various reasons, and is D not Dlang.
Ironically, they still do need Java for Azure, https://devblogs.microsoft.com/java
It's no mystery. https://en.wikipedia.org/wiki/Anders_Hejlsberg
Which recently decided that Go was a better option than C# for the Typescript rewrite, exactly because not all decisions were done correctly to make C# a better fit for the problem.
Go was chosen mainly because it aligned more with how the existing compiler is designed. They did not want to redesign the compiler which eliminated C# as a choice. So Go is apparently just a better fit for quickly porting JavaScript code to.
That was the original motivation yes, although they acknowledged later that the weaker type system from Go required redesigning the data structures anyway.
And as proven in the recent announcement, they had to rewrite parcel from C++ into Go, as they didn't found a comparable library in Go ecosystem.
There is also another interview, where again they mention having used AI as tool for code rewriting as well.
Also to note that it was pointed out that Native AOT wasn't up to the job, again something that both Java and C# failed not having done it properly from day one.
They said the prototyped in a few languages before settling on Go. Based on what you said it sounds like they didn't do a great job at that and stuck with their decision anyway.
> Also to note that it was pointed out that Native AOT wasn't up to the job, again something that both Java and C# failed not having done it properly from day one.
It's been working fine for a few years now. The only problem I know is there is little to no reflection allowed (by design) so a lot of code out there is not compatible with it yet. Not sure if that's what turned the TypeScript team away from it.
Yes, see BUILD 2025 talk for example, the section on "extreme refactoring" regarding the ASTs,
https://youtu.be/UJfF3-13aFo?t=1453
As for the AOT part, one would expect that being all Microsoft, they could work together to fix whatever were the issues with Native AOT.
What things are you referring to? Especially after the many features that Java gained after Java 8.
The mystery of why .NET got so many things right is simply that C# was built several years later by the exact same Microsoft engineers who had previously worked on extending Java, giving them a perfect blank slate to fix the architectural flaws they had already encountered
Second mover advantage.
virtual thread instead of async/await is a counter example.
Java is more used than C#, they can wait before delivering a new feature (given their leader position) but cannot deliver a flawed implementation that would stay in the language forever. Glad to have virtual threads and the backward compatibility that comes with it instead a Async version of sync methods + async and await keywords all over the code and Task as a return type in my interfaces methods to allow implementations to do non blocking I/O calls if they need.
I use Java and C# and appreciate them both.
.NET had green threads (fibers) in its first iteration. They were abandoned because practical use of .NET was also FFI-heavy - WinForms etc - and native code generally doesn't play well with non-native threads. The benefit of async is that it desugars into callbacks with state, which is something that can be easily expressed in terms of the C ABI (which is the de facto interop standard on all mainstream platforms). Which is why you can have async C# code calling into async C++ or Rust code, or for that matter async Python calling into async C#. Given that .NET was historically supposed to be a multi-language runtime, before they went all in on C#, async made a lot of sense.
C# did not ship with async/await, and Java didn't have virtual threads back then. I am specifically referring to the initial choices made in C#'s foundation.
> giving them a perfect blank slate to fix the architectural flaws they had already encountered
and then they make everything nullable by default in c#...
C# often feels like Java with hindsight; Java feels like Java with 30 years of backward compatibility debt.
Hence why so many .NET projects keep being .NET Framework instead having migrated to modern .NET.
mostly they are sticking to .net standard 2.0 that is compatible both framework and modern.
Java made several mistakes. It also made some questionable (yet often defensible) decisions. It's understandable. Type erasure was one I believe was a mistake. It's talked about in the article. Yes, you kept binary compatibility but you that created so many other problems such as not being able to use value types in generics. Notably, C# looked at that and said "nope". Type erasure is also hurting Valhalla here and the issue of value classes in generics is the second phase so is being pushed far into the future.
But a huge mistake (IMHO) was not having nullability part of the type system. You can still do this with type erasure.
Anyway, I read your comment as "nullability isn't complex" (paraphrased) but that's not the author's point. What's complex is having a value class and a regular class of every class and you don't necessary know which one you're dealing with at the language level.
C++ is a great example of this. You can create an object ont he stack or the heap and that's really what we're talking about with that proposal. And that's a nightmare. Combined with pointers it meant you never knew if you could free something or not and that ownership had to be passed around with vague comments like "// retains ownership".
Anyway, the whole article is a great tale of how difficult it is to retrofit things later and how difficult it can be to fix mistakes later (eg java.util.Date).
> Yes, you kept binary compatibility but you that created so many other problems such as not being able to use value types in generics.
This is often given as the defensible reason, but it's not even that true. Java 1.5/5 had several "breaking" changes in it regardless including the newly reserved 'enum' and a whole freaking memory model update.
And besides if any of your dependencies updated for all practical purposes you did, too, since you had to use a newer runtime to run their code regardless, it never really made sense to keep using an older javac out of spite
How would a non-nullable class field work in Java when it can be initiqlized by arbitrary imperative code that can read it while it's being initialized?
The type erasure version of this would look a lot like Hack [1]. So generic arguments would simply have a ? if they allow nulls eg List<?Point>. The list itself couldn't be null unless it was ?List<?Point>.
Now, one can argue that this is just smoke and mirrors with type erasure and it is but you can already put a Date into a List<Point> if you're so inclined because the JVM doesn't know the difference, hence type erasure. So this is no different.
I'm no JVM expert but from reading the article it seems like the chosen solution for value classes is to treat them all as a single L-type in the JVM where each primitive type is its own L-type. If I read the correctly, it means that if you have a Point value class then on the JVM level you'll be able to stuff any value class into there if you're so incline, just like with List<Point>.
Obviously we need to be concerned with fuzzing (moreso in C++) but here really we're just trying to have sensible defaults that aren't guaranteed because we can't design the language how we want from the ground up without making a new language.
Oh and there is a prosopal for this [2]. Personally, I prefer the Hack version.
[1]: https://docs.hhvm.com/hack/types/nullable-types/
[2]: https://openjdk.org/jeps/8303099
you seem to have ignored the question and answered a completely different one
> Now, one can argue that this is just smoke and mirrors with type erasure and it is but you can already put a Date into a List<Point> if you're so inclined because the JVM doesn't know the difference, hence type erasure.
And that's a massive problem that they're planing to solve with specialized generics.
> If I read the correctly, it means that if you have a Point value class then on the JVM level you'll be able to stuff any value class into there if you're so incline, just like with List<Point>.
I'm not sure what you mean. An L-type is an object reference. E.g. Ljava/lang/String, Lcom/org/CustomObject. The issue you're conflating is the erasure of List<T> to List<Object> and it's L-type Ljava/util/List.
> I prefer the Hack version
Hack/HHVM didn't have to worry about backwards compatibility.
---
The blog post does a pretty high level overview of the implementation, but my understanding of it is the following:
1. They are adding a new bytecode class flag for value classes. Bytecode descriptor for value classes are exactly the same (L-type).
2. Primitive wrapper classes will become value classes.
The difference from the CLR is that the JVM implementation is backward compatible with linked legacy bytecode. As they can accept a value class instance into their methods due to the same L-type. It's just additional metadata added to allow the JVM to stack allocate the class.
---
Separately, to handle generics:
1. Parameterized container classes will be flagged with a new bytecode to enable parametric attributes on initialization with the additional data of the parameters in the Constant Pool. Bytecode descriptor for classes are exactly the same with type-erasure, e.g. List<SomeType> erased to Ljava/util/List.
2. Initialization of parameterized classes are done with the additional metadata of the type argument stored in the Constant Pool.
3. The runtime does monomorphization of the parameterized class.
It doesn't seem too different to what the CLR does, i.e. runtime monomorphization. The difference is the JVM implementation is backward compatible with older type-erased code, i.e. the restrictions in Java due to type-erasure are exactly the same as before and the L-types don't change. It's just additional metadata added to allow the JVM to monomorphize the classes for performance.
---
In summary, value objects and specialized generics are backwards compatible with legacy bytecode. The JVM handles the compatibility. Of course, the newer bytecode is not forward compatible with older JVMs.
All that to be bytecode backwards compatible, although behaviorally there are some breaking changes. See https://news.ycombinator.com/item?id=48597943
Look at how Go did it. Any value type has a defined 0 value, and any variable of field of that type is initialized to 0 by default. So any un-initialized non-null able value type field could have the corresponding 0 value.
That's worse than null. Now every object has an invalid state. It works for Go because Go is trying to keep language complexity low. It has no good design principles behind it other than that. Also the zero value of a reference is null so you still haven't answered how a non-nullable reference field would work.
Sorry, I misinterpreted your question to be about non-nullable value classes, not non-nullable classes more generally. For reference variables, it seems that the a priori best approach would have been to generate a compiler error if the field was read before it was written; since this ship has long since sailed with final fields, it seems that the same approach would have to be taken - the "not null able" guarantee only applies after the class is fully initialized, and you can observe it as null during initialization. This is probably not a huge problem, given that initialization code always has to deal with a class breaking its invariants, since they are only established at the end of initialization.
Regarding the 0 value choice in Go, I don't agree that this is worse than null. It simply applies a design constraint that is not usually very hard to satisfy - that the 0 value of your type must have well defined semantics.
The compiler doesn't solve the halting problem so it doesn't know whether a field is read before it's written.
If you allow a nonnull field to hold null at any point then it's trivial to leak that out and have nonnull variables holding null all over the program, which is obviously something to be avoided.
Maybe you can say that if you read a nonnull field when it's null, that throws an exception. That might have its own knock-on effects since nobody expects reading a field from a valid reference to throw an exception, but it might be the best way.
I think you should require the code to be written in such a way that the compiler can verify the value is never read before initialization. There might be some subtleties in how to do that but I don't think it should be insurmountable.
It's completely insurmountable. It basically means you can't call any functions during initialization. Including the one that creates the object you want to point your nonnull reference to.
How can Kotlin do it?
Probably with hacks. Did you know a final field in Java can change its value? And I'm not talking about his reflection to make it non-final. With ordinary code only, you can read a final field before it's been initialized, so it still holds its default zero value. For example "final int x = calcX();" and have calcX print the value of x, it will be zero.
There's a whole bunch of specification language describing how constants aren't actually constant in specific situations.
I don't know Kotlin but I assume it does the same thing: until the non-nullable field gets initialized, it holds null and violates the type system.
Kotlin works around this by not exposing the backing field directly; a "field" becomes a "property" which has a getter and setter under the hood. Attempts to read uninitialized properties are compile-time errors. You can turn these into runtime errors using the "lateinit" keyword.
Kotlin still has a hole where you can run code in "init" blocks which are executed sequentially on object construction; in one, you can call a function that is defined after an unmodifiable property, and it will see the uninitiailized value.
Nothing stops me from sticking my dick into a blender either, yet it works fine for most of the things (the blender). Both Java’s notion of final and Kotlin’s nullability work great for 99.999 use cases and you really need to go out of your way to break them.
If you can get a null into a nonnull variable, it can propagate all over the program and people will be defensively checking for it everywhere - final is not like this.
A lot of the language rules are required to make its approach to nullability work. Hence odd keywords like "lateinit var".
`lateinit var` was not added to Kotlin to handle nullability, but to address specific Android design where system components like Activity cannot realisticly initialize fields in their constructors. Outside of Android it shouldn't be too commonly used.
"lateinit var" predates Android's adoption of Kotlin by years and was added because fields initialized after construction by frameworks are common in many contexts, but having nullability in the language makes that annoying.
so your complaint is about the blogger, not the Java language?
also, null markers are coming too: https://openjdk.org/jeps/8303099
Its just that they have to deliver things incrementally. This PR that introduces value classes/objects is already 200k lines long.
I agree, but I have seen the previous proposals/jeps and the discourse around them is rather discouraging. I hope this one can find it's way out of Draft, but I'll only believe it when I see it.
> it is this interpretation that kills off the null-safety debate entirely. Saying you have a variable that cannot be null is not a mentally taxing distinction, especially since everything is labelled thoroughly.
I think you've missed what this is referring to. It isn't about null safety (which is orthogonal) but about having reference/value projections analogous to Integer/int.
What the Valhalla team ended up doing is, instead of having two projections for each type, one with identity and one without, value types never have identity and so Integer and int are synonymous, and the memory layout is determined automatically based on context and optimisation decisions. This is why the semantics of == for the primitive wrappers (like Integer) were changed, as they now don't depend on whether the "reference projection" or the "value projection" is used.
> There is no reason to reduce the optional(!) safety guarantees you can offer with the excuse of "too mentally taxing".
This is not what happened here.
> and so Integer and int are synonymous
Except they're not, as I can do Integer x = null, but not int x = null. So an Integer is forced to occupy more memory, for very very unclear reasons. And this is also deeply weird - there is no other (mainstream?) language that allows null value types.
That's not quite how it works in Valhalla. Because Integer and int already exists, your declarations above will be interpreted with those meanings, but (assuming some TBD nullability annotation), they will be equivalent to `int? x` and `Integer! x` respectively. In other words, the nullability of a variable is a separate concern from the data type, and other than the different defaults on variable declarations (as these types already exist), Integer and int become the same type.
This may be true, hopefully, in a future version of Java, if the article isn't wrong. In JDK 28 with the Preview feature enabled, int is not nullable and Integer is nullable, and they are thus different types under the hood. Which also means that on most CPU architectures, Long[] will be just as inefficient compared to long[] as it was in any previous version of Java.
> int is not nullable and Integer is nullable, and they are thus different types under the hood
Yes and no, because in Java we have runtime types and compile-time types. The frontend compiler will treat these types as having different defaults on nullability, but they'll compile down to the same representation (when appropriate). I.e. if the compiler sees that some Integer variable is never null, it will compile down to the same thing it would if it were declared an int.
You're right, however, that on the heap, until the language adds nullability information, the compiler cannot generally know that an Integer will never be null (unless it's a final field), so it's likely that, unlike on the stack, you'll get a different representation.
It's not that weird. The goal is to enable existing types to be turned into value types without porting the users, so stdlibs and other libraries can mark types as value types without an API break.
That goal is an ideal and can't be reached perfectly. Converting a type to a value type will break clients that synchronize on them, or rely on identity for some reason. But such cases are rare, and can be weighed up on an individual basis when making the decision about whether to do it. Storing things in a nullable variable on the other hand is very common and changing the rules to prevent it would make every such change a source incompatible breaking change.
Nullable is just a different loadout state in Railway Orientated Programming. So, no reason to put different flavours of state into the language directly, when its a solved thing since (checks slides) 2012. There is just rails - going to A or going to B, depending on the trains loadout.
If you have language-wars about a concept going in and out of existence, that is a hint that there is demand and the language does not properly handle the demand or when it handles it, it creates mental overload.
> Value
> Errorstates
https://fsharpforfunandprofit.com/rop/As the pythons said: Get on with it!
They just decided to tackle non-nullable value types in a follow-on JEP. I don't think they're saying it's untenable. You don't eat the elephant in one bite and all that.
That said, we've been gnawing on this limb for a while...
Ill be old when null safety will finally arrive
This takes longer than game of thrones books
This is mainly for performance and memory layouts, it would not have improved safety guarantees of java.
It would have implicitly brought some null-safety to java with primitive-like classes that can not be null.
The non-nullability issue seems to be about performance, not cognitive load (search the article for "writes atomically"), though not articulated.
> very little faith that Java can be steered in a sensible direction here.
What? It’s been getting better with each release. Valhalla brings features that address key problems, and they didn’t rush to it either.
> a single type would have two projections: a value variant (flat, never null, behaving like a primitive) and a reference variant (a box that allows null). Across various iterations this was written as Point.val/Point.ref, and later they experimented with the Point! and Point? syntax.
This seems heavier? Having two representations and manually having to refer to .val or .ref?
You can argue that the extra flexibility lets you write safer (non-nullable) code but naively it seems more complex at the language level.
I mean, I appreciate the huge engineering and design challenges here, but C# had non-null value types in 2002. It had generic value types in 2005 and it gained not-null “types with identity” in 2019 and no-one has batted an eyelid. (Indeed the type system support for value types still includes stuff Java isn’t even considering yet.)
Saying the mental model is too hard is basically saying your userbase is stupid. This stuff is not tricky.
Yes, in this respect Java is 100% doomed. They've made a terrible decision and they're sticking with it for the sake of "consistency".
I think “Doomed” is slightly dramatic for preserving some decades old null ability conventions?
Like yeah, every field is final but omg non-null is a bridge to far! Wtf?
> But the difference in memory is fundamental. The JVM can now store the values themselves in the array, laid out densely one after another: 8 bytes per point (plus a possible null flag), in a contiguous block. No headers per element. No pointers. No jumping around the heap.
How much was this article proof-read? Didn't they just get finished talking about how heap flattening won't work for objects with > 64-bit representations? Their `Point` is at least 65 bits (two 32-bit ints plus the null flag). The "plus a possible null flag" and oddly short following statements seem to suggest this was some AI that got sidetracked by trying to make emphatic statements... oh and also the "[IMAGE: the same Point[] array in two variants..." block halfway down the page is unfortunate.
> No headers per element. No pointers. No jumping around the heap.
that smells of AI [1], and thus lazy writing. I'm all in for using AI to help you write, but if you don't put your voice to it then there's no reason to read it.
[1] https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing#...
> I'm all in for using AI to help you write
Don't be all-in. It's important for humans to be able to write for themselves, and also to stand by what's been written in their name, which is much less likely if someone/something else has done the writing.
(proofreading is another matter though.)
Also, the images were ruinously far off from what they intended to convey. Dude, just draw a picture by hand & take a picture of it.
That particular section is indeed AI, though other parts of the article aren't: https://www.pangram.com/history/89b28cd1-58e6-4065-9f1d-111a...
You see this in all the AI generated Tik Toks. What causes AI to use such a weird construction.
I learned that exact style of writing in a marketing workshop, pre-AI. It's effective, satisfying, and a random third thing I can't be bothered to come up with right now.
As a proportion of all easily crawled text on the internet, a lot of it will be random marketing copy. That influenced the writing style of early AIs, and since then everyone has trained at least partially on transcripts from every other AI chatbot
Oh my god did we inadvertently train AIs on idiotspeak.
It seems to be called the Rule of 3. see https://en.wikipedia.org/wiki/Rule_of_three_(writing)
Like Caesar's supposed "Veni Vidi Vici" saying, people seem to prefer and remember items when grouped in three.
I recall a public speaking film shown to my management science class starring John Cleese mentioning this rule of 3.
No, we actually trained it on standardised tests https://marcusolang.substack.com/p/im-kenyan-i-dont-write-li...
Thank you for sharing this. It brought together things I had suspected but not from his perspective. Also pleasant to read something that used rhetorical devices in a cohesive way instead of just as sprinkled on flavor packets.
There was nothing inadvertent about it. A decade of cultivating and harvesting millions of examples of this kind of pseudo-writing from underpaid internet piece-workers preceded LLMs.
In-advert-ently?
Given that this specific style is the result of being reinforced over and over again via RLHF, "inadvertently" isn't really the word I'd use.
> did we inadvertently train AIs on idiotspeak.
Nope! That is - training on lowest-common-denominator, low-signal high-noise "idiotspeak" was not at all inadvertent.
It's engaging and I doubt it happened by accident.
* Checks notes *
Reddit
Twitter
Facebook
4chan
Call of Duty chat logs
Every public marketing site
SlashDot
UseNet
...
Verdict: Yes idiotspeak was part of the training set, but no, it was not inadvertent. There's a smattering of Shakespeare in there, at least.
Wait until in 5 year's time all kids speak in rule of 3
Didn't you know? Evenly divisible numbers are infelicitous. That's why Atevi don't use them in polite conversation.
Not rule of one. Not of two. But three.
Exactly! But AI is here to stay. Sooner or later, even comments on HN will be 100% AI generated. And we won't be here to read them - our AI agents will. /s
That’s right. Because at some point, the volume of AI-generated posts and comments on sites like Hacker News or Reddit will overwhelm the ability of humans to read them all. So the only reasonable way for humans to participate will be to have our own AI readers summarising them, and posting furiously on our behalf!
I had that until I used Opus 4.8.
It stopped being infuriatingly sloppy and took time to ensure the article had integrity.
It did having said that I did burn through a lot of tokens trying to do a deep analysis cross data pipeline debug.
I really wanted to read this, it seems like a really interested subject. I can even forgive the AI generated images. But after a few paragraphs it became clear this was either fed through an LLM or worse.
Please, if you write a technical blog, or anything really: Stop. Stop letting the AI write for you. Nobody wants to read this.
18446744073709551616 possible values and you can't spare 1 for null? :)
TIL that Rust has NonZeroU64 which you can combine with Optional to get the required behaviour with only 64 bits per entry. [1]
[1] https://doc.rust-lang.org/std/num/type.NonZeroU64.html
Especially because signed integers aren't symmetrical. Reserve INT_MIN and you get 8 billion NaN values and multiplying by -1 always gives you a valid location.
Ah, INT_MIN. If I had a nickel every time I saw an implementation of inttostr/strtoint that don't properly handle it, I'd probably have about $5. So I too thought about possibility of it serving as a NaN of signed integers... but I doubt we'll see it any time soon.
Also, apparently, shifting a negative number to the left is UB in C.
Left shifting a large positive number is also UB. C made a lot of things undefined that would make much more sense as implementation defined.
Yep. Basically, if you take a signed int/long/etc. and a set bit shifts left into the sign bit — UB.
> a lot of things... would make much more sense as implementation defined.
Or even just defined. Apparently, the fact that shifting right a signed number is done arithmetically, not logically, is implementation-defined too.
Well, at lest bitwise not/and/or are (almost) fully defined even for signed integers, so that's something.
Well at the time it made sense not to force two's complement. But I would try harder to trim the UB list over time.
Java has always had this juxtaposition in language design where they don't want you to think hard about value types (hence no unsigned types), but the types themselves are precisely defined down to the specific bit pattern representation in bytecode. This is essentially hardcoded into the JVM and its bytecode specification and is too hard to change for compatibility concerns.
Luckily we have Valhalla, which is an admission that Gosling was partially wrong, and programmers who want to have an unsigned nullable non-zero 64-bit integral value type can just make one, and not have to pay outsized memory costs to do so.
If we're done paying homage to Gosling, can we get operator overloading for our fancy value types please? I have no idea if this is on the radar for Valhalla.
In many cases, NonMaxU64 and NonMinI64 (aka SymmetricI64) would be much more useful though. But Rust is aiming to eventually add a more general way to create types with user-defined ranges, such as the "pattern types" feature currently being prototyped.
The obviously used too much AI, I stopped after 2 paragraphs
The first two paragraphs are
> On June 15, Oracle engineer Lois Foltan confirmed what a good chunk of the industry had stopped believing: JEP 401: Value Classes and Objects will be integrated into the main OpenJDK repository and is targeting JDK 28.
> The change is so large that the remaining committers were asked to hold off on bigger commits during the integration. The pull request alone adds over 197 thousand lines of code across 1,816 files.
What in those paragraphs is obviously AI?
These days I'm having second thoughts about pictures that I am pretty certain can't be AI but just have that look. It's strange but I've noticed it happening more and more.
I mean I’m only answering that because you’re asking, nothing set me off personally there, but now that you ask:
« The pull request alone adds over 197 thousand lines of code across 1,816 files. »
I noticed that both Claude and GPT are fond of those kind of stupid accounting statements that don’t mean a lot in and of themselves, but look impressive in a « wow numbers » way. Which is kind of ironic since counting remains one of their weak points
Yeah its definitely inconsistent level of specificity. It's "roughly" 197 thousand files, and yet at that scale a human would call it 200 thousand lines of code, and then an exact count of files at 1,816 instead of a similar level of estimation.
For instance I might write this "The pull request alone adds nearly 200 thousand lines of code spanning almost two thousand files", or even better just "The pull request alone adds nearly 200 thousand lines of code" because really who cares how those are broken up into files.
As a human (as far as I know...) there is a decent chance I'd write it like that, depending on the exact numbers.
It said "over 197 thousand". That's what I'd probably say for a number in [197000, 197999], or maybe "under 198 thousand depending on where it is in that range.
Saying "nearly 200 thousand" is still 3 digits so doesn't save any space over 197 or 198, and I think with it only being 3 digits most people will assume only the last digit is rounded. 200 ending in a string of 0s does suggest it might be rounded to the nearest 10 or nearest 100, but it just could easily not be.
I'd almost certainly fully write out 1816. If it were common to spell out groups below 1000 like 100s and were going to that I might write it as something like "just over 18 hundred" or "almost 19 hundred", but I almost never see anyone use grouping sizes of less than 1000.
I understand ai hate but I would rather avoid a future where everybody talks in purposely weird and unstructured sentences to avoid being similar to ai
By necessity a lot of people write very similarly to how llm do
I'm tired of people jumping in to point out "AI, AI". The article is very good and informative. That is the only important thing. Geez.
No, it’s not the only important thing. The complaints about it should tell you that.
People care about provenance a lot.
Whether it’s a drawing my daughter did of her mother, a Picasso napkin sketch, a worn 1960s Stratocaster, or an blog essay, the provenance is value on top of the correctness of the item.
Strange comparison, the Strat has sentimental and historical value. I don’t collect and cherish articles about Java.
Yep, I used an example where the provenance value was obviously large to make it very clear.
>The article is very good and informative.
But you don't know which parts of it are true.
> Didn't they just get finished talking about how heap flattening won't work for objects with > 64-bit representations
In this initial commit. As was made clear in the JEP, this is just the first deliverable of a huge feature that, like all Java features in recent years, is being delivered piecemeal. Obviously, the point is to flatten larger values (the mechanism is already in the JVM; what remains is exposing the intent of "I allow tearing" in the language).
> This is exactly the moment where non-nullability stops being cosmetics and becomes a lever for performance.
Looks like they just missed the `!`. It should be `Point![]`.
I'm confused about the 2008 Bloomberg article image in the first slot... right after implying the effort started in 2014. With nothing mentioning anything in there.
Is there a way we can request a "flag as AI garbage" downvote for articles? Or should we just flag them?
I thought this was an ad bugging out. I use an adblocker. Very confusing.
I initially took it for an ad too, and just didn't bother looking at it. Then I noticed it was oddly small, and the more I looked the stranger it got.
It adds a fair bit to that "did anyone proof-read this? pretty obviously no?" vibe.
I've been sadly using too much Claude not to immediately recognize this verbal construction...
After reading a lot of comments in here, there is one thing that always repeats itself in Java/JVM-related comment sections on HN. There are a surprising number of people who have an idea of what the JVM or Java used to be and have very little idea of what it is today. It is a very fit predator in 2026. Does it have its warts? Yes, but the substrate is extremely good.
Agreed - you don't get great JVM takes on HN, it's out of fashion here.
Our work uses modern Java (26 w/ preview features - mainly for StructuredConcurrency), and it's fantastic. Do not regret it one bit, and that's coming from using both Haskell and Python at previous companies.
Many of us work on Java monoliths that started in the 2000s when it was in vogue and we still have to keep them chugging along on Java 8. Personally I'm familiar with all the new features that have come out in the last few years, but for my actual work, java is literally stuck in the past.
> we still have to keep them chugging along on Java 8
There's something else amiss here. Compared to other platforms, upgrading Java, even on complex codebases, has never been a nightmare for me.
The problem in a large codebase is keeping consistency when upgrading.
I upgraded a codebase of approx 100 kloc from Java 7 to Java 8 a couple of years ago. As I didn't want mixed patterns for the same thing throughout the code base I replaced most of the loops with their streaming equivalent. I had the luxury of having the budget for doing so.
Mixing patterns of newer language features alongside older ones can make the code base hard to read.
In this sense, Java is already the next Cobol. I usually ask one or two questions about class loading in interviews (of senior Java devs), the younger ones are frequently stumbling upon these, and they don't even understand why I'm asking this. Good old Tomcat days, when you could run out of PermGenSpace if you weren't careful :)
Good news is, Oracle extended extended extended support for Java 8 will not last forever, and eventually - if you work in a regulated industry - the company WILL have to pull the trigger.
On the other hand, "where there is muck, there is brass", so a little bit of legacy can be beneficial for some.
Yeah, that would be a more nuanced take. The comments I'm indirectly referring to are people who are literally unaware of these features and talk confidently as if they do not exist.
Any reason why? My entire company is on 21-25. Except for one project that decided to use sun.internal.* classes.
Paying back tech debt, being able to keep up with treadmills (even slow and smooth ones) is depressingly rare.
whats keeping you from upgrading?
Most don't even know there are plenty of JVM implementations to chose from.
A lot of the comments on here are a bit unfair on what is great work being done and even more awesome work (JEPs) in the pipeline for the future.
If Java was a child, imagine it being brought up by loving parents for the first few years (Sun) then it was thrown in a garage with some other children and neglected by its evil guardian (Oracle)
Neglected and unloved till JDK 8, its basically been playing catch up.
So when people say "oh so its now got structs or value types of X", yes it has but that's because it has been stunted in its development due to big bureaucratic and hostile corporate processes, but its free now and is getting love through the OpenJDK family.
I will continue to enjoy writing once and deploying anywhere!
> If Java was a child, imagine it being brought up by loving parents for the first few years (Sun) then it was thrown in a garage with some other children and neglected by its evil guardian (Oracle)
Whether you like oracle or not, this is simply not a correct description of Java's history. It was brought up by loving parents, who due to financial problems had to put Java into a foster home where she was neglected.
But later it was adopted by new, loving parents (Oracle) and she bloomed and become a healthy and stable adult.
Like, it was Oracle that completed the open-sourcing of the platform, making OpenJDK the reference implementation. They also open-sourced the previously proprietary jfr, mission control etc tools.
They also managed to keep many of the original members of the language team, which is quite rare during these acquisitions, and Java has seen a huge improvement both on the language and runtime front.
Yup. I was around for and skeptical of the Oracle purchase of Sun. I was worried about what it would mean for Java.
The Java team has been delivering nice language and environment improvements regularly since Java 10.
Well, Oracle may have done fine, but IIRC open sourcing the JDK was Sun's very penultimate move on its deathbed. Oracle inherited the license to the trademark, but the actual JDK was already free.
It was neglected during its last few years at Sun. Oracle started moving it forward at never before seen pace, while mostly maintaining backward compatibility (unlike .NET that "did things right from the start", which is what .NET Framework/.NET Core/.NET split/rewrite is according to some in this very discussion. And .NET had Java to copy and learn from, but still fucked up.)
Same with MySQL, btw. "Dead" according to this site, risen from the dead under Oracle for those who actually know it.
I have no idea about MySQL, but what I always remind people is that HN is more GQ/Vogue than the NYT. It focuses on novelty and aspiration more than on coverage of what the industry is actually doing. Like others, I enjoy it because it's aspirational/inspirational, but I try not to confuse it with a reflection of reality. E.g. there's little correlation between programming languages that are discussed a lot on HN and those that achieve (or don't achieve) big and long-lasting success.
In fact, much of the software industry, which writes the software that matters to our lives the most and holds most of the value delivered by software in general - the software that processes your credit-card transactions, runs your bank, sorts your mail, routes your phone calls, manages the manufacturing of your car and the shipping of your packages, holds your healthcare information, schedules and tracks your flights, and manages your law enforcement and your government - is barely represented here because the organisations that write most software aren't software companies, and they don't tend to publish technical blogs.
Where do you find more nuanced discussions?
I don't think the issue is nuance. The issue is what people enjoy talking about. E.g. here's what the industry probably looks like in terms of how many people work in different languages: https://www.devjobsscanner.com/blog/top-8-most-demanded-prog... Now compare that to the languages most frequently talked about on HN. The stuff on HN isn't a reflection of the industry, just like Silicon Valley doesn't produce most of the world's software (or most of the world's software value).
People come to HN because they want to hear or talk about things that most people don't usually do; it's more interesting because it's different! I'm not saying they always say positive things, but positive or negative, this is what we like talking about online. This is why people buy GQ or Vogue. If you want to talk about boring work stuff, talk to people at work :)
> If Java was a child, imagine it being brought up by loving parents for the first few years (Sun) then it was thrown in a garage with some other children and neglected by its evil guardian (Oracle).
> Neglected and unloved till JDK 8, its basically been playing catch up.
These two statements are contradictory. The last Java version under Sun was in 2006. Oracle bought Sun in 2010. JDK 7 came out in 2011 and JDK 8 in 2014.
The team largely remained the same, and the main difference was that Oracle ended the neglect and funded us more, which is why Java picked up the pace after the acquisition.
> its basically been playing catch up.
Catch up with who or what? There are only two languages in the world as popular as Java or more: JS/TS, and Python. People who are saying Java is "playing catch up" usually compare it to languages that are doing far, far worse than Java. It's just that people who like certain features think that the language that has them is doing poorly despite them and not because of them. Many times I see people insist that other languages are "doing it right" (or better than Java) even though it is clear that the people who say this are in the minority when it comes to preferred features.
> So when people say "oh so its now got structs or value types of X", yes it has but that's because it has been stunted in its development due to big bureaucratic and hostile corporate processes, but its free now and is getting love through the OpenJDK family.
If anything, the opposite is the case. Managers love to see things ship quickly. It is our technical leadership - all people who were there in the Sun days - who insist we have to move deliberately and carefully and get things right. You can agree or disagree with the decisions, but comparing Java unfavourably to languages that are doing far worse is unconvincing.
Rather, what I think the vibe is because Java is not as popular as it was in, say, 2003. And it certainly isn't. But guess what? No other language is, either, because that time was anomalous not only for Java, but for the entire software ecosystem, which had never been as consolidated and unfragmented before or since.
Yeah. I agree. As a C# fan I discovered one day the change process and release notes. Like C# it does still have strong momentum in the language design space. It was a joy observing the last 10 releases.
>> I will continue to enjoy writing once and deploying anywhere!
Except to the browser, iOS, embedded systems...
WebAssembly is the real write once deploy anywhere tech now. JVM had its turn and lost.
Embedded systems? Like sim cards? There's even real time Java, I think they used it for some missile guidance stuff aswell at some point
> Embedded systems? Like sim cards?
Serious question: I remember the old installer, six billion devices or whatever. I’ve heard about Java ME, old set-top boxes and DVD players, etc.
But how much of that is active today. I can’t say I’ve ever seen a job listing for an embedded Java developer or even Java ME in my entire career. Are people actually still using it?
Actually yes. Pretty much most credit cards are in fact JavaCards.
Weird but true, and quite obscure.
Yeah I didn't mean it as praise for Java (SE, ME, or whatever), but I don't think you're better off finding embedded WebAssembly jobs
https://github.com/bytecodealliance/wasm-micro-runtime https://github.com/WebAssembly/wabt/blob/main/wasm2c/README....
ISTR Siemens uses wasm2c to compile Wasm for a bunch of embedded devices runninng Zephyr RTOS.
Fair point, but translating to C is almost cheating ;)
Sure, but it's a trick not available to most JVM languages.
Yes, Aonix, nowadays belongs to PTC, still in business.
To take your analogy further, not only was it thrown in the garage, but it was used to sue for billions of dollars in child support (Google) so really it had just become a cash grab.
Anyway, I wouldn't even call Java "stunted". It made choices, some reasonable, some not, and those are incredibly hard to fix later. Heck, just look at C++. Semi-compatibility with C is (IMHO) an unfixable 150 foot albatross around its neck and so many versions from C++11 onwards have simply been about making that 150 foot albatross more bearable.
I personally think treating all value classes as a single L-type in the JVM (like primitive types, basically) is a fairly neat solution to a difficult problem. But all this comes down to the original Java 2 decision to implement generics as type erasure to maintain backwards-compatibility, something that C3 NOPEd out of as a result.
You could probably a whole tech thriller on the evolution on Value Types in Java.
I’ve been reading the mailing lists and watched all videos on the topic and it is truly inspiring how much they managed to consolidate the design to something that always looked like java.
But while also going far deeper in granularity and understanding what it even means to be a value type and what optimizations can be done where
And the only syntax change is adding 'value'.
There will be null-restriction type modifiers later on (e.g. declaring a variable as "Integer! foo")
It’s more nuanced than that if you include tearability and implicit constructors
> But careful: == looks at internal state, which isn’t always what the object represents, so for “is this the same data” comparisons keep using equals.
So == for value classes will basically be like memcmp(). That is a bit unfortunate, as it breaks encapsulation, exposing implementation details. Client code can use this to do case distinctions based on how a given value is internally represented. In a way, it’s worse than identity comparison, because identity comparison at least doesn’t expose internal state.
Value types are a concept very far away from the "magic black box organism" school of OOP thinking. It's not a novel way of doing classic OOP (does anyone still do that?), it's a way for a language born in OOP ideology get one step further into the post-OOP world.
That’s just not true, you can have a completely value-based language without OOP that still doesn’t leak implementation details of the values, while also supporting UDTs.
OOP isn't just about values vs objects. Yes, the idea that everything needs identity is a big part of the problem. But another big problem is the idea that the implementation and representation of types should be hidden by default. The mindset that there isn't a known and useful data representation for a given type. That everything is done by methods parameterized by a type. It's a misguided idea. There is a place for objects and implementation hiding. But the idea that this should be done on a type granularity is a complete and utter failure.
To see why, consider that to do any useful work, data from different objects (also from different types) has to be combined. To be able to do that in the OOP framework, the encapsulation has to be unwrapped. That's why Java code is littered with getters and setters that don't do any useful work at all, they just make it too painful to get any real work done.
Again, there is a place for objects and implementation hiding, but it's at the highest levels of an architecture where different components get integrated.
All of this would be valid, except that value classes still pretend that their fields can be private.
This also has huge implications in a language that emphasises dynamic loading like Java. And it also flies in the face of all of the pretenses that ABI compatibility is sacrosanct and no feature that breaka it can be considered, that the design team often touts.
Why pretend? "private" on value types just means nothing to see here except when you happen to be one of the functions conveniently namespaced with the struct.
But I'd say that GP's complaint about inequality leaking makes no sense anyways, because what could be more unequal than different implementation, or different internal state implying different behavior down the line? The public subset isn't some arbitrary interface that could have different implementations. And even then, "equals under interface I1" would have to be considered a very special type of "equality", not the general case.
There is no requirement in the Java language to use getters and setters.
But why are there so many of them?
Not if you do DDD where a calue type has exactly those semantics and for record types this is actually a free lunch.
I wanted to comment on this as well. The article mentions it but if you've never used Java in anger (is there any other way?) then readers may not understand the true implications of this because it's a breaking change, something Java rarely does. I'll explain for the non-Java people.
Java separates checking identity and equality for objects. == basically checks if two pointers are the same. Equality is a subjective concept based on an interface (ie equals/hashCode). So this means:
There's a lot going on here. The complication is that in previous versions of Java (and I'm not sure when this changed), integers below a certain value would be replaced with canonical types below a certain value. I think it was 128 but its's been awhile. This led to the difference between 10 and 1000. That's now changed, I suspect because the above comparisons are being implicitly unboxed. That didn't used to happen either. I saw this because the Integer/Long comparison used to return false and it's now a compiler error so there must be unboxing going on.You may still be able to get the old behavior through variables too.
Anyway, if value classes lose identity then == changes from pointer equality to bitwise equality. That will hopefully resolve a bunch of corner cases like this but it is a breaking change, technically.
https://github.com/openjdk/jdk/blob/jdk-27%2B27/src/java.bas...
It could also be true if the instances were created through auto-boxing (e.g. arrayList.add(10); arrayList.add(10); arrayList.get(0) == array List.get(1) //would return true, but false if you used 1000 instead of 10).
Yes, because auto-boxing is just compiling to Integer.getValue under the hood, the bytecode for Integer.getValue(1) and ((Integer) 1) is the same. They'll both compile to something like:
Sure, I was just talking about Java syntax, not the bytecode internals.
So you've made my point in showing how complex this is because you're incorrect [1][2]:
> By default, Java maintains a cache of Integer objects for values between -128 and +127.
[1]: https://stackoverflow.com/questions/3130311/weird-integer-bo...
[2]: https://dev.to/marzuk16/understanding-integer-caching-in-jav...
it's easier to remember that it originated from the Byte range, where all bytes could be kept in. Character didn't have negative values so it did [0-128) instead. Long and Short are the same as Byte.
Years before the autoboxing/Integer.valueOf() caching stuff (and before generics), (I) used to have IntegerProvider that did similar stuff to higher ranges. Personally, I have considered autoboxing on integers net-negative for Java
> new Integer(10) == new Long(10) // compiler error, used to false
wait, really? I thought introducing _such_ incompatibility was not allowed
If your bags of data have internal state, there's something wrong with your bags of data. I assume that the Java guys thought far enough to either exclude padding from comparisons or force padding bytes to be zero.
It should work even for strings: They will surely continue to be heap-allocated, and memcmp-ing pointers (inside the new "structs") is exactly an identity comparison.
There’s nothing wrong with having non-normalized representations, that’s why there is equals().
For example, you might have a value class for representing (limited-precision) fractions using two longs internally, for the numerator and denominator. For efficiency trade-off reasons, you don’t want to always shorten the fraction. But now client code can distinguish 2/3 from 4/6 using ==.
Scenarios of that sort are conceivable where this actually leaks sensitive information. In any case, it creates dependencies on implementation details where you don’t want to have them.
When designing a value class, you are now in the dilemma of either always having to normalize the representation, costing performance, or having your class be a funnel for leaking implementation details.
Java can also distinguish a 2/3 object from a 4/6 object using == when they are not value types. It can even distinguish a 2/3 object from a different 2/3 object.
The difference, as I tried to explain, is that identity comparison does not expose the internal representation. So while you can know that two objects with the same value are different objects, you can't know whether they internally represent the value as 2/3 or 4/6. With value classes, however, the latter can expose information about the provenance of a value.
Would you use a value class if you wanted to represent a fraction?
[dead]
Well. I'd be upset if custom operator==() for plain-old-data structs was removed from C++, but Java never had it to begin with, so for Java, it just means that you have to fall back to using traditional classes (or compare using something other than ==) if you need such "fancy" features.
> There’s nothing wrong with having non-normalized representations
There is a lot wrong with that: complexity, bloat, and slowness.
> But now client code can distinguish 2/3 from 4/6 using ==
That's a great way to obfuscate code. Not a good idea. The right way to do the comparison is, just make a function called CompareRational().
the whole point of value class is that they should not encapsulate state, i.e. its a totally transparent data holder
> we want the JVM to be able to treat them as efficiently as primitives.
They want basically to solve the main Java design flaw with (almost) everything is a reference paradigm. C++ and Rust have had value-types from day one.
> 64 bits, including the null flag
So, this basically makes every value-object optional, adds extra overhead and makes code less safe to null pointer dereference errors.
> but a class with, say, two int fields or one double may not fit in an atomic write and end up as an ordinary object on the heap anyway
So, the whole optimization is applied only for very small structs with no more than two scalars (or so). Did it worth to spend 10+ years of development to achieve this?
That's like going to a steak bar and saying that this place sucks after the pre-dinner snacks.
Java JEPs are piecemeal, there is plenty other JEPs building on top.
A bit fuzzy and dramatic; luckily the original documents are quite readable:
top-level page: https://openjdk.org/projects/jdk/28/spec/
JEP status: https://bugs.openjdk.org/secure/Dashboard.jspa?selectPageId=...
I'd really like to see someone trace related developments in C#, Swift, Java, and Rust, since they all have been racing to catch up to hardware, and I believe they are cross-pollinating.
(My concern is how all this will affect the FFI memory shares.)
FWIW both Swift and Rust have had value types and generics that abstract over unboxed values since the start.
Not sure I would call them the same - not too familiar with Swift but for rust you probably mean types implementing the Copy trait?
But Java's value types are a higher level semantic feature, these objects may do a Copy or a Clone based on heuristics. So probably not the exact analogue but of course rust being a lower level language it can express where and when memory is allocated.
I know its a faux pas in the Java world to acknowledge the existence of .NET, but how does this differ from .NET structs?
Value types, generic specialization, boxing - a quick skim makes it looks like they picked the same choices.
C# actually has a fair amount of gotchas and Java aims to make these explicit. So where C# mostly copied C from a low level perspeCtive, the Java guys approached this high level and analyzed in detail which constraints give you what kind of benefit.
So where in other languages, the struct/class taxonomy is binary, Java allows more granular control, reflection the semantics of the underlying domain. Snd as it turns out, structs have a wide range of footguns, especially in a parallel context.
Could you actually explain/exemplify any of the gotchas and what's been made better (or is this just handwaving)?
Part of the reason Java hasn't reified generics is because C# did and it was a real big headache that also limited non-C# languages on the C# runtime (CLI?). Everything had to be recompiled to work with newer C# runtimes. While it's pretty easy to run a bunch of language on the JVM (Javascript, python, ruby, clojure) doing the same for C# is somewhat a nightmare, particularly for non-type aware languages.
For example, Imagine you have an api like `void do(List<Foo> foos)`. In the erasure environment of the JVM that looks like `void do(List foos)`. From python it's pretty easy to call with a `foos = [Foo()]`. But not so much if your python implementation needs to figure out how and if it can coarse it's `List` type into a `List<Foo>` type.
I don’t think that’s the case. You can absolutely implement a type-erased language on top of the CLR. Your language will just have the same constraints of a type-erased language like Java.
Having reified generics in the CLR just lets you store more type information. There isn’t much of a trade off for CLR end-users.
Compare this to the constraints and workarounds that Kotlin and Scala have due to type-erasure on the JVM.
> Compare this to the constraints and workarounds that Kotlin and Scala have due to type-erasure on the JVM.
The creator of Scala disagrees: https://youtu.be/Xn_YpUtXWT4?t=850
Not necessarily. You can ignore the reified generic system in the CLR and monomorphize it in the CIL output for your language. Debugging for users is usually a nightmare though due to the monomorphization. The benefit of a type-erased runtime is the interop between the languages built on the runtime.
The monomorphization of CLR generics is what NativeAOT does, though it doesn't support some C# features.
TypeScript is essentially C#, but with type-erasure and lacking the low-level struct & pass-by-reference features.
I do think the C#/CLR struct implementation is better though.
You CAN do it, but it's much more difficult.
And as far as I'm aware, both kotlin and Scala don't really suffer due to type erasure.
I mean, the language is what it is. But, it definitely constrains the language developers. Especially when considering interop with other JVM languages.
That being said, it is easier to write a language on top of the JVM with good interop, since there are less ways to implement features. Essentially, your language has to interop with Java.
And it is harder to have good interop between CLR languages because there are more ways to implement features. Essentially, your language has to interop with C#.
IronPython did just fine with reified generics.
There's also https://github.com/ikvmnet/ikvm that converts Java bytecode to CIL; essentially Java on CLR.
Actually no it didn't, DLR was created exactly to support dynamic languages on the CLR.
Nowadays largely abandoned, and I think not everything survived the transition from .NET Framework into modern .NET.
The DLR is just a shared library. It never changed anything about the CLR under the hood nor did it change anything about how Generics worked in the CLR (being the most relevant part of the thread here). IronPython could instantiate Generics just fine, and did just fine working with them.
The DLR is not "abandoned" so much as "complete". Everything did survive the transition into modern .NET and IronPython 3.4.2 runs just fine on .NET 6+ [1]. (For those trapped on the ugly side of the Python 2/3 split, even IronPython 2.7.12 runs on .NET 6.) Most of the "magic" of the DLR is shared with C# Linq in interesting ways (the System.Linq.Expressions AST) and sort of "has to survive" if only to properly support IQueryable<T> (and wilder relatives like IQbservable<T>, the Q is not a typo) even if most people aren't actively using DLR languages today (nor that much usage of C#'s `dynamic` keyword).
IronPython is a community supported (truly open source) language so doesn't get as much attention now as it did in the brief "first party" support era, so some may call that "abandoned" but F# has always lived in that gray space where it is primarily "community supported" more than "officially supported" by a dedicated team at Microsoft.
[1] https://github.com/IronLanguages/ironpython3/releases/tag/v3...
The addition of dynamic, and JIT being aware of IDynamicMetaObjectProvider also mattered.
Even though most of the communication around dynamic was about COM support and Excel.
IDynamicMetaObjectProvider mostly just caches and returns System.Linq.Expressions for various asks, so again most of the JIT awareness is still just System.Linq.Expressions awareness.
The COM support is by implementing IDynamicMetaObjectProvider in a cross-language reusable base class.
The C# `dynamic` keyword adds some smarts about IDynamicMetaObjectProvider to the C# compiler, but those smarts were never seen to be needed as a low level tool in the CLR itself. And again, once the C# compiles the IDynamicMetaObjectProvider calls, those mostly just result in System.Linq.Expressions for the JIT compiler to optimize in the same way it optimizes other usages of Linq.
Yeah, that’s a different issue. Statically-typed languages, including type-erased languages, are fine on the CLR. Dynamically-typed languages are a different beast.
I suppose DLR would be comparable to GraalVM/Truffle.
The difficulty of implementing a dynamically-typed language directly on the CLR and JVM are about the same. Though, it would probably be more efficient on the CLR with access to lower level operations for memory management.
I think an interesting project would be to implement a CIL interpreter on GraalVM.
DLR inspired the addition of invokedynamic opcode on the JVM, which is actually the foundation for how lambdas get generated, many still think nested anonymous classes are used.
GraalVM already handles LLVM bitcode, much cooler than plain MSIL.
And here there is another example where Java ecosystem ends up being better.
MSR had a compiler framework similar to GraalVM, called Phoenix, it was going to replace VS, LLVM style, instead it died and what is left are a couple of research papers.
> many still think nested anonymous classes are used.
Anonymous classes are still used (sometimes). It simply depends on the circumstance of the lambda.
For example, this will result in a new anonymous class being generated.
The class gets generated to capture the `s` variable. Indy gets used in the `filter` method because the incoming lambda or method reference could be several types of method calls. For example, a constructor, an instance method, or a static method (I believe there are few more in the JVM bytecode).What won't generate a new anonymous class is this sort of lambda
That will generate a new method on the parent class which ultimately gets called. Since nothing is captured it can be directly called without a new instance being created.I had another idea given Brian's talk on the matter.
Never bothered to actually look into the generated bytecodes.
Surprisingly hard to find good docs on this. [1]
I was wrong, it looks like the case I gave is one which doesn't result in a new anonymous class being generated. Instead the lambda metafactory gets involved to avoid that allocation.
I apparently didn't see what I thought I saw. I thought that I had seen new `lambda.$1` classes being created in call stacks when debugging. Maybe I did, but the lambda was serializable (we have that in some unfortunate places in our code base).
There are still cases where new classes get generated, but that's pretty much just for serialization.
[1] https://cr.openjdk.org/~briangoetz/lambda/lambda-translation...
I've been let down by structs in C# repeatedly. First of all, there are no constructor guarantees and you can never fully avoid them representing an illegal state. Which, wouldn't be so bad if there was some kind of post-construction validation, but this also isn't part of the language.
This is fine if you hand-roll all your code yourself, but I often use mapping libraries to lower the code footprint and the problems resulting from schema changes are subtle and fly under the radar. This is different from classes with hard construction guarantees, which Java would offer with their "integrity by default" mantra. Where you can opt out of integrity for performance benefits (which is also part of the design).
And Nullability in C# is an absolute nightmare. The type system has completely different rules for nullable types that generalize over classes and structs and there is no generic such as a "Nullable type".
It's just lots of minor annoyances that don't form a cohesive whole.
I hate to say it. But thats user error. The struct paradigm is different from classes. Structs are meant to be plain-old data types; simply a typed span of memory.
Structs are values, classes are entities with encapsulation.
The shape of the state would be structural. Whether or not the data in that shape is valid is behavioral.
Structs are useful when working with spans of memory.
Another example of a good usage of struct is Guid, which is 128 bits of data packed together.
The C# equivalent to Java ‘value class’ would be a class with a struct encapsulated for data. The data is flattened and allocated on the heap like Java. Similarly, escape analysis could stack allocate the class at runtime.
This is what makes the nuances of Valhalla's Value types so compelling. The idea are granular structs with "Integrity by default", where you can selectively give up constraints on class design to get performance characteristics.
Structs in most languages simply bunch a couple constraints together to get another set of performance benefits, but there's no law stating that they couldn't be singled out. In the design of Valhalla, it states that types can come in 4 buckets:
1: Fully identity classes (total control, mutable)
2: Value Based classes (no mutability, but full integrity and dense memory layout)
3: Implicitly constructed values (forced empty default constructor for swift bulk array initialization)
4: Tearable Values (No cross-field integrity during runtime for parallel access)
And I bet that for a vast majority of developers, #4 will come to a shocking surprise, thinking "values are threat safe" because they are told to use immutables.
This way of splitting up structs is the real interesting part of Valhalla, but this shitty AI-generated article buries everything interesting.
Imo #4 is why it’s not that useful. If the data is larger than an atomic read/write op the data isn’t flattened and it’s a regular object with value equality and immutability.
You have to opt into force flattening, and then it’s the same as a struct, except it’s still heap allocated without escape analysis. You still have to implement synchronization to prevent tearing.
Static code analysis can give you a warning for potential tearing of structs.
DotNext.Threading provides Atomic<T> to enable high-performance atomic operations on structs without heap allocation.
https://dotnet.github.io/dotNext/features/core/atomic.html
The design of value classes just seems counteractive to its purpose: memory management. If I want to manage contiguous blocks of memory, let me manage contiguous blocks of memory. If I want to allocate something on the stack, let me allocate something on the stack.
The paradigms of struct vs object are too different and they’re trying to combine them into one.
It is beyond me why I would get downvoted for legitimately pointing out shortcomings. I find it honestly frustrating how some people believe that “their language is best”. Until you point out real existing inconsistencies…
The gotcha is the potential boxing of structs onto the heap, but that can be avoided using `ref struct`s.
https://news.ycombinator.com/item?id=48599273
Why would you presume the parent is "just handwaving"? It's odd how people in the .NET community struggle to earnestly engage in conversation with Java folk. The reverse isn't true.
The article has a section about that.
For me, a struct in C/C# can be modified and is passed by copy while a value class can not be modified and is passed by value.
I do not think you can do stack allocation in Java.
Like @layer8 said, pass by copy and pass by value are the same.
C# copies C++ behavior where you can pass a struct by value or reference, and you can mark the parameter as readonly. C# also has in/out parameters. Essentially, you can program in C# exactly like you would in C++.
https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
The footgun with C# structs are that you can accidentally box them onto the heap. To avoid that you can define `ref struct`s that cannot be boxed. `ref struct`s follow the C# disposable pattern.
https://learn.microsoft.com/en-us/dotnet/csharp/programming-...
https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
I don’t see a difference between pass by copy and pass by value.
The mutability difference is that part of a struct can be modified in place, which value classes can’t: the value of a complete value-class variable (or array slot) can only be modified (reassigned) as a whole. This is presumably because object references to value-class objects can be created, and those objects should be immutable so their identity doesn’t matter.
I think pass by copy is a consequence of being modifiable.
The other solution is to stack allocate and pass a pointer but as i said, unlike in C#, i do not think it's possible to do that in Java.
In Go, you can stack allocate but when you send a pointer (that escapes), the compiler will heap allocate the object.
My point is that pass by copy and pass by value do the same thing, they copy the value representation. In other words, pass by copy means exactly pass by value.
Actually, Java only has pass-by-value, even for reference types. (The same way as C does).
People really misuse/misunderstand this term: Java objects are passed by their pointers ("references") being copied.
The alternative is pass by reference, which is done by e.g. c++, rust, who actually have references (Java doesn't). A good litmus test is whether you can write a swap method that actually changes your local variables.
Rust is also “pass reference by value,” not pass by reference.
For me, the difference is that if methods are inlined, the compiler is still required to do a copy for structs but not for value classes.
I do not know how this is called.
I think that's mostly a semantic difference - Java avoided the problem of strange lifetimes, captures, tearing by fixing the semantics as immutable value objects, while C# has to deal with these issues.
But under the hood it can (and will) do a modification in place.
The C# equivalent to Java ‘value class’ would be a class with a struct encapsulated for data. The data is flattened and allocated on the heap like Java. Similarly, escape analysis could stack allocate the class at runtime, and they can be scalarized like C# structs.
Java ‘value class’ only flattens if the total size of the class data fits within an atomic read/write op. You can force it to flatten, but you may have tearing like C# struct.
Even closer would be a C# ‘readonly record struct’. Though, it would be allocated on the stack unless you box it.
I made a comment on my understanding of the difference in implementation here: https://news.ycombinator.com/item?id=48606173
The ramifications for backwards compatibility is that the JVM won't have CLR features such as stackalloc (allocation of blocks of memory on stack), ref parameters (pass-by-reference of stack allocated value types), and all the other low-level/high-performance programming features available in the CLR.
> allocation of blocks of memory on stack)
Why couldn't it be done? Like sure, it won't happen in every case (e.g. too big value classes), but for a typical local variable of a value type, it's a trivial optimization to make it stack allocated. Even now it happens quite often (requires escape analysis), but the semantics change of value classes allows for it to be done "freely".
C# stackalloc returns a ‘ref struct’ which has certain restrictions and would be a Q-world type.
Java chose to go with an L-world implementation where everything is still a reference type on the heap, but memory management is more efficient via flattening. That’s why it’s a ‘value class’ and not a ‘struct’.
Primitive wrappers are scalarized into registers.
Stack allocated value types would have different semantics and is incompatible with the L-world implementation. Sure, they could implement it, but it would be the Q-world implementation that they decided to forego.
They can do automatic stack allocation for optimization via escape analysis as you mentioned. But, stackalloc is user allocated.
https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
Functionally they don't - java is just catching up with (by now) ancient practice.
The false dichotomy of
> A struct in C# has identity and mutation, so the semantics of copying on assignment or passing have to be precisely defined, which gives a heavier model for the programmer and less freedom for the runtime.
Doesn't really match with what they're describing. While yes, it will not have identity in a java class ref sense, it of course will still have identity in being a unique structure in memory at a certain address. This is just splitting hairs about Java nomenclature.
> it of course will still have identity in being a unique structure in memory
No, it will not. The design allows multiple objects to share one structure in memory across multiple records, or not have such a structure at all (see Scalarization in the article).
> The design allows multiple objects to share one structure in memory across multiple records, or not have such a structure at all
Yes. I fear you are missing the point.
I don't wanna badmouth Java people, but how they push the idea that this thing is some sort of genuine breakthrough that took multiple PhDs years of cutting-edge research to implement, when in fact they basically copied what .NET did from basically year 1, is not a good look.
Again, not trying to turn this into a .NET vs Java thing, I'd have been much happier if they reached some new and interesting conclusions.
> genuine breakthrough
Well, it is - because they had to make it with almost perfect backwards compatibility for one of the most popular languages with trillions of lines of code produced over decades.
Sure, adding it to a new language is not hard. Adding it to Java which has primitives, generics and boxing, finding ways that seamlessly cover the differences between objects and primitives, while trying to plan for the future is hard.
As a general note, if you come to the conclusion that one of the best designer teams on Earth "basically copied what .NET did from year 1 is not a good look", then maybe your mental model needs adjusting on how these stuff works? Java has a public mailing list, you can browse through the related discussions. Implementation is the least of these things. But I can assure you they most definitely know what they are doing.
> because they had to make it with almost perfect backwards compatibility for one of the most popular languages with trillions of lines of code produced over decades.
At what cost? A key benefit of value types is improved performance but AFAIK Valhalla doesn't even let you pass them by reference. Efficiently passing them through registers is great but won't help you out with larger value types.
idk maybe java should adopt something similar to rust's "edition"?
Correct me if I'm wrong, but Rust editions are a source code-level feature. So given you have the source code of newer and older rust code, you can compile them together.
That's materially distinct from Java's model of basically dynamic loading already compiled class files. Though class files do have "editions", and there are extra code to deal with different versions. But still, it should be possible to e.g. send a new value class to an old library's class that has never heard of them, and that should just work.
The important thing is that Rust editions affect semantics and name resolution. In such an analogy, JVM bytecode is the equivalent of Rust code - various semantics are baked in, but stuff like name resolution isn't (at least not completely).
Except of course they are breaking backwards compatibility, in relatively subtle ways, for anything that uses the standard library wrapper types. So every use of Integer, Boolean , etc is an opportunity for either a compilation error or a runtime bug.
Honestly, if you're relying on `new Integer(999) == new Integer(999)` to be false, you've earned your bug.
>I don't wanna badmouth Java people, but how they push the idea that this thing is some sort of genuine breakthrough that took multiple PhDs years of cutting-edge research to implement, when in fact they basically copied what .NET did from basically year 1, is not a good look.
Oversimplifying a big semantic and backend change to a huge codebase on which some of the most crucial customer and government and business systems depend on, and which has to be made as seamless, correct, and performant as possible, to "they just copied .NET", just because .NET has the same functionality, is an even worse look.
It's a "HN "Dropbox is just rsync + some scripts"-style bad look.
This is exactly what made it so difficult. It is much easier to have a feature like this from year 1 than to add it to a language that has grown and evolved for 18 years already.
I agree with this sentiment. The work they put in deserves a lot of respect, and took a lot of effort, no doubt. It's just the framing they push to the public that could use some work.
The article is shit, the actual concept and roadmap goes well beyond the capabilities of C# or the CLR.
Footnote 6 "How is this different from struct in C#" is inaccurate. Since the article is littered with AI-generated images, I assume the writing, or at least the research, is littered with hallucinations?
> [IMAGE: the same Point[] array in two variants: “before” (an array of arrows → scattered boxes with headers) and “after” (a uniform strip of number pairs)]
The `Point[]` in the image tag of your LLM output crashed your image generation post processing.
> Will I get a fast, flat `ArrayList<Point>`? Not yet.
Sad. Hope they can do this by the next LTS JDK.
As I understand it, this is anyway an extremely limited perf enhancement - for any class whose data size isn't guaranteed to be atomically writable on your CPU, after including the nullability overhead, it doesn't do anything, basically. On a CPU where 64 bits is the max guaranteed atomic read/write, even Point[] will not get optimized, since you need at least 65 bits of memory for a point value (since it has two 32 bit int fields, and it needs an extra bit to specify if it's null or not - so in practice it will take up 72 bits at the very least, possibly more with alignment requirements). But even after fixing this, if you have 3D points or if you need 64bit coordinates, your value type 3DPoints will still be individually heap allocated and your 3DPoint[] will store pointers to them, just like today, on most processors.
Given that the JVM could already do escape analysis and allocate regular classes on the stack in certain scenarios, it's very unclear what benefit, if any, this will bring for normal processors for anything except the base wrapper types - even after implementing generic support and nullability for value types in a future JVM.
Which is why this is the wrong approach. Again. This is a major misstep.
The core insight there is to separate value semantics (no identity) from reference (itself) semantics (nullability). While this particular change can bring very limited amount of improvements it’s still does some - probably smaller to no object header + more guaranteed optimizations for variables on stack.
It’s when they land next part (nullability) it will shine fully - particularly on the intersection of not null and value. Alternatively if they introduce tearable semantics it will also shine - it would be possible to still optimize array of value classes, even if they are nullable (for example by having correspondent nullability mask).
So they are taking right step in a right direction. They are just trying to land this incrementally.
It seems to me that the "and a null flag" is adding a tremendous amount of unneeded complexity. Supporting null seems to be about avoiding C#'s ref/in/out solution. I suppose that, from a JDK dev's perspective, that's a reasonable requirement. I just hope that we actually get non-null.
I'm not sure the no-tearing rule is particular helpful either. Like, this is something folks get wrong all the time in regular java. There's plenty of places where we use unsynchronized classes and expect synchronization to occur in the containing class or other explicit lock. If atomic operations are a requirement, and non-atomic value types get turned into references, then value types seem pointless.
I fear we're getting something called "Value types" with none of the actual benefits of value types. Like "we heard you want something called value types so here you are". No, we wanted a way to declare arrays of structured values without having to deref pointers, or to store structures inline as a field within an object. What I've read seems to be not that unless the structure's total size is 63 bits...
Yup. That's a big disappointment they could not cram universal generics faster. But I get the problem - they have to preserve backwards compatibility. I can take 30 y.o. Java 1.0 JAR and run it on Java 27 and it will work.
> There’s a catch worth knowing about here, though: flattened data has to be readable and writable atomically (otherwise it risks “tearing” under concurrent access).
I really hope they give an escape hatch for this. It will make it really hard to extract a lot of the benefit of valhala if you can't make a thread unsafe value class. It's also one of those problems that will be quite hard to run into. You basically need something like this
Not something you typically run into and generally already a thread safety problem.The solution is also simple, a `synchronized{}` block will fix it if you need to have a tearable class that's written from multiple threads.
But the other thing is that for SIMD operations, you really need flattening, and that really does typically mean having something like `Foo(double x, double y, double z)` in play. It'd be a shame if the way we have to do this is a struct of arrays.
I actually don't understand the tearing they're talking about. If the fields are final then you can't modify the Value Type anyway? And a simple write-lock bit for fat Value Types would solve everything while maintaining most of the performance benefits (both on read and write)
The problem is concurrent access. A write bit on the value doesn't really help as you have to check and update the bit using atomic instructions. But you'd also need to reserve that bit for every read as concurrent access wouldn't be safe.
That's the tearing problem.
It gets worse because things you can't generally do in the JVM can happen. For example, if your value class contains a reference to an object but that reference just so happens to split a tear, it's possible one thread to see an invalid reference while another thread is writing that object. That could be fixed with some added padding based on the architecture to make sure stored references aren't tearable.
References can't tear in Java, per the specification (long and double could actually, the spec only talks about references and 32-bit slots being tear-free - though actually almost all implementations have them atomic as it's practically free on 64-bit CPUs). That would basically make the platform memory unsafe so I'm fairly sure they would make sure references are always written atomically.
But tearing may still cause a logical issue of course. (Think of a date class where the day may still be 31 but the month was set to Feb on another thread).
Interestingly Go is memory unsafe on this issue, slices can tear and later code can read into an incorrect offset from the pointer. Java abstracts away pointers, so this issue is non-existant there.
> I actually don't understand the tearing they're talking about. If the fields are final then you can't modify the Value Type anyway?
You can assign the object again to overwrite it 'in place'.
> And a simple write-lock bit for fat Value Types would solve everything while maintaining most of the performance benefits (both on read and write)
They even already have an extra 'null' bit tacked on to the value object.
Tons of armchair critics but dang this is freaking cool!!! Thanks everyone for working on this an THANK YOU for moving slow and getting the design right!
I'll be interested in seeing the fallout of the (unavoidable) compat issue:
If I have a function that has a value `x` that erases to `java.lang.Object` (e.g. a parametric function with no lower bound); then it used to be safe to check for nullity and then synchronize on the object.
This is no longer safe: This can now throw `IdentityException` into your face. (it was _never_ a good idea)
In other words, a lot of old code must be reviewed.
I suspect that `-XX:DiagnoseSyncOnValueBasedClasses=2` will need to stay (with the semantics: if user tries to synchronize on identity-less object, then log a JFR event and make it a NOP, don't throw an exception)!
The current JEP text is a little too ambiguous to figure out whether that is the plan, anyways.
You lost me at "I have a function that has a value `x`". How does function "have" a value?
I think they meant function that takes a value x as an argument.
I understand the rationale for value classes, but the implementation is flawed.
What will this code print:
Until now the answer was obvious. Now with the addition of value classes, the answer depends on whether Point is a value class or a reference class. So readability suffers with this design.This is a violation of the principle of uniformity. In The Psychology of Computer Programming, Weinberg explains that uniformity is a psychological principle which says that users/programmers expect that things that look similar should do similar things, and conversely that things that look different should do different things.
If a programming language lets two constructs look nearly identical at the use site while having meaningfully different semantics, it increases the cognitive burden on the reader. Programmers must inspect the type declaration or rely on tooling to understand whether assignment, equality, identity, and mutation behave like ordinary reference objects or like values. That can make code harder to reason about and maintain.
This could have been fixed by requiring the use of the "value" keyword not just at declaration time but also at use time like this:
I believe that the statement `a.x = 100;` is invalid since Record types are immutable.
That is, the situation you are afraid of should be impossible.
If that's true then it is a significant improvement over structs in C#.
But the distinction still matters. Value-vs-reference semantics affect equality, identity, nullability, arrays, collections, boxing, and performance.
So this is not just an implementation detail. If a language hides that distinction at the use site, it increases the burden on the reader and makes code harder to reason about.
C# has Properties that make setters look like fields anyway. There's no ambiguity between value and object in C# because there is no promise that that syntax only sets a field. Love it or hate it, you just need to know what you're calling.
[dead]
based on the goals from JEP 401 [1], this is not possible, as value classes are meant to "Allow developers to opt in to a programming model for immutable data(...)"
[1]: https://openjdk.org/jeps/401
From my read of the article line 3 is a syntax error. All fields in value types are final.
No, there’s no way to know from those four lines that will happen, but we have that problem today. If Point was a record the same thing would happen.
Eh, still kinda murky. How about
Now it's much more obvious that cloning/copying takes place, and mutating a field won't affect fields of any other objects.How are people still defending type erasure? Sure, it was “defensible” in the sense that there were reasons the choice was made. But it was clearly a bad choice (to many people at least) when it was made and the effects are still rippling through the ecosystem. With the benefit of hindsight, it’s even more clear that the naysayers were correct and the harm to the Java ecosystem from type erasure is worse than the harm from creating parallel libraries would have been.
If sane generics had been introduced, the non-generic collection types would be a historical oddity by now and we wouldn’t be talking about how a future enhancement is going to undo the erasure decision.
> How is this different from struct in C#? A struct in C# has identity
Since when? I’m pretty sure structs didn’t have identity last time I used C#, and that would be a very surprising thing to add.
I have such an urge to comment "lgtm" on the 197k line change PR
Do it
From the article:
> In 1995, a memory access cost roughly the same as a CPU operation
Uhm... no?!
Here's a CS paper from 1993(!) about prefetching from cache(!!) because the cache was slower than the ALU. https://www.eecs.umich.edu/techreports/cse/93/CSE-TR-152-93....
It would perhaps make Java look a little bad to say that, in 1995, the prevailing attitude in certain circles was "If it's too slow, just wait for faster hardware - Moore's Law forever baby!" (Of course, Sun was selling, at the time, relatively fast hardware - the slower the software, the faster the required hardware)
Yeah, when I read that, I thought "this guy was either born wayyy after 1995, or he doesn't know the first thing about computer hardware history, or both". 1995 was the year the Pentium Pro was launched, which was (one of?) the first CPU(s) to integrate the L2 (!) cache into the same package as the CPU - they were still separate chips, but the interconnection could be made faster by putting them into the same package.
Yeah, 1995 is much too late. I'd say somewhere about 1990. Maybe you can go as early as the i386 and 68030 in the late 1980s but I'd be hesitant to include them.
Yes, this also stood out to me. I usually think of CPUs and memory having parity in the early 80s, but I never bothered to check for sure. I do remember some early computer architects writing about memory being faster than the CPU!
Well, yes but no:
The Z80 took 3 cycles to load from memory. A register to register transfer took 4 cycles (including fetching the instruction). Only one of those cycles was instruction execution.
I think the only reasonably mainstream scenario where the CPU would be significantly slower than memory would be the serial CPU designs such as the PDP-8/s.
That said, at the time people were doing cool stuff with 8-bit CPUs, they weren't running software remotely like what we're discussing here. That would have been done on a VAX, which had instruction and data caches.
What really happened, that the article is alluding to is that memory didn't get much faster in absolute terms since the 1980s. CPUs on the other hand did.
E.g. in the 1980s we had 60ns DRAM. Today DDR5 I believe allows about 10ns random access reads best case (6X). Over the same period CPU clock speeds have increased from about 8MHz to 5GHz (600X).
Early 80s is also what I remember, mainly from articles about old CPUs on HN - like the zero page on the 6502 that served as a sort of L2 register file.
I think this is quite similar to julia's handling of a struct. An array of mutable structs is just an array of pointers, where every pointer directs to the underlying structure. However with an array of structs (immutable is the default), there is no such indirection. The value of all fields are stored as array element (unless you have an array of heterogeneous elements).
If you want to change an element of such an array you need to create a new immutable struct which in practice it is quite fast, but a bit verbose to write.
It's still too unpredictable trying to be transparent IMHO.
Scalarization can fail in surprising ways just due to what a maximal atomic write can be on the target platform, and then it fall back to heap allocated objects.
Even if there's type erasure.
I much rather have the compiler balk at me than let me write something that may or may not work as expected.
I think a lot of people will file this under Java got structs.
That seems off. They're still objects, the new thing is that they can give up identity.
This beaurcratic development feels like turning a super-tanker that's connected to a hundred other super-tankers. While I accept the priority of back-compatibility, I personally lack the working memory to manage it, while creative problem-solving.
I love a long form programming deep dive. I have questions, probably basic ones that belong in undergrad CS but it’s been … a while.
1. Can someone remind me why it was so important/intentional at the start of the language that every object has identity? 2. Why is it important that we not synchronize on these value objects?
What I have in mind when I read Valhalla : https://valhalla.openstreetmap.de/
Great write-up. Java is getting so good. The improvements over the last decade have been unbelievable. The negativity here is bizarre. Just a reflex I suppose.
And I notice, people aren't aware more things are being planned for. For example, the carrier classes being proposed, they will separate state description with state representation and this is where value classes will shine syntactically.
[dead]
I found a solution for what seems to be the same problem, in a different language: a particular type of lists, where the class metadata is stored once and the data for each instance is contiguously stored in a flat array.
Not sure if it covers exactly the same terrain, but perusing the article, it seems to be the case, with a single instance being the degenerate case.
Yup, it's the same terrain.
I've made something like this in the past. And I did it exactly because `List<Foo>` was too expensive and slow.
Am I understanding this correctly: a value type really only works when it fits on a 64 bit "cache line", and when larger, it falls back to normal heap allocated objects as before? Seems extremely limiting, no? Great for a boxing optimization, but not much else unless you're deal with very small data types regularly...
That's true for arrays of these value classes. Scalarization would help for larger local values though, since those would avoid pointer indirection for purely local values.
Larger types are supported, there is A notion of tearing. According to JVM spec even long and double could tear, not sure about practical implications though
Surely it can't be that, it destroys basically the entire value proposition of value types, unless you use a preprocessor to write everything as SOA.
And one bit for null! So “smaller data types” means 32bits! Yay! It’s 1995 again!
stopped reading when i saw the AI illustration. wholly unnecessary, and it feels insulting to be fed slop like this...
if you really want a fun drawing get a human artist to do it. it doesn't need to be complicated, for example https://www.code-cartoons.com/ is mostly just stick figures and does an excellent job
but you don't even need any of that, a mermaid diagram would have worked perfectly fine too. instead you chose to use a technology that is known to be harmful
Thank you, no idea how this stuff gets upvoted here. The whole article reads like something Claude came up with.
I simply do not trust articles that use slop imagery like this. I assume the text of this article (and realistically, most articles posted here) is also slop, but it's often difficult to tell.
If you don't have the time or put in the effort to make your article, I'm not going to spend time and effort reading it. You really don't need some generic cartoon guy hovering over your graphs, draw them in MS paint or something.
> The difference in the code is exactly one word: value.
What is unclear to me is why the decision to use a Point instance as a value or as a reference is made in the class definition rather than by the caller.
> Point[] point = new Point[10];
For the same class, I might need an array of values in one place and an array of references elsewhere within the same codebase.
It would really break the GC or the type system if you did that. If you return a single point out of a 100k long array, it has to pin the array? How do you track the GC root? Struct array elements need back pointers?
Conversely, if it auto-copies now you have to contend with runtime state changing the pass semantics?
What about the case of just needing one, not a collection? And when a function receives a Point, how does it know if it's a value or a reference?
Looking into the negative comments is quite amusing. Not only do most of them contain technical inaccuracies, but of course, they also need to mention how great .NET supposedly has been from the beginning and how Java supposedly copied everything.
Let's take a stroll down memory lane. First of all, .NET literally started as a Java copy. On top of it, a non-cross-platform one for almost two decades! After having shamed Linux for so long Microsoft finally started porting .NET to other platforms in a non-backward compatible way. A lot of .NET proponents will tell you porting from legacy .NET to .NET Core (which was renamed once again to .NET) would be a quick fix, but it isn't. For example, the shop I used to work in had some important cryptographic libraries which were very painful to port. And then, there's .NET's simplistic garbage collector, which can be quite annoying because it tries to be a one-fit-all solution that basically cannot be tweaked at all, often resulting in unresolvable latency problems. There’s a lot of other stuff, like its ghetto-like ecosystem and the insane fragmentation of GUI libraries.
I also don't get the C# praise. Over the years, it has become quite the bloated language. It feels like Microsoft tries to implement every feature possible without realizing that an enterprise language is supposed to be streamlined. Async/await? Very ugly, very annoying. Java has solved this a lot better with virtual threads and structured concurrency.
I could go on, but these "language wars" are silly and pointless. Both platforms have their pros and cons. Besides, I have a lot of bad things to say about the JVM as well, but it's nice to see Valhalla finally beocming reality. Too late for me personally though.
I like how you point out inaccuracies and next paragraph you deliver couple more, finishing with “language wars are silly and pointless”.
> inaccuracies
Like what?
> It was always .NET
No, it was not. What's called .NET now used to be .NET Core. And then there's .NET Framework which was commonly known as .NET.
> "cannot be tweaked at all"
Are you serious? Not only does the JDK have multiple GCs for different use cases (Serial, Parallel, G1, ZGC, Shenandoah), they have very refined tuning settings (https://wiki.openjdk.org/spaces/zgc/pages/34668579/Main#Main... / https://docs.oracle.com/en/java/javase/25/gctuning/garbage-f...). What does .NET let you do with the GC? Set the hard limit? Maybe turn on/off concurrent collection? That's not tuning, that's triviality.
You just confirmed your ignorance about anything .NET related.
Coming from someone claiming:
You are just so much in language wars I am just definitely ending the conversation.I keep telling you what's what and you do nothing but gaslight me by trying to turn my words on me.
Language wars are silly and pointless. Someone tells me he/she uses language xyz, I basically don't care, do whatever works for you ,but God forbid you cross a .NET proponent. In case you haven't noticed, this is a post about Java. You mention Java, and the first thing that happens is a bunch of .NET maniacs popping up out of nowhere, telling you how Java copied this feature or how C# had that feature for years. What is this?
> The pull request alone adds over 197 thousand lines of code across 1,816 files.
And that across 2819 commits.
Wow, that’s insane.
I just got my projects up to JDK 21 a few months ago. Working on trying to get one upgraded to JDK 25 now and now they're talking about delivering JDK 28 in less than a year from now. How are you supposed to keep up with these rapid updates?
JDK 21 is a few years old now, so you were a few years behind. JDK 25 was released last year, which makes for the next stable LTS for a while. JDK 28 is expected in 2028, and these features are not going to be enabled by default for years after that.
Java is generally backwards compatible, so unless you're using fat frameworks that use shady internals or known-deprecated APIs, you should generally be fine immediately upgrading to the latest LTS, possibly even non-LTS versions if you have confidence in your stack.
What did you go from to get to 21?
Mostly just hit the LTSes is what we've been doing and since about 17 it's been a pretty easy process in general.
Protip: If you ditch lombok everything gets a lot easier.
How much stuff actually broke? I feel like you can treat Java upgrades as minor upgrades most of the time, maybe you have to rebuild a few binaries but I'd be shocked if it required significant code changes.
The article has a section about that. For me, a struct in C/C# can be modified and is passed by copy while a value class can not be modified and is passed by value.
I do not think you can do stack allocation in Java.
Yup. By design, value classes will use cpu registers as a 1st priority instead.
That smells a lot like Facebook making a php compiler
Does it FINALLY fix the "-Xmx" nonsense? Or do I still have to statically specify the max heap size, as if I'm still using MacOS 9?
Most people use percentages now for containers.
But they are working on removing that: https://openjdk.org/jeps/8377305Ha, just walked down a street called Valhalla in Stockholm — felt appropriate timing to read this.
I'm a little unclear as to when and under what conditions this results in non-heap objects, now (<= 64-bits?) and in the future (???). I thought that was the _ENTIRE_ point of this project, so I was surprised to see they can be null (did that change from before?). If it is always and forever limited to 64-bits, I fail to see the point of this entire project, as it would have been far simpler to add syntactic sugar (simply pass primitives underneath the covers) as Scala did to create value types vs. JVM changes.
(Yes, not yet, but...) As a Scala afficionado, "free"/freer runtime performance is very welcome :)
Fun read.
Why remove identity from Double and Integer? This is going to break so much stuff for no reason when double and int were already a thing.
I'm wondering what this means for Kotlin now
Dupe? https://news.ycombinator.com/item?id=48590056
a few questions for the pros
> "The defining trait: no identity"
I get that this makes objects behave like primitive types. Maybe thats reason enough. But is it necessary for the performance boost and de-fluffing the objects? Seems like an orthogonal objective
> There’s a catch worth knowing about here, though: flattened data has to be readable and writable atomically (otherwise it risks “tearing” under concurrent access).
Isn't this a race condition and "undefined bahvior"..? Having to limit yourself to atomic sizes seems like a huge limitation, to accomodate what is most likely buggy code. Is all the effort only gunna help lil toy ColorRGB examples?
> The points array is a million pointers. Each pointer leads to a separate Point object lying somewhere on the heap.
Does this happen in actuality? One would assume the allocator tries to put stuff sequentially on the heap? Its not a guarantee as with these Value Types, but I'd think you could get similar-ish perf with prefetching in cache. I dunno whats happening under the hood.. But when writing Clojure apps the JVM always reserves absurd amounts of heapspace on my machine (to my annoyance). Id assume it can find some place to do contiguous allocations..
Which i guess gets me to my last question... where are the benchmarks broski? It all sounds great, but does it actually yield the insane speedups promised?
Great article, well written. But a benchmark would have been a nice "punchline"
> is it necessary for the performance boost and de-fluffing the objects?
Yes. The one part of the JVM GC that can't run concurrently is heap compaction; objects that can be moved by copying and then deleting would be a huge help for that. And it would be awkward to say the object has an identity but can't be wait/notify'd, at which point you need somewhere for the monitor to go.
> Does this happen in actuality? One would assume the allocator tries to put stuff sequentially on the heap?
Yes. Of course it tries, but semantically the pointers are just pointers and the prefetcher can guess but the system still has to chase them.
> I get that this makes objects behave like primitive types. Maybe thats reason enough. But is it necessary for the performance boost and de-fluffing the objects? Seems like an orthogonal objective
It feels like an orthogonal objective and honestly arbitrary distinction, yes.
> Isn't this a race condition and "undefined bahvior"..? Having to limit yourself to atomic sizes seems like a huge limitation, to accomodate what is most likely buggy code.
I think they meant it like the appearance of atomic behavior from a java multithreading view.
> Does this happen in actuality?
Yes, it does happen. Having guarantees on this front leads to better performance.
> But when writing Clojure apps the JVM always reserves absurd amounts of heapspace on my machine (to my annoyance)
Might be a configuration problem?
> Is all the effort only gunna help lil toy ColorRGB examples
Arguably flattening mostly makes sense for these only.
And yeah, you are right that allocations happen on something called a thread local allocation buffer, which is basically just a pointer bump in cost and objects allocated one after the other should be physically close in memory for the most part (though an object's creation may require a bunch of other object's creation that would sit in-between). But these have headers, so not as dense as they could be (though due to GCs being generational, they may end up actually closer in the next gen? The in-between temporary objects wouldn't survive for the most part)
There are plenty of cases where flattening an object that takes 64bits would make sense.
The current code will help with `Integer[]`, `Char []`, etc, as well as combinations of `byte`, `char`, and `int`. Past that it doesn't really help much.
It would be fantastic if we could also flatten something like `Pair` or `Tuple`. However, even with compressed pointers, that is 64 bits, so that, plus the `null` bit, means it can't be flattened, which is a real shame. For various reasons, I have `List<Long>` in numerous places in my code, It would be great if that could also be flattened. However, since a Long is 64 bits, it _also_ can't be flattened. https://openjdk.org/jeps/8316779 would go a long way to to helping here, since then at least the null bit could be thrown away, which would allow more things to be flattened.
And then, if you want to go Wishlist land, something that would allow SSO (Small String Optimisation) would also be awesome, but that would require something akin to unions in Java, which we can _kind_ of do with sealed classes, but, since String is a final class, can't be retrofitted back into the language.
Does anyone know if Valhalla will flatten "simple" sealed classes, where every sealed class is small enough to be flattened? Since that would also be a powerful example to share.
Is there some reason there isn't simply a write-lock/semaphore on Value Types that are over 64bits? The overhead should beat pointer-chasing. I mean maybe someone wants to concurrently write to values from different threads with no coordination, but that's not super common. As you illustrate, having "fat" Value Types would open up a lot of potential.
In the current setup will a Pair Value Type be a compiler error, or will it silently just have bad perf?
Anyone know why the article's 4th picture is about the Jobs obituary gaffe? (It's not just for me, right?)
It's because the author is comparing that incident to how they were prepared with the bulk of their analysis in advance. Ready to publish as soon as it happened.
And here I thought engineers were mostly logical and objective. This thread is very entertaining.
So, is this going to allow an F# like language to run on the JVM?
We’ve had Scala for years.
“plus a null flag” is going to be the GIL of the JVM.
modern Java is great. But this article makes me really appreciate the class and struct features of C++
wow, basic stuff c++ had since the 80s. congrats. clap, clap, clap. now can someone please make this app that is running with -Xmx360m not use 700mb of resident memory ? asking for a friend.
What a dumb comment. It's almost like a low-level language having a different feature set is expected.
Also, there is no exact analogue, C++ is just wholly different where you can specify copy/move/destruct semantics on a gradual basis.
This time, 30mb.
try reducing the heap size as it seems that's what's eating half of those 700mb
It's slop o'clock
[dead]
[dead]
[dead]
[flagged]
The gap between demo and production is always bigger than it looks. Things that work great on the examples in the README tend to fall apart on edge cases that aren't covered. Worth running it against your actual data before committing to it.
Java = Oracle = Ellisons way of doing business
Unless your company forces you to use Java for new projects, consider a change
name another statically typed, compiled, mature language with a bunch of packages for everything and maybe I will /srs
The one that immediately springs to mind is C#. Of all the mainstream languages it is probably the one most similar to Java. It can be compiled into platform-independent bytecode (like Java) or into native code using Native AOT. Relevant to the subject of this article, it has had support for structs (user-defined value types) since C# 1.0 in 2002.
Rust
[dead]
> Before we pop the champagne, though: this is preview, disabled by default, and, as Brian Goetz was quick to cool everyone down, “only the first part of Valhalla.” Goetz added a great observation that the “they’ll never ship it” crowd will now smoothly switch over to “but they didn’t ship the most important part” (and a joke has been going around the community for years that we’ll sooner end up in Valhalla ourselves, the Norse-afterlife one, than the project ships).
I don’t know if this is fair way to try to disarm your critics. The only thing that’s remained after this decade is the slogan so it’s a real ship of Theseus question if Valhalla has shipped since what’s delivered doesn’t achieve it. Congrats on the accomplishment, but from looking at what ended up, I’m not sure it’s a huge improvement.
> The trouble is that this optimization is unpredictable and fragile.
Is this describing escape analysis or value classes? Because the list of exclusions where this does anything is so large and the conversion to a heap type under the hood is so transparent and opaque, I think it can describe this technique as well.
Also, the whole “works like an int” motto is violated - int is never null, int-> integer boxing is explicit and well understood.
> In the new model, the wrapper classes themselves become value classes (when preview is on, Integer, Long, Double, and company lose their identity
Oh neat, they sidestep that by changing the definition of an int. I’m sure it’ll be trivial to turn this on in the wild on code that may be relying on identity for boxed numerics. I think this alone shows this project can’t ever be turned on by default and now we’ll have a decade of two Java languages (one with value types and one without) as they try to convince everyone to migrate and then just turn it on (ie python3).
So much opportunity squandered and dismissing critics as always having something to complain about is a neat way to sidestep legitimate criticism that this approach is not going to work out for Java.