Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 20 / JDK 20: General Availability

mail.openjdk.org

Post reply on HN
Print view View original

121–130 of 356 posts

Re: Java 20 / JDK 20: General Availability

#121

Post by spicybright »

barkingcat wrote: post #86

Minor typo in the linked site: "JDK 20 reached General Availability on 21 March 2022" Should be 21 March 2023 Not sure who can edit that page but putting here.

Just adding too, I think some of the switch statement example code is wrong:

    Object obj = 123L;
    String formatted = switch (obj) {
        case Integer i -> String.format("int %d", i);
        case Long l    -> String.format("long %d", l);
        case Double d  -> String.format("double %f", d);
        case String s  -> String.format("String %s", s);
        default        -> o.toString();
    };
Unless I'm not understanding something, the default statement should be `obj.toString()` as `o` isn't defined.

Re: Java 20 / JDK 20: General Availability

#122

Post by gcl09 »

taftster wrote: post #103
DonHopkins wrote: post #89

Why not just use C# instead? It was purposefully designed to address and correct the many mistakes of Java, and much more importantly, it's not owned by Oracle.

All the while, adding its own mistakes to the pile. As an example, idiomatic Java style is moving away from getters/setters and instead favors builders and immutable types. That whole inheritance vs. composition concept is changing the way Java is being used. Meanwhile, C# has baked getters/setters so deep into their language (as properties) that there's just no moving off of them. Have you tried making a Builder in…

Aren't records and init only setters in C# also a way to favor immutable types and fix setters in properties? (Not trying to criticize, I really want to know).

Re: Java 20 / JDK 20: General Availability

#124

Post by dcminter »

Alifatisk wrote: post #98
akavi wrote: post #26

Now even Java has pattern matching, what's Javascript's excuse? Literally the only feature preventing Typescript from being my perfect language.

What’ the hype with pattern matching? What does it solve?

It's really nice syntactic sugar. Complicated conditional logic cluttered with redundant types turns into a series of simple patterns. "Just" makes it easier to not make stupid bugs (I'm all for it).

Re: Java 20 / JDK 20: General Availability

#125

Post by rerdavies »

pajko wrote: post #60
mikepurvis wrote: post #45

Earlier quoted context omitted.

I'm not a Java user, but I really don't love the overloading of `if` in Python (statement, ternary, comprehensions), so introducing a new keyword here seems pretty reasonable to me. And don't even get me started on `static` in C++.

OK, no static then, but what about if constexpr (...) ? :D

And then there's "static constexpr" (which is only used in places where non-static constexprs are illegal). An overloaded keyword that's become so overloaded, it's even used in places where it's completely unnecessary! :-P

Re: Java 20 / JDK 20: General Availability

#127

Post by rerdavies »

logistark wrote: post #100
taftster wrote: post #84

Earlier quoted context omitted.

I mean, that's OK though. Not sure why this is considered such a bad thing. You're missing out on some new language features, sure, but Java 8 is still reliable and rock solid. There's lots of companies that have hesitation or even inability to upgrade, hopefully there's at least some initiative and/or direction to do so. A company that is head-in-sand deliberately not upgrading from Java 8 is one thing. A company th…

I think that the main problem upgrading beyond Java 8 is Java 9 and module system and a lot of javax package classes that were removed. It will be very helpful a tool that can detect what modules or classes that are being used by your codebase and add them as maven or gradle dependencies and add them to the classpath.

The main problem with upgrading beyond Java 8 is that it's Android! And we all know how THAT went.

Re: Java 20 / JDK 20: General Availability

#128

Post by brabel »

Alifatisk wrote: post #98
akavi wrote: post #26

Now even Java has pattern matching, what's Javascript's excuse? Literally the only feature preventing Typescript from being my perfect language.

What’ the hype with pattern matching? What does it solve?

Hype with pattern matching? That sounds quite funny to me considering certain languages (Haskell, Erlang, OCaml...) have had that for decades.

What convinced me of the power of pattern matching was seeing a red-black binary tree being implemented effortlessly in Ocaml (I think), while in C++ and Java it was a really difficult algorithm to implement.

When you have provably exhaustive pattern matching (i.e. the compiler forces you to handle every possible case), certain things that are very difficult to write otherwise become very easy.

Re: Java 20 / JDK 20: General Availability

#129

Post by munificent »

Alifatisk wrote: post #98
akavi wrote: post #26

Now even Java has pattern matching, what's Javascript's excuse? Literally the only feature preventing Typescript from being my perfect language.

What’ the hype with pattern matching? What does it solve?

If you've ever done any assembly programming or worked with other old or low level languages, you may have encountered an environment where you can write simple operator expressions, but you can't compose them. So this is OK:

    a = b + c
    d = e - f
    g = a * d
But the compiler doesn't allow:

    g = (b + c) * (e - f)
You have expressions that produce, but they don't compose. You can't produce a value from a more complex, nested expression. We, rightly, no longer use languages like that.

Pattern matching parallels that, except for assignment and decomposing values. Many languages today let you write:

    topLeft = rect.topLeft.x;
    left = topLeft.x;
    top = topLeft.y;
    bottomRight = rect.bottomRight;
    right = bottomRight.x;
    bottom = bottomRight.y;
Or even:

    left = rect.topLeft.x;
    top = rect.topLeft.y;
    right = rect.bottomRight.x;
    bottom = rect.bottomRight.y;
(Because at least you can compose expressions on the RHS.) But they don't let you write:

    (topLeft, bottomRight) = rect;
    (left, top) = topLeft;
    (right, bottom) = bottomRight;
Or even:

    ((left, top), (right, bottom)) = rect;
Pattern matching gives you that. It is freely composable destructuring.

Also, the "matching" part means that in many languages you can also ask questions about values as you destructure them, which enables a particularly nice style of programming.

Re: Java 20 / JDK 20: General Availability

#130

Post by taftster »

gcl09 wrote: post #122
taftster wrote: post #103

Earlier quoted context omitted.

All the while, adding its own mistakes to the pile. As an example, idiomatic Java style is moving away from getters/setters and instead favors builders and immutable types. That whole inheritance vs. composition concept is changing the way Java is being used. Meanwhile, C# has baked getters/setters so deep into their language (as properties) that there's just no moving off of them. Have you tried making a Builder in…

Aren't records and init only setters in C# also a way to favor immutable types and fix setters in properties? (Not trying to criticize, I really want to know).

Kind of. It gets you close.

With the Builder pattern, you can easily define complex relationships for your class inner state. Like maybe if A & B are specified, then C shouldn't be specified. But if C is specified, then D should have a default value. Etc.

These types of initialization requirements are not easily duplicated with C# init-only construction. Instead, in C# you have to rely on the callers to know exactly how to correctly instantiate your class, including all the complex logic like in the example above.

So yes, C# init-only setters are kind of the best option you have. You can still create a C# FooBuilder for a Foo class. But generally C# programmers want to go out of their way to directly instantiate a Foo, and the number of bugs you get from this is crazy. It's a culture thing, honestly, not as much a language problem.

My two cents.

Post reply on HN