Hacker News new | comments | show | ask | jobs | submit login
Entering the next phase of Project Valhalla (java.net)
67 points by arto 66 days ago | hide | past | web | favorite | 26 comments



A lot more details about carriers and L, and LW1: http://mail.openjdk.java.net/pipermail/valhalla-spec-experts...


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


Background

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

Oh right, well that clears that up.


https://wiki.openjdk.java.net/display/valhalla/Minimal+Value...

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

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


It’s an email to the Valhalla-spec-experts mailing list. It’s not unreasonable to expect that they know the terminology.


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


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


C#


Lol


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.


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.


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


You're quite happy with only getting security patches for 6 months from release? Really?


It is only Oracle that is limiting security patches to 6 months. Others don't necessarily have that limitation. Check out Adopt OpenJDK.


Excusers gonna excuse.

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.


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


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

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.


https://adoptopenjdk.net/support.html

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


Have you even considered OpenJDK and adoptopenjdk.net ?


We're just moving the entire company to OpenJDK come November.

Looking like it'll be a pretty seemless transition actually.


Indeed - simonh's response is hysterical (in both senses). The first release of 11 is here:

https://adoptopenjdk.net/archive.html?variant=openjdk11&jvmV...

And there will be more over the next three years. No contact with Oracle, legal or digital, is required.


Ever heard of OpenJDK?

Some people just love to hate Oracle.

Yet paying for Sun's support was perfectly fine.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: