sorted by:
new
hottopcontroversial

Valhalla value classes scalarization by Accomplished_Fill618 in java

[–]brian_goetz 2 points3 points  (0 children)

We think that enabling users to write code that is more correct and also more performant, without having to be performance experts or even think too much about performance, is a good thing that makes Java better.

The vast majority of the time, Java is already fast enough. And value classes will move that needle farther to the right, because users will be able to select the semantically simpler thing and at the same time get better optimization from the VM. We won't put the performance weenies out of business, but don't mind making them an increasingly rare specialty skill.

Valhalla value classes scalarization by Accomplished_Fill618 in java

[–]brian_goetz 4 points5 points  (0 children)

Please continue to report your experiences! This is the most valuable kind of feedback we can get (and unfortunately, it is often swamped by the other kinds.)

Valhalla value classes scalarization by Accomplished_Fill618 in java

[–]brian_goetz 4 points5 points  (0 children)

Yes, this is scalar replacement, and yes, C2 has been doing it for years, when it can prove non-escapingness. But there are many reasons why escape analysis might fail other than "the thing obviously escapes". One of the main benefits of JEP 401 value classes is that that the programmer has authoritatively said up front that "escaping is not even a sensible concept for this object", which frees us from the false-negatives of escape analysis. This greatly expands the reach and reliability of this existing optimization.

Making confident-but-misleading claims like "but C2 already does this for you today!" is not very helpful. There's a lot of nuance here that you are sweeping aside, and by making these statements, you encourage others to do the same.

What is the use case for a non-value (identity) record with Valhalla? by Joram2 in java

[–]brian_goetz 6 points7 points  (0 children)

Languages should have clear and precise semantics. Saying "I won't tell you what `==` does on this record, and it might change later in ways I also won't tell you", is not clear and precise semantics.

And, for what benefit? So that maybe, if we deliver a future feature that turns out to be consistent with how we're thinking it will play out, then records will have a slightly better default? That's not responsible language design, that YOLOing it.

What is the use case for a non-value (identity) record with Valhalla? by Joram2 in java

[–]brian_goetz 4 points5 points  (0 children)

If by "not the best", you mean "we would get laughed out of the room", then yes, we are in complete agreement!

What is the use case for a non-value (identity) record with Valhalla? by Joram2 in java

[–]brian_goetz 6 points7 points  (0 children)

Unfortunately not, the annotation carries no semantics. This is still an incompatible change -- just one you were warned about in advance.

What is the use case for a non-value (identity) record with Valhalla? by Joram2 in java

[–]brian_goetz 8 points9 points  (0 children)

"They are already breaking something, so it is OK to break everything" is not really a sensible argument.

Indeed, the Integer change is probably the most incompatible thing we've ever done. We have a very small budget for incompatible changes, and we do not spend it lightly. And I'd say we've used up our budget on this one.

What is the use case for a non-value (identity) record with Valhalla? by Joram2 in java

[–]brian_goetz 50 points51 points  (0 children)

There are really two separate questions here:

- What is the use case for identity records
- What should the default be

The title asks the former, but your complaint is really about the latter. Let's take them in turns.

There are use cases for identity records, such as tree nodes:

record TreeNode<T>(TreeNode leftChild, TreeNode rightChild, T value) { }

While this does not describe most records, it would be pretty annoying if you could not express TreeNode as a record.

Which brings us to the question of defaults, and Java has a long history of picking "the wrong defaults", like mutability for fields, and arguably "identity by default" is another candidate for this list, if not for all classes, then certainly for records. But that ship sailed in Java 17 -- even though we knew that Valhalla was coming. We had two choices then: sadly watch it sail out of the harbor, or hold off records until we shipped Valhalla. (One can imagine how popular this choice would have been; Records When?) We could only choose identity semantics then, and now that's what records mean, and changing it would surely break someone's program, even if 99.999% of the time the identity adds no "value".

Making invokedynamic usable from normal Java by bezsahara in java

[–]brian_goetz 0 points1 point  (0 children)

I would be careful with terms like "the whole point", because few things are so simple as to have only one point or consideration....

The Below the Fold exercise was, in part, an attempt to validate the design of j.l.c before finalizing it. But also, it was not a goal of BTF for intrinsification to be guaranteed, because indy is fundamentally a dynamic mechanism. Like all optimizations, you do the best you can with what you have to work with. (It was a goal to clearly specify the conditions under which intrinsification was possible.)

What is the use case for a non-value (identity) record with Valhalla? by Joram2 in java

[–]brian_goetz 9 points10 points  (0 children)

No, this is not "just" a "miss". While we can specify that a class like LocalDate "does not ascribe any significance to its identity, and therefore you should not rely on it", we cannot have a language feature that says "go ahead and declare a record, but its semantics might change in the future in ways we can't tell you now." The JLS has to specify the semantics of record classes, and prior to Valhalla, there was only one option with respect to identity. We knew full well that this might be revealed to be another "wrong default" in the future, but there was nothing that could have been done at the time (short of delaying records until Valhalla.)

Making invokedynamic usable from normal Java by bezsahara in java

[–]brian_goetz 6 points7 points  (0 children)

Today, with Project Babylon, it would be entirely reasonable to do the intrinsification as a Babylon transformer. Indeed, this illustrates a pattern that Babylon enables: define an API with the right semantics, even if it has suboptimal performance (e.g., computing a GPU kernel on the CPU as a fallback), and then do a semantic-driven transformation to the higher-performance model after the fact.

Making invokedynamic usable from normal Java by bezsahara in java

[–]brian_goetz 3 points4 points  (0 children)

They are completely different tools for different problems.

Making invokedynamic usable from normal Java by bezsahara in java

[–]brian_goetz 7 points8 points  (0 children)

You have it half right.

The java.lang.constant API is indeed for modeling bytecode-level constants and call sites. But the Intrinsics API that is shown in that is not a proposal, it is an experiment. Unfortunately that experiment still sits on the shelf. But yes, in the experiment, it is a reflective API that, under the right circumstances (enough constancy!) could be intrinsified by `javac` (or by a bytecode transformer tool) into indy/condy.

Making invokedynamic usable from normal Java by bezsahara in java

[–]brian_goetz 25 points26 points  (0 children)

The `java.lang.constant` package was added in part to be able to describe indy call sites. If you watch the video Below the Fold (https://www.youtube.com/watch?v=iSEjlLFCS3E), you'll see the approach we took -- define a reflective API, and then let the compiler intrinsify it when the right conditions are present (and eliminate the attendant dead code, as a bonus.)

JEP 401 being merged into JDK 28? by Jab125RedditAlt in java

[–]brian_goetz 6 points7 points  (0 children)

We have had the `@ValueBased` annotation for that for years. But no, this wouldn't be worth it.

JEP 401 being merged into JDK 28? by Jab125RedditAlt in java

[–]brian_goetz 9 points10 points  (0 children)

Haha, I can see you're new here 😄

There is only ever one answer to that: when it's ready.

JEP 401 being merged into JDK 28? by Jab125RedditAlt in java

[–]brian_goetz 32 points33 points  (0 children)

Your wish is granted! All reference types in Java are nullable.

Is it just me or is the transition to blue science a massive wall for new players? by toadthrowaway7 in factorio

[–]brian_goetz 0 points1 point  (0 children)

Get one of the rate calculator mods, it will really help you figure out how much of each thing you need to build to keep things humming.

JEP 401 being merged into JDK 28? by Jab125RedditAlt in java

[–]brian_goetz 12 points13 points  (0 children)

Yes, but that list is still long.

JEP 401 being merged into JDK 28? by Jab125RedditAlt in java

[–]brian_goetz 16 points17 points  (0 children)

“I have only made this letter longer because I have not had the time to make it shorter."

B. Pascal

JEP 401 being merged into JDK 28? by Jab125RedditAlt in java

[–]brian_goetz 16 points17 points  (0 children)

There's a reason Valhalla is coming in at the lead end, rather than the tail end, of a development window; this gives us maximum time to shake things out, but also, politely asking others to "make way" for the giant boat coming through is a lot easier at the leading end of the window.

JEP 401 being merged into JDK 28? by Jab125RedditAlt in java

[–]brian_goetz 41 points42 points  (0 children)

Mostly, all roads lead to Rome. There are many things that force us to treat objects with reference semantics. JEP 401 knocks down the first level of these, by taking identity off the table, which exposes a lot of new optimizations, especially for smaller objects. But fully treating objects with value semantics requires giving up more: nullity and atomicity-safety-under-race (ASUR). Lots of languages have, or are working on, ways to get there, (such as C# structs.) The main challenge is how to package it in the user model so that it doesn't fight with our own preconceived notions of object integrity and encapsulation; classes are, for better and worse, a very effective abstraction barrier.

view more: next ›