BoyRobot777

vor 5 Jahrendiscuss

Is everything still glued together without being able to repair yourself? /s

vor 5 Jahrendiscuss

You won't need to rewrite into async model, because project Loom will introduce virtual threads. That means your sync code will look exactly the same, but will have scalability of async.

BoyRobot777

vor 5 Jahrendiscuss

https://advancedweb.hu/a-categorized-list-of-all-java-and-jv...

Only missing stuff from 17, but that's a short list.

BoyRobot777

vor 5 Jahrendiscuss

This will be solved[1]:

record Point(int x, int y) {}

Point p = new Point(1, 2); Point pp = p with { x = 3; }

[1] https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...

BoyRobot777

vor 5 Jahrendiscuss

Value classes cannot provide the performance/memory flatness that Valhalla will bring though. So I'm not really sure what benefit does "values classes" bring. Just to make sure, you are talking about the inline class which is just a wrapper around single property?

   inline class Password(val value: String)

BoyRobot777

vor 5 Jahrendiscuss

I very much like text blocks as well. SQL/JSON can be finally understandable without all the "\n" +

BoyRobot777

vor 5 Jahrendiscuss

I think Loom can be abstracted away by Kotlin quite easily. Valhalla on the other hand won't work at all. You won't be able to have inline classes in android/older Java versions. Even more - specialized generics.

BoyRobot777

vor 5 Jahrendiscuss

>While they're about it, they should also add immutable/copying data structures.

They will start with records[1], but I think all value classes (Valhalla) should have this functionality eventually.

You will be able to write:

   record Point(int x, int y){}
   Point pp = p with { x = 3; }

[1]https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...

BoyRobot777

vor 5 Jahrendiscuss

I was not aware that Microsoft invented algebraic data type.

BoyRobot777

vor 5 Jahrendiscuss

Every thread about new Java version has the same comment all the time. Why share it? What kind of response do you seek?

BoyRobot777

vor 5 Jahrendiscuss

There was a lengthy discussion some time ago[0]. Quote:

#### Why not "just" make contextual keywords?

At first glance, contextual keywords (and their friends, such as reserved type identifiers) may appear to be a magic wand; they let us create the illusion of adding new keywords without breaking existing programs. But the positive track record of contextual keywords hides a great deal of complexity and distortion.

Each grammar position is its own story; contextual keywords that might be used as modifiers (e.g., `readonly`) have different ambiguity considerations than those that might be use in code (e.g., a `matches` expression). The process of selecting a contextual keyword is not a simple matter of adding it to the grammar; each one requires an analysis of potential current and future interactions. Similarly, each token we try to repurpose may have its own special considerations; for example, we could justify the use of `var` as a reserved type name because because the naming conventions are so broadly adhered to. Finally, the use of contextual keywords in certain syntactic positions can create additional considerations for extending the syntax later.

Contextual keywords create complexity for specifications, compilers, and IDEs. With one or two special cases, we can often deal well enough, but if special cases were to become more pervasive, this would likely result in more significant maintenance costs or bug tail. While it is easy to dismiss this as “not my problem”, in reality, this is everybody’s problem. IDEs often have to guess whether a use of a contextual keyword is a keyword or identifier, and it may not have enough information to make a good guess until it’s seen more input. This results in worse user highlighting, auto-completion, and refactoring abilities — or worse. These problems quickly become everyone's problems.

So, while contextual keywords are one of the tools in our toolbox, they should also be used sparingly.

[0]. https://mail.openjdk.java.net/pipermail/amber-spec-experts/2...

BoyRobot777

vor 5 Jahrendiscuss

Why not Kotlin, C#, F#, ML and so many other languages?

BoyRobot777

vor 5 Jahrendiscuss

With records, multi-line strings, and upcoming pattern matching + virtual threads, I hardly see any need to switch languages. I really enjoy working with Java and JVM ecosystem which is very vibrant and has a plethora of tools/libraries.

I'm happy when I'm productive and ship stuff. I'm unhappy when I have to struggle with obscure/undocumented libraries/tools.

BoyRobot777

vor 5 Jahrendiscuss

> no more Hibernate and so on

Quarkus, Redhat's, native first frameworks works fine with Hibernate and GraalVM. One of contributors gave a [talk](https://www.youtube.com/watch?v=za5CSBX-UME&feature=youtu.be)

BoyRobot777

vor 7 Jahrendiscuss

What licensing costs? OpenJDK is free. As it always have been. OracleJDK and OpenJDK starting from version 11 are virtually the same.

BoyRobot777

vor 7 Jahrendiscuss

Except the opposite is happening lol:

- Contributes pretty much all of the closed source technologies (or what was originally to become closed source) of the Oracle JDK to OpenJDK, for example giving the community: JDK Flight Recorder; JDK Mission Control; ZGC; …and probably more stuff I can’t think of right now;

- Ensures the Oracle JDK and the OpenJDK builds are virtually indistinguishable;

- Starts providing a free OpenJDK build (which includes all these donated technologies);

- Provides uncountable man hours of maintaining and innovating the Java platform;

- Ensures that the community knows where to find the free bits by linking to them, and slaps on a bright yellow warning sign, so that everyone can see that the licensing has changed;

Some bits do not even make sense: >OpenJDK might survive as permanently stuck in version 8

??? Wat?

BoyRobot777

vor 7 Jahrendiscuss

> We were told <...>

Yeah. Say no more... If only you would have looked. Anyhow, Oracle does the following:

- Contributes pretty much all of the closed source technologies (or what was originally to become closed source) of the Oracle JDK to OpenJDK, for example giving the community: JDK Flight Recorder; JDK Mission Control; ZGC; …and probably more stuff I can’t think of right now;

- Ensures the Oracle JDK and the OpenJDK builds are virtually indistinguishable;

- Starts providing a free OpenJDK build (which includes all these donated technologies);

- Provides uncountable man hours of maintaining and innovating the Java platform;

- Ensures that the community knows where to find the free bits by linking to them, and slaps on a bright yellow warning sign, so that everyone can see that the licensing has changed;

And how does the community react, you wonder? Yep, that’s right. “Oracle is the Devil”, “This is a bait and switch operation” etc. Ad nauseum.

ONCE AGAIN. You do not need to use OracleJDK. Just use OpenJDK from AdoptOpenJDK.

comments