Live data from Hacker News

The Road to Valhalla

cr.openjdk.java.net

21–30 of 82 posts

Re: The Road to Valhalla

#21

I wonder if they plan to support nested inline types, such as arrays inside objects, or arrays in arrays. Every time I try to design a layout something like that I end up having to compute values to initialize various offsets with. Arrays may have a length prefix, or objects may need some metadata in the header. Tagged unions may need to initialize tags.

Reading the doc, I believe this is supported with these restrictions: (1) value classes may only contain other value classes, and (2) value classes cannot contain instances of themselves (no circularity).

Your first point is incorrect, inline classes can have fields that are regular reference types.

Re: The Road to Valhalla

#22
post #8
post #3

FYI: Valhalla is the project code name for adding inline types (value types) and generic specialization to the Java language/platform.

I wonder why that name was chosen.

The initial concept was "value types" and we wanted a project name that was evocative of "value". Place names (even for mythical places) are good names since they cannot be trademarked. Hence, "value" => "val" => "Valhalla".

Re: The Road to Valhalla

#23
post #21

Earlier quoted context omitted.

Reading the doc, I believe this is supported with these restrictions: (1) value classes may only contain other value classes, and (2) value classes cannot contain instances of themselves (no circularity).

Your first point is incorrect, inline classes can have fields that are regular reference types.

Interesting; I must have “over-read” the restriction. You are correct.

Re-reading the doc, the restriction is that all fields of a value type must be final, because value objects do not have identity.

Re: The Road to Valhalla

#24
post #22
post #8

Earlier quoted context omitted.

I wonder why that name was chosen.

The initial concept was "value types" and we wanted a project name that was evocative of "value". Place names (even for mythical places) are good names since they cannot be trademarked. Hence, "value" => "val" => "Valhalla".

That was the type of interesting explanation I was wondering about. Thank you!

Re: The Road to Valhalla

#25

While Java's slow and cautious evolution frustrates developers, it still arguably demonstrates longer-term thinking than the constant accrual of features in its contemporaries such as JavaScript and C#. That isn't to say the designers of JavaScript and C# don't think carefully about the addition of new features; indeed, was it Anders Heljsberg who made the point about all new proposed features starting with negative…

I would agree with this if C# didn't definitively show you can have a successful enterprise/"LTS" language that doesn't move at a glacial pace and spend several years doing little to nothing (pre Java 8) It's implemented features Java had just gotten much earlier, in much more useful forms (see: generics, lambdas) without them being "haphazard" about it. - To me tasteful is what C# did, breaking changes when needed,…

I won't argue over particular features because clearly it's a matter of personal preference and, working on OpenJDK, I'm biased, but a couple of points:

Since Java was introduced in 1995 until today, Microsoft's software framework has had about three or four drastic backward-incompatible "generations", depending how you count. Most Java code written in 1995 will run, with little or no change, on the current JDK 13, and would compile on JDK 13 with only minor changes.

Leaving aside the JDK 7 years (2006-2011) when Sun was struggling and then going through an acquisition, the rate of innovation on the Java platform is quite high. It's just that we emphasize other parts of the platform more than the Java language because that's where Java has always believed most of the value is. In the past five years Java has seen an exceptional new low-overhead, extendable profiling capability (JFR), groundbreaking new GCs (ZGC), and what is probably the biggest breakthrough in compilation technology of the past decade (Graal). Those are all huge developments, none of them affecting the frontend language in any way. An innovative, state-of-the-art runtime programmed with an intentionally conservative language has been Java's strategy from the beginning -- James Gosling called it a wolf in sheep's clothing (https://youtu.be/Dq2WQuWVrgQ) -- and it has worked quite well. One could argue that that's the only way to sell a wolf to such an industry. Indeed, despite some grumblings on HN, it seems like most software developers prefer it this way.

Re: The Road to Valhalla

#26
post #15

While Java's slow and cautious evolution frustrates developers, it still arguably demonstrates longer-term thinking than the constant accrual of features in its contemporaries such as JavaScript and C#. That isn't to say the designers of JavaScript and C# don't think carefully about the addition of new features; indeed, was it Anders Heljsberg who made the point about all new proposed features starting with negative…

The .NET CLR (VM) has had proper generics and value types since 2002. Java did not implement generics until 2004 and to this day does not have user-defined value types. There was an opportunity to do it right in 2004 before this became "baked in". There is really no good excuse. Many developers have abandoned java due to the glacial progress with both the language and the VM. It is legacy now. The main benefit (IMO)…

Well, some companies still write many of their new projects in the Java language (not to mention use the Java platform), like Apple, Amazon, Alibaba, Google, Netflix, and, of course, banks, governments, airports, militaries, hospitals, utility companies, factories, robotic warehouses [1], and most Fortune 500 companies.

[1]: https://www.infoq.com/presentations/java-robot-swarms/

Re: The Road to Valhalla

#28

While Java's slow and cautious evolution frustrates developers, it still arguably demonstrates longer-term thinking than the constant accrual of features in its contemporaries such as JavaScript and C#. That isn't to say the designers of JavaScript and C# don't think carefully about the addition of new features; indeed, was it Anders Heljsberg who made the point about all new proposed features starting with negative…

While that is interesting to hear, is there a single book that brings someone who hasn't used Java in the last 5 years upto speed, like the book Bjarne Stroustroup's 'A tour of c++' does for c++.

Re: The Road to Valhalla

#29
post #25

Earlier quoted context omitted.

I would agree with this if C# didn't definitively show you can have a successful enterprise/"LTS" language that doesn't move at a glacial pace and spend several years doing little to nothing (pre Java 8) It's implemented features Java had just gotten much earlier, in much more useful forms (see: generics, lambdas) without them being "haphazard" about it. - To me tasteful is what C# did, breaking changes when needed,…

I won't argue over particular features because clearly it's a matter of personal preference and, working on OpenJDK, I'm biased, but a couple of points: Since Java was introduced in 1995 until today, Microsoft's software framework has had about three or four drastic backward-incompatible "generations", depending how you count. Most Java code written in 1995 will run, with little or no change, on the current JDK 13, a…

I have no love lost for Java the language, I find it cumbersome as hell to work in and as such all of my JVM work is done in Kotlin, but I appreciate having conservative and well-thought our evolution of platform features that ultimately effect all JVM languages; seeing as Java The Language is heavily tied into JVM semantics.

Quite frankly even with all the new features Microsoft has been putting into C# they’ve been prime to ignore the existing implementations in F#, leading to a clusterfuck of an ecosystem where I can’t use many C# libraries in my language of choice due to conflicts in implementation. I don’t have that on the JVM, I know I can use a Java library in Kotlin, Scala, Clojure, hell even Ceylon without huge headaches because they all share the same primitives.

Let other JVM languages incubate need language features, Java needs to be where they are eventually stabilized and standardized in how they work on the platform.

Re: The Road to Valhalla

#30
post #25

Earlier quoted context omitted.

I would agree with this if C# didn't definitively show you can have a successful enterprise/"LTS" language that doesn't move at a glacial pace and spend several years doing little to nothing (pre Java 8) It's implemented features Java had just gotten much earlier, in much more useful forms (see: generics, lambdas) without them being "haphazard" about it. - To me tasteful is what C# did, breaking changes when needed,…

I won't argue over particular features because clearly it's a matter of personal preference and, working on OpenJDK, I'm biased, but a couple of points: Since Java was introduced in 1995 until today, Microsoft's software framework has had about three or four drastic backward-incompatible "generations", depending how you count. Most Java code written in 1995 will run, with little or no change, on the current JDK 13, a…

>Since Java was introduced in 1995 until today, Microsoft's software framework has had about three or four drastic backward-incompatible "generations", depending how you count. Most Java code written in 1995 will run, with little or no change, on the current JDK 13, and would compile on JDK 13 with only minor changes.

That's exactly what's wrong with Java.

That's why we got "functional interfaces" instead of proper lambdas.

That's why we got half baked generics.

That's also exactly what I'm praising C# for.

They've paid that price 4 times, and every time they added so much value that it was easily worth it to their users.

Ask the average C# developer if they'd trade for Java's half baked lambdas and generics alone for none of those generations happening, and you'd get a resounding, no way in hell.

And C# stayed relevant in enterprise despite it, I've never seen an enterprise say "we're choosing Java because 4 times since 1995 they decided to add features so incredibly powerful language features and broke backwards compatibility.

The places that couldn't handle the changes needed are also the ones that would keep running an old runtime (and old JVM if they're using Java, because any upgrade = risk, backwards compat claims or not) as long as they want, security be damned.

.NET has an insane amount of "under the hood" innovation that has happened as well in all that time by the way, I'm speaking to the programming languages, not the runtimes and platforms that enable them. It's fairly straightforward to compare language features because they started in such similar places, comparing runtimes is a much less direct comparison.

Post reply on HN