BoyRobot777

5 yıl öncediscuss

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

5 yıl öncediscuss

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

5 yıl öncediscuss

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

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

BoyRobot777

5 yıl öncediscuss

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

5 yıl öncediscuss

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

5 yıl öncediscuss

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

BoyRobot777

5 yıl öncediscuss

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

5 yıl öncediscuss

>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

5 yıl öncediscuss

I was not aware that Microsoft invented algebraic data type.

BoyRobot777

5 yıl öncediscuss

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

BoyRobot777

5 yıl öncediscuss

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

5 yıl öncediscuss

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

BoyRobot777

5 yıl öncediscuss

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

5 yıl öncediscuss

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

comments