
The Road to Valhalla - efge
http://cr.openjdk.java.net/~briangoetz/valhalla/sov/01-background.html
======
ljackman
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 points?

But Java's recent and upcoming additions show _taste_: adopting a single
lambda notation that fitted smoothly with the surrounding class-based OOP
paradigm via SAM types (rather than magically-generated-type-style lambdas
succeeding two overlapping "delegate"/"event"-like features); implementing
(sadly somewhat-incompatible) modules that can curtail unbounded reflection,
opening the door to greater reasonability and performance in the future;
proposing Project Loom to avoid the async/sync API split that hit Python, C#,
and even Kotlin Coroutines; and now Valhalla, which was quietly mulled on for
years before arriving at this very reasonable solution that considers myriad
angles.

I like this approach to language design and think it bodes well for the
language's future. It's a sweet spot between being necessarily conservative,
dealing with developers' real-world problems, and giving time to mull over new
language feature designs and not just implementing as soon (and haphazardly)
as possible to please vocal developers.

~~~
billfruit
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++.

~~~
ljackman
There might be, but unfortunately I don't know it. I learnt Java initially
from the first edition of Just Java, read from various other sources about the
1.5 and 1.6 additions it didn't cover, and then learned new features from
OpenJDK proposals from 1.7 onwards as they were released.

The biggest impact of the 5 years for working developers has probably been:

* Streaming API and lambdas allowing usual `map`/`filter`/`reduce` transformation pipelines line many other languages (lazy, unlike JS's `Array` methods, parallelism considered via "spliterators" unlike Python).

* Default methods in interfaces, _not_ making them traits, but arguably more "trait-like". It allowed them to add many useful methods onto existing types without needing bifurcate the common APIs.

* A REPL. Probably not a big deal for a professional developer, who likely uses IntelliJ's "Evaluate Expression" feature already for a similar feature, but pretty useful for education I guess.

* Better at being stuffed inside Docker containers with resource limits. Also, max permgen space no longer a problem really (it's where you had to set an upper memory limit when invoking Java programs, which was annoying). Just generally less annoying at being deployed in modern infrasructures.

* APIs like `File.lines` that mean you don't need to recite War and Peace just to do a buffered operation across lines in a file. Generally more ergonomic APIs that finally make basic operations sane.

* Type inference with `var`. Basically the same as C#'s `var` or Go's `:=`.

* More native executable-producing tooling. jlink, jpackager, etc. The dream of ubiquitous, shared Java runtimes installed everywhere didn't really work out, and they seem to have realised that.

* Ecosystem moving away from XML. Still there, just less common. Runtime annotations are used more heavily, which I'm honestly not sure is a massive improvement. Hopefully more lambda-heavy APIs will reduce use of runtime annotations; see Spring WebFlux's functional handlers for annotation-based controllers for a comparison.

There's a lot more, but I'd argue it won't be as immediately visible for the
working developer more than those points. Modules were important for the
ecosystem, but most devs probably aren't worrying about that day-to-day.
Gradle and Maven still dominate the building/packaging side.

~~~
billfruit
Very informative summary, thank you.

------
efge
Make sure to read the second part, Language Model
([http://cr.openjdk.java.net/~briangoetz/valhalla/sov/02-objec...](http://cr.openjdk.java.net/~briangoetz/valhalla/sov/02-object-
model.html)).

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

~~~
mongol
I wonder why that name was chosen.

~~~
smarks
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".

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

------
raiflip
Tangentially related questions to generics, anyone think java will ever get
higher kinded types? It would be super useful to have a better way of
expressing higher level abstractions.

~~~
adimitrov
Java will not get HKTs in yours and my lifetime. What _might_ get HKTs is
Kotlin. There's a proposal brought forward by the Arrow people that has
attracted a lot of attention.

[https://github.com/Kotlin/KEEP/pull/87](https://github.com/Kotlin/KEEP/pull/87)

If if that does not succeed, the Arrow folks are working on a meta compiler
(think template Haskell but with IDE support) that should get you HKTs and
union types.

[https://github.com/arrow-kt/arrow-meta](https://github.com/arrow-kt/arrow-
meta)

Regardless, something quite close to HKTs is available today via type level
defunctionalisation. Just look at the Arrow docs

~~~
raiflip
Yeah Arrow is pretty great. There's a similar work around for HKT in java:
[https://github.com/highj/highj](https://github.com/highj/highj).

I would much rather some native syntax like K<T> where K is some generic
though.

------
akkartik
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.

~~~
cobbzilla
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).

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

~~~
cobbzilla
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.

------
he0001
> With the multi-level memory caches and instruction-level parallelism of
> today’s CPUs, a single cache miss may cost as much as 1000 arithmetic issue
> slots – a huge increase in relative cost.

Does this mean that the value of these additions are partially diminished
because of spectre and meltdown vulnerability fixes?

~~~
nl
No.

This is nothing to do with specular execution.

------
ddtaylor
This could have been submitted as an HTTPS link.

------
admax88q
While undoubtedly useful, I feel like this will further the divide in
programming models when dealing with primitive types vs objects in java.

~~~
kasperni
I think it might actually end up the other way around. For example, primitives
are going to be able to have methods now. In the end, the numbers just aren't
there for certain types of computations without them. And people have been
complaining about them missing for years.

~~~
JonathonW
Also generic specialization-- which will allow generics over primitive types
(and value types). That'd eliminate one major source of pain for performance-
sensitive code (no more writing your own collection classes if you need to,
for example, contain a bunch of ints).

~~~
kasperni
Yes that too, good point.

------
loudlambda
Horrible headline. Was relieved this wasn't about following the footsteps of
the supposed New Zealand shooter.

~~~
paulddraper
java.net doesn't usually have articles about such things.

