Having Box-es (legacy java.lang.Integer), Lox-es (new lightweight value boxes) and Pox-es (primitive wrapper value classes) and primitives (int-s) would complicate the understanding...
I wish there would just be one (int) or maximum 2 (int.Box)...
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:
> [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.)
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.
Yup. We are switching to openjdk 11 from Oracle 8. We used none of the commercial features and really only used the Oracle jdk because it was easy to install.
If you want support, there area ton of other jdks for cheaper (like azul).
Oracle dumped features on the community and fired the supporting employees (e.g. mission control). They stopped supporting fully open projects to pivot towards ones with commercial editions (e.g. nashorn). They sued a reimplementer of their language, actively continue to keep things like the JCK hidden/non-open, reduce the age of JDK editions they'll help support, add confusing language around costs and use restrictions for their edition, etc. They are the only popular language stewards I know that continue to find any way they can to make a buck on the language itself and they reduce maintenance efforts at the same time.
Add to this their actively hostile treatment of users/developers in other segments of their business and it amazes me how many rush to their defense. "Look at all the new JVM features," they say, as though other language stewards can't do the same without all the bullshit. There's plenty to complain about without assuming ignorance on the complainers part.
Nashorn doesn't have a commercial edition and it's being deprecated in favour of GraalJS which is fully open source too.
The JCK is also open source now I think.
Reduce the age of the editions they'll help support - no, there are still LTS releases. Maybe they're supported for a few less years than Java 8 was but that's not unreasonable.
Your final complaint appears to be just "they're trying to make Java financially sustainable" which is hardly a problem, the lack of that is why Sun went down in the first place.
> Nashorn doesn't have a commercial edition and it's being deprecated in favour of GraalJS which is fully open source too.
Right, Graal has commercial versions and doesn't have community ownership.
> The JCK is also open source now I think.
No. I think you're making the same mistake as many and confusing the Java EE TCK with the Java TCK that was refused to Harmony and is non-open.
> Reduce the age of the editions they'll help support - no [...] Maybe they're supported for a few less years
A clear self-contradiction, and my point exactly.
> Your final complaint appears to be just "they're trying to make Java financially sustainable" which is hardly a problem, the lack of that is why Sun went down in the first place.
I think it is a problem. Languages these days cannot expect to be financially sustainable in and of themselves as it only incentivizes non-free actions against its users/developers. Sun's problem was not realizing this and their inability to be financially sustainable enough outside of the language to fund its development. Oracle won't have that problem, they'll take their pound of flesh from the language itself, free maintenance/support be damned. It might seem impractical to expect free language/runtime development paid by the stewards and with no cost on the developers, but it's clearly the only way to keep the ecosystem thriving sans perverse incentives.
Graal does, but the JavaScript engine does not. And the main thing the commercial edition of Graal gives is just faster performance. You can run GraalJS without the commercial edition and even without Graal at all! (it acts as an interpreter, in that case).
Languages these days cannot expect to be financially sustainable in and of themselves as it only incentivizes non-free actions against its users/developers
That's a circular argument. "Languages can't expect to be free because that'd require charging for something". Well, yes, by its nature that requires charging users for something.
I also wonder how you're defining "language" here. It seems to be pretty expansive. Java has a free top of class virtual machine, free compilers, free IDEs, free frameworks and so on. Many companies also sell enhanced versions of some of these things but that doesn't make the free versions less free.
It might seem impractical to expect free language/runtime development paid by the stewards and with no cost on the developers, but it's clearly the only way to keep the ecosystem thriving sans perverse incentives.
I actually have come to disagree with this over time, I see it as the other way around. If there's no commercial model, that's when the perverse incentives start. In the vacuum left by the obvious incentive of pleasing your customers, steps various perverse and self-destructive incentives instead, like "make a name for myself as someone very clever" or "do as little work as I can whilst not getting fired" or "experiment with fun research topics that probably won't amount to much".
Profit is ultimately just a signal that your users really do value what you're making. Without that signal things get crazy really fast. If this wasn't the case then academic languages would constantly smash commercially developed languages, but the most popular languages are generally the ones developed by companies who are focused - at least to some extent - on adoption. So not only do I not begrudge firms making commercially enhanced versions of things like programming tools, I have come to welcome it, because I associate a desire for profit with hard-headed, pragmatic and ultimately beneficial decision making.
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.
And if one is on Linux distribution like Red-Hat, or IBM/HP/Unisys platforms, cloud providers it is only a matter of calling update on the package manager.
If you guys are price sensitive, why are you not using OpenJDK? (Not to put too fine a point on it, but you sound commercial, so you guys could even consider contributing to it.)
