OpenJDK Java 20 Released With Latest Vector API, Scoped Values

[BrokenAnsible]

Coroutines, string templates, null safety, just to name a few.

Coroutines -> Java Loom is on the horizon and is in Java 20. Virtual threads are easier to use than Kotlin coroutines IMO.

String Templates -> JEP 430 exists and is in Java 20. Its in a pretty good state of affairs. It should release GA in Java 21

Null safety... if you aren't using Optional or some library variant of an Optional in modern code then I just don't know what to say? If you are interacting with legacy code... you need to push it down into null safe code around an Optional centric layer. You don't get any better when using Kotlin and legacy code. You still have to riddle your 'null safe logic' with ? everywhere. And the language lets you earmark variables with nullable so I am not sure what you are trying to get at. Kotlin doesn't save you from anything when you work with old libraries. Gosu kind of does, but that is another can of worms you mess with there regarding class loader compatibility that limit use cases.

While the first two examples are language Previews and you should not use them for building frameworks or hardened API's you can get a lot of mileage out of them for small projects, especially ones that will serve an ephemeral lifespan through agile development.

It does, but it still doesn't make Java a good fit for lambdas (AWS) for example. Those need to run as fast as possible (charging per 100ms iirc) and then stop. Rinse and repeat. Java is the exact opposite of that: it needs to run for a while so the JIT can work its magic, before offering good performance. There's CDS to help with that, but that's another thing virtually nobody uses.

Again, it depends on your use case. If you need to process XML payloads that are more complex than a Book example off the Internet and uses actual XML idioms that you only see in B2B corporate Object models from decades old interfaces that aren't going away for another 20 years... Python is not your man and anyone asking you to use Javascript should be slapped on sight. Your only option is C++, Java or C# typically. Especially if you your objects use a library that 'works' but hasn't been updated in 15 years but it won't work in any modern XML serializer library.

Furthermore, Java Lambda's don't run in a vacuum on AWS. If you are executing from s3 triggers or sinking from sqs or sns enough you should be making thread-safe Hot loaded contexts that get shared between invocations. You can use functional programming to lazy load your clients 1 time and are available across all instances. Put all your expensive to create objects in there and all that gets invoked is the lambda will be shared while the lambdas are hot. They are as fast as anything else. If you are trying, for instance, to create a Jackson ObjectMapper every time then you are missing some opportunities.

There is a bigger cost to NOT doing something sometimes. There is room for 'good fit' nonsense. Right tool for the right job. Your build of materials will typically let you know a path forward that is correct. It is a developers job to help itemize the costs of doing it responsibly and letting the product owner decide what they still want.

[bug77]

BrokenAnsible Yes, some of those features are making their way into the JDK. But my point was Java is falling behind. These features have been available in Kotlin for over 5 years. Scala's case classes and proper pattern matching? Available for probably 10 years now, yet the JDK is still not caught up (has records, switch is still pretty dumb).

[BrokenAnsible]

BrokenAnsible Yes, some of those features are making their way into the JDK. But my point was Java is falling behind. These features have been available in Kotlin for over 5 years. Scala's case classes and proper pattern matching? Available for probably 10 years now, yet the JDK is still not caught up (has records, switch is still pretty dumb).

That is a silly position to take. You are parroting a position that will never change. Java will never be as up to date as the other JVM languages can be because the other JVM languages have different priorities, timelines and roadmaps. Groovy will test against their test cases and on target JREs. They won't have the same swat room meetings as the the Java JEP developers when a new release goes GA and a memory leak or a CEV is found in the wild.

What you don't say is how, Java is moving faster than ever before towards features that people want despite providing backwards compatibility. Java in 2023 is great. Who would have thought there would be a SIMD vector api in the language?

[bug77]

That is a silly position to take. You are parroting a position that will never change. Java will never be as up to date as the other JVM languages can be because the other JVM languages have different priorities, timelines and roadmaps. Groovy will test against their test cases and on target JREs. They won't have the same swat room meetings as the the Java JEP developers when a new release goes GA and a memory leak or a CEV is found in the wild.

What you don't say is how, Java is moving faster than ever before towards features that people want despite providing backwards compatibility. Java in 2023 is great. Who would have thought there would be a SIMD vector api in the language?

Silly? I think not. It's not like I compared Java to Erlang, Haskell or Rust. I just pointed out features other have been built by others on top of what the JVM already offers while Java took years to catch up. I pointed out coroutines and string templates among other things. These aren't nice feature, strictly regarding Kotlin's priorities. These are feature that are becoming ubiquitous these days.

[nadirx]

Silly? I think not. It's not like I compared Java to Erlang, Haskell or Rust. I just pointed out features other have been built by others on top of what the JVM already offers while Java took years to catch up. I pointed out coroutines and string templates among other things. These aren't nice feature, strictly regarding Kotlin's priorities. These are feature that are becoming ubiquitous these days.

True, but it is easier to steer smaller things.
The new 6-month rapid release approach is finally changing things: we're seeing a lot of great things happening both in the language, in the JVM and in other related technologies (GraalVM), so there is hope.

[bug77]

True, but it is easier to steer smaller things.
The new 6-month rapid release approach is finally changing things: we're seeing a lot of great things happening both in the language, in the JVM and in other related technologies (GraalVM), so there is hope.

Even that is debatable. It took records 3 or 4 preview releases to be finalized. That's like 2 years. In the early days, a 2 year release would net us collections, or NIO, or generics. But maybe it's not a fair comparison, it's always easier to move faster at first, where there's little legacy to care about.

[BrokenAnsible]

Silly? I think not. It's not like I compared Java to Erlang, Haskell or Rust. I just pointed out features other have been built by others on top of what the JVM already offers while Java took years to catch up. I pointed out coroutines and string templates among other things. These aren't nice feature, strictly regarding Kotlin's priorities. These are feature that are becoming ubiquitous these days.

I think you are trying to project how you perceive the tools and how the tools are built. Java will never be feature parity with the other languages because the motivations of the other languages are to out pace the Java language itself. Its a redundant argument to point that out. It will always be that way. It is the alternate languages raison d'être.

Typically when the Java languages provides something after it catches up its the better implementation and the language developers move their code onto the out-of-the-box implementation on that version of the JVM going forward. Which perpetuates a cycle of the alternate language getting native speed boosts for something they typically implemented unoptimized then moving on to a new feature to create another feature gap. Kotlin 1.5 doesn't work with Java 6 or 7 anymore for these reasons. Also 'ubiquitous' is a nebulous word regarding established programming languages. The people who rely on Java 11 LTS don't care about any of those features. If they did, they'd use Kotlin already. But the millions of application installations using Java obviously just don't care. And even when Netty, Jetty or some other great new library/framework comes out and adopts something, like Virtual threading, they still won't care even if they use the framework that will now make heavy use of it.

This is nature of any widely adopted platform. Java is the Debian stable of programming languages. If you needed something newer than stable prior to their 6 month rapid release approach you would just go get the Ubuntu of programming languages (Kotlin/Scala/Groovy). In 2023 that may just mean you use Debian Sid itself and not the Ubuntu...

[bug77]

I think you are trying to project how you perceive the tools and how the tools are built. Java will never be feature parity with the other languages because the motivations of the other languages are to out pace the Java language itself. Its a redundant argument to point that out. It will always be that way. It is the alternate languages raison d'être.

We're talking about features available for over 5 years that Java hasn't managed to adopt. But let's assume you are right and my analogy is flawed. Let's not look at languages built on top of the JVM. Let's look at Java's main competitor, C#. Do you feel Java is picking up features faster than C#?

Typically when the Java languages provides something after it catches up its the better implementation and the language developers move their code onto the out-of-the-box implementation on that version of the JVM going forward. Which perpetuates a cycle of the alternate language getting native speed boosts for something they typically implemented unoptimized then moving on to a new feature to create another feature gap. Kotlin 1.5 doesn't work with Java 6 or 7 anymore for these reasons. Also 'ubiquitous' is a nebulous word regarding established programming languages. The people who rely on Java 11 LTS don't care about any of those features. If they did, they'd use Kotlin already. But the millions of application installations using Java obviously just don't care. And even when Netty, Jetty or some other great new library/framework comes out and adopts something, like Virtual threading, they still won't care even if they use the framework that will now make heavy use of it.

That's a fallacious argument. Mostly because people don't miss things they don't know about and many programmers (barely) master one language. If your argument was sound, why add any feature to any language that is currently in use?

This is nature of any widely adopted platform. Java is the Debian stable of programming languages. If you needed something newer than stable prior to their 6 month rapid release approach you would just go get the Ubuntu of programming languages (Kotlin/Scala/Groovy). In 2023 that may just mean you use Debian Sid itself and not the Ubuntu...

It is a deliberate choice to preserve backwards compatibility, yes (and there's value in it, I'm not disputing that). But where you see Debian, I'm afraid I'm look at the next Cobol.

[BrokenAnsible]

We're talking about features available for over 5 years that Java hasn't managed to adopt. But let's assume you are right and my analogy is flawed. Let's not look at languages built on top of the JVM. Let's look at Java's main competitor, C#. Do you feel Java is picking up features faster than C#?

I don't care what C# does. C# has had some great features for years and Kotlin and Gosu both have taken ideas from them and brought it to the JVM. Java has access to those features by libraries and compiler plugins as well. If the language itself lingers it doesn't matter. Moreover, You should be asking yourself, according to your argument, why C# hasn't managed to adopt functional programming since F# is eating their lunch and has been available for years.

That's a fallacious argument. Mostly because people don't miss things they don't know about and many programmers (barely) master one language. If your argument was sound, why add any feature to any language that is currently in use?

Your argument is from the position of how you want to write code, not who you are writing code for or the build of materials you need for use actual use cases. Java as a language is just a syntax, albeit a core syntax. Most projects don't need but 2% of the Java api. Why are you arguing for the extra 0.02% that might be shimmed in by another syntax? If a developer needs a specific feature and cannot find a library for it or write their own library for it, then they look for answers that may include adding in some other language.

I run work on some middleware that uses Kotlin in a spring boot application that started as Java. I could not use Manifold at the time and I didn't want to spend X days writing static utilities to work with Generated code from a 10 year old library. Kotlin was the perfect fit because I didn't want to write static utilities in a specific way in my Java app. I am using Kotlin like I would any library. Now, under the hood we know this is just decoration and static binding... but I wanted my code to look a certain way for reasons that make sense to that project. I could have done it in Java 100% and the bytecode would probably have been 99.9% the same.

It is a deliberate choice to preserve backwards compatibility, yes (and there's value in it, I'm not disputing that). But where you see Debian, I'm afraid I'm look at the next Cobol.

Everything is the next Cobol by your view point I feel. The distinction between Cobol and every other large modern language (except maybe perl) is that the language is having a problem with mind share. Developers who are keen to Cobol are aging out and not being replaced. But the codebase is too important. This is why IBM and Unisys will let you keep a cobol core while providing plumbing to MVC structures for PHP/Java/C# etc. They are honestly doing God's work for that industry.

But a big reason why Cobol is dying out is because most developers in general who you say many programmers (barely) master one language are in fact not mastering the core concepts of programming in general because at the end of the day the language syntax doesn't matter as long as you are being data driven. They are being too religious about their language and the paradigms that language exists in. Reading Cobol is a system shock to a C-like programmer, but if think in data structures and not your favorite paradigm you can make sense of it.

Programming paradigms are ways to organize your code. Languages provide structure around it and the ideas they want to convey. Some languages do a better job at a thing than others. Java and C# have the bonus of being core languages on top of a virtual machine that lets you co-mingle ideas together instead of having messy language bindings as the only resort. The Java language itself provides a robust set of ideas out of the box. You cannot responsibly call Java the next Cobol, that is an emotional reaction to a misguided perception. It is impossible without many other languages going out of the mindshare as Cobol is headed. The syntax shares a core structure with C, C++, C#, TypeScript and PHP to name a few.

Java as a core language is alive and well. I am not sure where your point of reference comes from.