
Entering the next phase of Project Valhalla - arto
http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-October/000760.html
======
pas
A lot more details about carriers and L, and LW1:
[http://mail.openjdk.java.net/pipermail/valhalla-spec-
experts...](http://mail.openjdk.java.net/pipermail/valhalla-spec-
experts/2018-October/000762.html)

~~~
twic
_Background_

 _In MVT, there were separate carrier types (Q and L) for values and
references._

Oh right, well that clears that up.

~~~
pas
[https://wiki.openjdk.java.net/display/valhalla/Minimal+Value...](https://wiki.openjdk.java.net/display/valhalla/Minimal+Value+Types)

and

In value-capable modules, the class-file descriptor language is extended to
include Q-types, which directly denote unboxed value types. The descriptor
syntax is “QBinaryName;”, where BinaryName is the internal form of the VCC
name. (The internal form substitutes slashes for dots.) In fact, the class
name must be that of the value type derived from a value-capable class.

By comparison, a standard reference type descriptor is called an L-type. For a
value-capable class C, we may speak of both the Q-type and the L-type of C.
Note that usage of L-types is not correlated in any way with usage of Q-types.
For example, they can appear together in method types, in arbitrary mixtures.

See also the JVM bytecode standard, which has the following "things", that
explain the "L" part:

[https://stackoverflow.com/a/5086340](https://stackoverflow.com/a/5086340)

> [0] Logically speaking, we have two things we want to do, and that unfolds
> to a choice between three "worlds" of up to four distinct kinds: L/Q/U/R. L
> is always present because it is a legacy model for reference types. Q is
> always present because we know we need (at least sometimes) to make a
> syntactic distinction between flattened values and legacy objects.

> (Why not just always look inside the classfile? Because the verifier cannot
> be expected to load a class for every type it sees, so needs a descriptor
> kind character from time to time.)

[0] [http://mail.openjdk.java.net/pipermail/valhalla-spec-
observe...](http://mail.openjdk.java.net/pipermail/valhalla-spec-
observers/2017-November/000388.html)

------
_Codemonkeyism
Brian Goetz has been a role model on how to lead [0] a language for a long
time now for me. Thanks for all the great work Brian.

[0] "Brian Goetz - Stewardship: the Sobering Parts",
[https://www.youtube.com/watch?v=2y5Pv4yN0b0](https://www.youtube.com/watch?v=2y5Pv4yN0b0)

------
jrd79
Any estimate on which version of Java will get Value Types?

~~~
hossbeast
C#

~~~
Cristian_knur
Lol

------
simonh
We're going through the process of auditing and budgeting for the costs of all
our (previously free) Java licenses now.

Not interested in the slightest.

~~~
frant-hartm
Haters gonna hate.

Oracle made OpenJDK functionally equal to OracleJDK (including previously
commercial only java flight recorder and mission control), but people still
complain. At first I thought this was an issue in Oracle's communication
strategy, but I started to think this is ignorance on the receivers end.

~~~
simonh
OpenJDK only gets 6 months of security patches. Try again.

~~~
twic
I can understand you not being up to date on this, because the story has been
too murky for too long, but that's not the case. See:

[https://developers.redhat.com/blog/2018/09/24/the-future-
of-...](https://developers.redhat.com/blog/2018/09/24/the-future-of-java-and-
openjdk-updates-without-oracle-support/)

tl;dr: Oracle will maintain the latest release of the OpenJDK codebase. The
community (in practice, Red Hat) will backport security fixes from that to the
current LTS codebase. AdoptOpenJDK and others will release builds of the
current LTS codebase.

