Growing the Java Language [video]

I enjoyed both talks a lot.

I really appreciate the work done to evolve Java. They seem to be able to both fix earlier mistakes (and there were many!) and new ones from happening. While I see other languages struggling with the weight of complexity added over time, Java seems to get simpler and easier even with significant updates to the language spec.

I'm concerned about Spring Framework shenanigans. It's under Broadcom now, which feels like a dangerous steward. Just few weeks ago Broadcom discontinued newly acquired bitnami images.

It's hard to imagine Java without Spring, everyone uses Spring.

Quarkus and Vaadin is pretty productive.

Yes :)

Checked exceptions are not the problem. In fact, I don't think there should be ANY unchecked exceptions outside of OOM and other JVM exceptions. I will die on this hill. The actual problem is that handling exceptions in Java is obnoxious and verbose. I cannot stress enough how bad it feels going from Zig back to Java, error-handling wise. If Java had Zig-style inline catching, there wouldn't nearly be as much humming and hawing over checked exceptions.

I think checked exceptions are fine, they just haven't updated them along with other features. We now have expression based switch, why not have expression based try-catch? The other major problem is inability to pass them through the new functional interfaces, since they usually don't have anything like `<X> throws X`. But this could be solved by an Optional-like type.

(I am primarily a C developer)

What is the problem with Checked Exceptions? Don't they just provide type checking? I would think that developers would want to know which function might or might not execute a non-local goto in middle of execution and handle that properly, since debugging that will be a mess.

I disagree entirely, but I'd love to hear your arguments (other than vague allusions to "popularity" and other languages).

Improved checked exception handling in Streams would be nice, but that's my only gripe with them. They force you to stop and think, which is a good thing.

There are some checked exceptions that should probably be unchecked, like UnsupportedEncodingException thrown by ByteArrayOutputStream::toString which takes a charset name. I'm sure there are other subclasses of IOException that could be an IllegalArgumentException instead. But those few inconveniences don't invalidate the concept of checked exceptions.

I would like some sort of pragma that would allow me to ignore all checked exceptions in a file. Something like "use nocheck;" and then all methods would implicitly throw Exception.

Sometimes I want to write a small program for a one-off task and handling Exceptions is absolutely unnecessary.

Obviously YMMV, but I like checked exceptions

it's is kind of interesting that we are in a phase where Rust is the "cool" language even though it has a similar kind of feature. I wonder which way it will age.

This is a typical opinion to have. This is also an uninformed opinion.

All Java needs is better syntax to handle exceptions. Nobody wants to open a whole block to handle an expected exception.

``` switch (f.get()) {

    case Box(String s) when isGoodString(s) -> score(100);

    case Box(String s)                      -> score(50);

    case null                               -> score(0);

    case throws CancellationException ce    -> ...ce...

    case throws ExecutionException ee       -> ...ee...

    case throws InterruptedException ie     -> ...ie...

I think the «best practices» found in Java enterprise has meant that a lot of people think all Java has to look like that.

High performance Java is awesome and can be competitive with C++ and Rust for non trivial systems, thanks to much better development cycle, debugging and high quality libraries.

Most the benefits is the JVM, so Kotlin has those too, but I don’t feel Kotlin is enough of an improvement to warrant the downsides (at least for me). But both Kotlin, Scala and Clojure are great for the Java ecosystem.

Java is controlled by Oracle. It's not that different from Kotlin in that respect. Go is controlled by Google. Swift is controlled by Apple. Typescript, C#, F#, VB, etc. are Microsoft controlled things. It's not like the grass is that much greener next door. I don't think these things are show stoppers. A lot of this stuff is open source after all.

Jetbrains considered using Scala before they created Kotlin. I think they were right. With Kotlin they went for a bit more conservative approach. Mainly undoing things that aren't so great in Java language and unlikely to change for language compatibility reasons, and avoiding some of the pitfalls with Scala. I think Scala saw a bit of wild growth of features and frameworks that Kotlin largely avoided. For better or worse, there has been a bit of a Scala diaspora with people flocking to things like Rust, Elixir, and indeed some to Kotlin.

Weather people like it or not, Kotlin plays very nice with existing Java code bases. By design. It was designed as a drop in replacement. It's why it caught on with Android developers before it even was released. It's a bit different from Scala in that respect, which while it worked alright with Java code bases really nudged you away from that to the point where you'd be swapping out your build tools, frameworks, etc.

At this point Kotlin is arguably a better language to use with any of the popular Java frameworks. I'm not really aware of any exceptions to this. Spring is a good example (arguably the most popular server framework for Java and the JVM). IMHO you are missing out if you are not using that with Kotlin. The Spring people certainly seem to agree. They've invested lots of time and effort to make Kotlin a first class citizen in the ecosystem. Documentation is dual Kotlin/Java, the framework ships with lots of extension functions for Kotlin and Kotlin specific features, and expanded Kotlin support is one of the headline features for the upcoming major version. And it's not like the previous version was particularly lacking on that front. They've been supporting the Kotlin ecosystem for many years now.

I've coded in both. I prefer Java but Kotlin is pretty cool also. And Clojure.