Java 23: The New Features Are Officially Announced(coderoasis.com)
coderoasis.com
Java 23: The New Features Are Officially Announced
https://coderoasis.com/java-23-new-features/
136 comments
Maybe it's worth noting that a very similar looking article from the same website was recently flagged and is dead because it appeared to be AI generated nonsense: https://news.ycombinator.com/item?id=39872271
I haven't checked if this one is correct.
I haven't checked if this one is correct.
This one is partially nonsense too. Here's a snippet that starts talking about super() and then abruptly switches to string templates.
> These include statements before super(…), which would give developers greater freedom in expressing constructor behavior – meaning string templates. This would make it easy to express strings that include values computed at run time – meaning scoped values. This would enable sharing of immutable data within and across threads; and implicitly declared classes and instance main methods.
> These include statements before super(…), which would give developers greater freedom in expressing constructor behavior – meaning string templates. This would make it easy to express strings that include values computed at run time – meaning scoped values. This would enable sharing of immutable data within and across threads; and implicitly declared classes and instance main methods.
All of that stuff about strings is utter nonsense. And it doesn't link the JEP for statements before super (https://openjdk.org/jeps/447).
The conclusion of the article is clearly nonsense. How would the features presented, which include an API for generating JVM bytecode, "make it easier for beginning programmers to write programs without needing to understand the programming language features designed for larger or enterprise application development"?
It might be plagiarized from an Infoworld article [0] which also talks about these features and uses a similar phrase – "make it easier for beginning programmers to write programs without needing to understand language features designed for large programs" – but there it specifically refers to "implicitly declared classes and instance main methods", i.e. JEP 463 [1].
[0] https://www.infoworld.com/article/3714933/jdk-23-the-new-fea...
[1] https://openjdk.org/jeps/463
It might be plagiarized from an Infoworld article [0] which also talks about these features and uses a similar phrase – "make it easier for beginning programmers to write programs without needing to understand language features designed for large programs" – but there it specifically refers to "implicitly declared classes and instance main methods", i.e. JEP 463 [1].
[0] https://www.infoworld.com/article/3714933/jdk-23-the-new-fea...
[1] https://openjdk.org/jeps/463
While the Stream Gatherers will be very nice once they're out of preview, and the Vector API seems very useful, I'm most excited by (finally!) being able to execute some statements before calling super(). It was always possible to call super(Foo.bar()); , but it was never possible to call foo = Foo.bar(); super(foo);
I'm digging this steady progress.
I'm digging this steady progress.
C# needs to introduce super() for the same reason.
The article makes it sound like the feature set has been finalized, but is that really the case? I'm struggling to find evidence for this, and the official page does not seem to indicate this at all: https://openjdk.org/projects/jdk/23/
No, the feature set is not finalized. This is just a random blog post, nothing more. Like who says "New Features Are Officially Announced"? Which source? They make it look like Java 23 is done, but it's not.
If you want see what's coming in Java 23 you have to check https://openjdk.org/projects/jdk/23/ - the only source of truth. If you look at the Schedule of that page you will see at least before Rampdown Phase One there still is time to add new JEPs. And there will more JEPs be added for sure, that's how it was done in the past.
If you want see what's coming in Java 23 you have to check https://openjdk.org/projects/jdk/23/ - the only source of truth. If you look at the Schedule of that page you will see at least before Rampdown Phase One there still is time to add new JEPs. And there will more JEPs be added for sure, that's how it was done in the past.
https://openjdk.org/jeps/469?ref=coderoasis.com
vector api looks nice
what resources exist for say a half-way decent python dev like myself to get into java development?, I'm mostly a back end dev / data engineer
from the article:"Overall, these changes will make it easier for beginning programmers to write programs without needing to understand the programming language features designed for larger or enterprise application development. "
what resources exist for say a half-way decent python dev like myself to get into java development?, I'm mostly a back end dev / data engineer
from the article:"Overall, these changes will make it easier for beginning programmers to write programs without needing to understand the programming language features designed for larger or enterprise application development. "
If you care about portable SIMD and performance, you may be better served by Vector APIs in C# instead which has low-level but cross-platform abstractions stabilized since .NET 7 and an extensive guide to using those: https://github.com/dotnet/runtime/blob/69110bfdcf5590db1d32c...
CoreLib and many new libraries are using it heavily to match performance of manually intrinsified C++ code.
CoreLib and many new libraries are using it heavily to match performance of manually intrinsified C++ code.
very cool
I've come around to C# use of composition and the repository pattern since it's first introduction to me where I balked at it
It's probably time to revisit C#
I've come around to C# use of composition and the repository pattern since it's first introduction to me where I balked at it
It's probably time to revisit C#
Generally speaking, JVM favours more high-level languages, while .NET is the low-level focused counterpart in many of its areas, so if that's what you are looking for, it might pleasantly surprise you :)
The part about making it easier for beginning programmers probably refers to JEP 436 [0] which allows you to leave out some of the tedious boilerplate around the entrypoint for simple programs, just like in Python (well, there is still some extra boilerplate compared to Python). It has nothing to do with the vector API.
The article confuses these two things because it's AI-generated word salad and plagiarized the phrase from somewhere else.
(Also, why does the article include a "ref" parameter in its links? Does openjdk.org have some sort of affiliate program?)
[0] https://openjdk.org/jeps/463
The article confuses these two things because it's AI-generated word salad and plagiarized the phrase from somewhere else.
(Also, why does the article include a "ref" parameter in its links? Does openjdk.org have some sort of affiliate program?)
[0] https://openjdk.org/jeps/463
When it comes to language itself, I don't see there being any good reason to pick java over c# these days.
If you compare ecosystems then maybe, but it terms of language features I don't know why would any1 ever pick java from scratch in this day and age.
If you compare ecosystems then maybe, but it terms of language features I don't know why would any1 ever pick java from scratch in this day and age.
Because Java's combination of performance, productivity, observability, and stability is unmatched. The average codebase lifetime of large, important server software is over a decade, so not only do you want the first three, but to get a good return on your investment, you also want the fourth (over time, different parts of the codebase will see more or less development, and you don't want to spend money on maintaining parts that you don't want to focus on). Now, it's true that the biggest Java shops, where new projects are regularly developed in Java, are traditional businesses like Apple, Amazon, Google, Netflix, Alibaba, Tencent, and other Fortune 500 companies -- companies that care a lot about the value (and cost) of the codebase not just in the moment but over time -- whereas smaller companies are more diversified in their language choice, but they, too, often adopt Java more as they grow.
C# and .net platforms matches (or more often even exceed) java in all those categories.
Looking at what big companies are doing is also weak argument, especially since Google literally developed their own language which slots in the same space as Java. Maybe not exactly the same, but pretty close.
Again, if you need compatibility with existing code - that it's a decent argument. But in terms of language itself? No good reason
Looking at what big companies are doing is also weak argument, especially since Google literally developed their own language which slots in the same space as Java. Maybe not exactly the same, but pretty close.
Again, if you need compatibility with existing code - that it's a decent argument. But in terms of language itself? No good reason
Google is a major Java shop, and for big projects compatibility is certainly at the top of requirements because big codebases last for a long time, and compatibility directly translates to increased future returns on investment. I don't think .NET quite matches Java on the other aspects (certainly it tries to add lots of language features while Java tries to avoid adding many features, but having more or fewer features is a matter of personal preference) and its GCs aren't as good, but while these things are arguable (because Java and .NET have different advantages and disadvantages compared to each other), its compatibility story is poor, and not just in comparison to Java.
In the data engineering space JVM languages are probably neck and neck or even favored over Python. Hadoop, Spark these things. I know big firms like Apple — where I’d love to end up doing DE stuff — are big on Java and Hadoop style things.
I just know I need to branch out. I’m decent at Python and SQL but I could learn some more.
I just know I need to branch out. I’m decent at Python and SQL but I could learn some more.
Apple use Scala, not Java, for that sort of thing. At least that was the case last time I interacted with them.
Here are some of the suggested starting points for Scala: https://docs.scala-lang.org/
Here are the Scala books I've written: https://noelwelsh.com/landing/books/
Here's the coding group I run: https://www.scalabridgelondon.org/
ScalaBridge's online events have attendees from across Europe.
Here are some of the suggested starting points for Scala: https://docs.scala-lang.org/
Here are the Scala books I've written: https://noelwelsh.com/landing/books/
Here's the coding group I run: https://www.scalabridgelondon.org/
ScalaBridge's online events have attendees from across Europe.
Learning Java will give you a leg up on Scala, as C would for C++. Even more so because Scala is still dirtectly implemented on Java at runtime, you'll be looking at Java stack traces and interacting with JVMs every day you work with Scala.
If you don't know either you might as well start with Java-- walk before you run. Scala is very much an unfocused kitchen sink multiparadigm language (in the sense similar as C++ or perl) so there's not really a focused core to start on other than Java.
If you don't know either you might as well start with Java-- walk before you run. Scala is very much an unfocused kitchen sink multiparadigm language (in the sense similar as C++ or perl) so there's not really a focused core to start on other than Java.
Scala was a nicer Java but now Java is nicer
Scala may have started out as a "nicer Java" back when Java was in its fossilized stage, but the niche it has grown into is more like a Haskell for the JVM. A pretty cool niche, but niche. "Nicer" just isn't part of its claim anymore, hasn't been for quite some time.
Kotlin can certainly be seen as a what Scala could have been if had stayed on the "nicer Java" course, and no, Java isn't anywhere close to overtaking Kotlin in the field of unambitous but spectacularly effective niceties. Because that's what Kotlin is, from a Scala perspective: low hanging fruit language features, not powerful enough to even bother. But the Kotlin standpoint is that more powerful isn't necessarily a good thing, they judge a feature on how it improves mundane code, without changing the entire programming paradigm. Scala has long stopped trying to be a "nicer Java", they have chosen a different path. And that's not a bad thing, it just isn't for everybody.
Kotlin can certainly be seen as a what Scala could have been if had stayed on the "nicer Java" course, and no, Java isn't anywhere close to overtaking Kotlin in the field of unambitous but spectacularly effective niceties. Because that's what Kotlin is, from a Scala perspective: low hanging fruit language features, not powerful enough to even bother. But the Kotlin standpoint is that more powerful isn't necessarily a good thing, they judge a feature on how it improves mundane code, without changing the entire programming paradigm. Scala has long stopped trying to be a "nicer Java", they have chosen a different path. And that's not a bad thing, it just isn't for everybody.
This is just objectively false. The type system is weaker, the syntax more verbose. No good functional programming libraries in Java. Pattern matching, syntax sugar. The list goes on. I had to go back to Java from Scala and it's very much behind.
Java does have pattern matching, but while some programmers certainly like having more features and a stronger type system to be, there's clearly nothing objective about that preference, considering that the only languages that are as popular as Java or more these days are JavaScript and Python. Of course, no one argues that more popular necessarily means better, but since software has huge economic value (and the vast majority of software is done to further economic activity) you'd expect some correlation between "better" and "more value". Given that for decades now the market consistently prefers the languages that you consider "worse", then one of two things: either there's a huge market inefficiency that somehow no one manages to exploit, or that what you consider better is not, in fact, objective.
In short, there's no doubt different programmers have different preferences on what they consider better (though those preferences are clearly not distributed evenly), but if you want to claim that something is objectively better, it has to be better by some objective measure that is related to the actual value that people expect to gain from software. The bigger the gap between your characterisation and market behaviour, the harder it would be to support claims of objectivity.
In short, there's no doubt different programmers have different preferences on what they consider better (though those preferences are clearly not distributed evenly), but if you want to claim that something is objectively better, it has to be better by some objective measure that is related to the actual value that people expect to gain from software. The bigger the gap between your characterisation and market behaviour, the harder it would be to support claims of objectivity.
Syntax is only part of the equation. And comparing syntaxes is never "objective".
Only Windows developers should pick C# for anything, though. From my privileged point of view, that's a tiny minority.
But not sure why anyone would choose Java over Kotlin now that Kotlin exists.
But not sure why anyone would choose Java over Kotlin now that Kotlin exists.
This stopped being the case eight (8) years ago.
This what .NET is often used with today (in terms of dev, user and hosting stories):
- Linux containers with ASP.NET Core
- AvaloniaUI and Unity/Godot/Stride (all cross-platform)
- Rider (on macOS in particular)
This what .NET is often used with today (in terms of dev, user and hosting stories):
- Linux containers with ASP.NET Core
- AvaloniaUI and Unity/Godot/Stride (all cross-platform)
- Rider (on macOS in particular)
"Often" seems a strong word. I understand that it's possible, but I haven't seen many projects using C# or other CLR languages for containerized Linux app
That's the default deployment target for any new or migrated application. I'm saying often because it is not the only one.
You're very out of date then :)
Well, if these are valid arguments, I'd rather go with Swift for a more modern language.
Unfortunately, Swift is slower and has worse tooling, especially on Linux. I like it a lot as a language but it is hard to justify its usage outside of macOS when C# exists.
Related: https://news.ycombinator.com/item?id=40045524
Related: https://news.ycombinator.com/item?id=40045524
IntelliJ Community Edition. That'll give you tooling for generating boilerplate projects and handling some of the issues around build tools and project management that can be off-putting to a newcomer.
In general Java development is much more brutal and violent than Python. The VM is very performant, it's like a huge ship engine, thousands of horsepowers. When a library is lacking in some way and you're in a hurry you just crack it open with reflection and edit the parts you want. The type system has quirks and sharp edges that'll cut you in ways you don't expect in the beginning, and it's a very strong type system, you need to work with it to make things manageable, no way around it. Maven is a daunting mess, but it's also a relatively robust mess.
At first it'll feel slow to develop in, then you get the hang of code generation and figure out how to use the type system to get out of having to maintain the code and being able to make changes with confidence. At that point maintenance turns into routine tasks related to libraries and deploy environment. It's also multiplatform for real, not like C# where some things are but the goodies are MICROS~1 exclusive.
A problem is that there is so much of it, both the language itself and libraries. Some common libraries have an API surface you could study for years without feeling you're running in circles.
Start off with some well-defined, rather small projects. Connect to a database and crap out a PDF report. Install Wildfly and boot up a ping-API. Create the number guessing game as a Swing or JavaFX application. Stuff like that.
In general Java development is much more brutal and violent than Python. The VM is very performant, it's like a huge ship engine, thousands of horsepowers. When a library is lacking in some way and you're in a hurry you just crack it open with reflection and edit the parts you want. The type system has quirks and sharp edges that'll cut you in ways you don't expect in the beginning, and it's a very strong type system, you need to work with it to make things manageable, no way around it. Maven is a daunting mess, but it's also a relatively robust mess.
At first it'll feel slow to develop in, then you get the hang of code generation and figure out how to use the type system to get out of having to maintain the code and being able to make changes with confidence. At that point maintenance turns into routine tasks related to libraries and deploy environment. It's also multiplatform for real, not like C# where some things are but the goodies are MICROS~1 exclusive.
A problem is that there is so much of it, both the language itself and libraries. Some common libraries have an API surface you could study for years without feeling you're running in circles.
Start off with some well-defined, rather small projects. Connect to a database and crap out a PDF report. Install Wildfly and boot up a ping-API. Create the number guessing game as a Swing or JavaFX application. Stuff like that.
> It's also multiplatform for real, not like C# where some things are but the goodies are MICROS~1 exclusive.
That's absolutely not true. Everything except the old GUI frameworks is multiplatform and even runs better on Linux.
That's absolutely not true. Everything except the old GUI frameworks is multiplatform and even runs better on Linux.
Right, seems Blazor and some other things have now been ported.
How about the IDE?
Personally I don't trust MICROS~1 and fiercely dislike their operating systems, so I'm not exactly engrossed in the details in this area.
How about the IDE?
Personally I don't trust MICROS~1 and fiercely dislike their operating systems, so I'm not exactly engrossed in the details in this area.
Visual Studio is not open source and neither is .NET tooling for VS Code.
https://isdotnetopen.com/ explains a lot of this and has made me avoid .NET as well. Competing languages are pretty good these days and a lot more open.
https://isdotnetopen.com/ explains a lot of this and has made me avoid .NET as well. Competing languages are pretty good these days and a lot more open.
OK, that looks pretty dire, especially the corporate bullying.
Recently I tried running some .NET-stuff under Linux but it was a mess, Wine choked on stuff and even figuring out .NET versions seemed like it would have taken so much of my time that it could easily have bought a MICROS~1 machine. So we just dug out an old one for running that software instead.
I've also tried to build some applications under Linux that were supposedly supported, a year or so back, it was also messy. In my dayjob I've built stuff in Java and Racket and when I've built it on the target platform it just runs, it seems like a much nicer experience.
I'm sure the Mono folks are doing a great thing and some people say that the Steam compatibility layer is something of a miracle, but it's not like I can shove in the enterprise tools I had to use in a gaming framework. For one GDPR doesn't allow me to load the data if I did.
Recently I tried running some .NET-stuff under Linux but it was a mess, Wine choked on stuff and even figuring out .NET versions seemed like it would have taken so much of my time that it could easily have bought a MICROS~1 machine. So we just dug out an old one for running that software instead.
I've also tried to build some applications under Linux that were supposedly supported, a year or so back, it was also messy. In my dayjob I've built stuff in Java and Racket and when I've built it on the target platform it just runs, it seems like a much nicer experience.
I'm sure the Mono folks are doing a great thing and some people say that the Steam compatibility layer is something of a miracle, but it's not like I can shove in the enterprise tools I had to use in a gaming framework. For one GDPR doesn't allow me to load the data if I did.
Statements from Miguel De Icaza on .NET in the last three or so years are mostly useful if you would like to baselessly bash the technology and look for anything that can confirm your bias (nowadays he advocates for Swift which is way less FOSS).
Of course if you put a stick in the wheel it won't turn.
Engineers who are unburdened by prejudice and are up-to-date with industry advances simply do `sudo dnf install dotnet-sdk-8.0` and get on with their life while accounts like in this discussion keep posting how it is """unusable""" on Linux (it runs better, and is more portable for deployment targets (self-contained JIT and AOT) than Python or JVM).
Also, Mono (not the Unity fork one) is now just a part of https://github.com/dotnet/runtime like CoreCLR and is used for targets which CoreCLR is not suitable for or does not support yet like WASM (NativeAOT-LLVM is in the experimental stage).
Of course if you put a stick in the wheel it won't turn.
Engineers who are unburdened by prejudice and are up-to-date with industry advances simply do `sudo dnf install dotnet-sdk-8.0` and get on with their life while accounts like in this discussion keep posting how it is """unusable""" on Linux (it runs better, and is more portable for deployment targets (self-contained JIT and AOT) than Python or JVM).
Also, Mono (not the Unity fork one) is now just a part of https://github.com/dotnet/runtime like CoreCLR and is used for targets which CoreCLR is not suitable for or does not support yet like WASM (NativeAOT-LLVM is in the experimental stage).
You aren't particularly specific. I wouldn't touch Swift even if the pay was good.
Obviously you have a great deal of buy-in on this specific technology. That's fine with me.
It's not a way to get me to share the buy-in however, since I try to minimise my reliance, personally and professionally, on US:ian megacorporations. In part because I distrust them, in part because I'd be in violation of the law if my customer's data ever touched their servers.
Obviously you have a great deal of buy-in on this specific technology. That's fine with me.
It's not a way to get me to share the buy-in however, since I try to minimise my reliance, personally and professionally, on US:ian megacorporations. In part because I distrust them, in part because I'd be in violation of the law if my customer's data ever touched their servers.
I suppose you didn't read the link. It's not complaining about usability of deployed .NET apps on Linux, it's complaining about the openness of the tooling and community of the .NET ecosystem.
I'm very well aware of it. It's mostly attention-seeking bait taking Miguel de Icaza's already critical posts (the only kind shared by his twitter/mastodon persona) even further out of context.
You are not arguing this from PoV of evaluating .NET as a technology or seeking to better the software ecosystem, you just found a convenient content for the arguments of your messages. It's known, solved, not new, and people carry on using Rider and VSC as usual.
You are not arguing this from PoV of evaluating .NET as a technology or seeking to better the software ecosystem, you just found a convenient content for the arguments of your messages. It's known, solved, not new, and people carry on using Rider and VSC as usual.
> You are not arguing this from PoV of evaluating .NET as a technology or seeking to better the software ecosystem
I am evaluating .NET from exactly this perspective, and I heavily consider ecosystem openness in that evaluation.
.NET has an undeniably more closed-source ecosystem than competitors like Go or Rust or Python.
It's fine if you don't think ecosystem openness is as important as I do, that's a totally valid perspective.
I'm sorry if my post comes across as implying the way I think is "the only valid perspective" on how to choose a tech stack. My intent was just to answer the OP's question about the openness of the IDE.
I am evaluating .NET from exactly this perspective, and I heavily consider ecosystem openness in that evaluation.
.NET has an undeniably more closed-source ecosystem than competitors like Go or Rust or Python.
It's fine if you don't think ecosystem openness is as important as I do, that's a totally valid perspective.
I'm sorry if my post comes across as implying the way I think is "the only valid perspective" on how to choose a tech stack. My intent was just to answer the OP's question about the openness of the IDE.
Except the response ignores the fact that the posted links have little to do with the openness of the ecosystem. .NET does not restrict who can use which APIs nor they are designed in a way to prevent the use of "third-parties". e.g. VS and VSC debugger implementations are not the only one that exist, Rider uses its own, there is a Samsung-maintained open debugger and likely a few more specialized ones I'm unaware of. There also exists Unity which is moving over to CoreCLR, it is certain they have fully custom tooling.
There are also areas that may not be as open as they could be, which yet simply do not exist in other languages - for example Go and GUI frameworks (.NET's AvaloniaUI works well on Linux, while MAUI doesn't at all even though there seems to be now work done in that area, you can also use Gir.Core to write GTK4 applications).
Hot reload drama is uncharacteristically bad, that is true, but it's a minor feature that happens to be a convenient scapegoat repeated ad nauseam.
If anything, your comments only support my argument that C# receives criticism regardless of improvements that it gets, while Swift and Go receive undeserved good will regardless of the actions conducted by companies investing in them.
I should probably learn my lesson and stop arguing with engineers engaged in this kind of double-standards thinking repeating the same old statements that lost relevance.
There are also areas that may not be as open as they could be, which yet simply do not exist in other languages - for example Go and GUI frameworks (.NET's AvaloniaUI works well on Linux, while MAUI doesn't at all even though there seems to be now work done in that area, you can also use Gir.Core to write GTK4 applications).
Hot reload drama is uncharacteristically bad, that is true, but it's a minor feature that happens to be a convenient scapegoat repeated ad nauseam.
If anything, your comments only support my argument that C# receives criticism regardless of improvements that it gets, while Swift and Go receive undeserved good will regardless of the actions conducted by companies investing in them.
I should probably learn my lesson and stop arguing with engineers engaged in this kind of double-standards thinking repeating the same old statements that lost relevance.
I think the links are tangential to the openness.
I think most agree that the watch debacle was bad, but what I (and from what I can tell others) may see from that is that the conspiracy theories of "M$ will close it back up as soon as they can capture the users" might have more weight to it than just conjecture, and is clearly out of the hands of anyone in DevDiv. Rebuilding trust is hard, and Microsoft is going to have a hard time reaching escape-velocity from EEE if there are things like this that continue to pop up. The other links where open source projects got moved into the private GH org (and causing issues with github sponsor money going towards the OSS contributors) is also pretty bad. The other divisions aren't helping with things like ads in the Windows start menu, etc.
I'm sure there are other companies that would pull off an open-source heist if they could (I keep an eye on things like GraalVM license changes to see whenever that rug-pull might happen), but agree that because of its past, Microsoft is under a finer microscope than others and the perspective is clouded by what the rest of the company does.
This all being said, I think C# and dotnet as technologies receive quite a bit of praise on HN and other platforms whenever they come up. The threads that make it to the front page about performance improvements and such are usually 80% praise.
I think most agree that the watch debacle was bad, but what I (and from what I can tell others) may see from that is that the conspiracy theories of "M$ will close it back up as soon as they can capture the users" might have more weight to it than just conjecture, and is clearly out of the hands of anyone in DevDiv. Rebuilding trust is hard, and Microsoft is going to have a hard time reaching escape-velocity from EEE if there are things like this that continue to pop up. The other links where open source projects got moved into the private GH org (and causing issues with github sponsor money going towards the OSS contributors) is also pretty bad. The other divisions aren't helping with things like ads in the Windows start menu, etc.
I'm sure there are other companies that would pull off an open-source heist if they could (I keep an eye on things like GraalVM license changes to see whenever that rug-pull might happen), but agree that because of its past, Microsoft is under a finer microscope than others and the perspective is clouded by what the rest of the company does.
This all being said, I think C# and dotnet as technologies receive quite a bit of praise on HN and other platforms whenever they come up. The threads that make it to the front page about performance improvements and such are usually 80% praise.
I solely develop in C# on Linux, with Rider (jetbrains IDE).
What cross-platform GUI framework do you use?
Avalonia, Uno, Eto, GtkSharp...
There's also Gir.Core which is the way to get a rich abstraction in C# for using GTK4.
It is weird to me that as of the 2010s every major programming language (Python, Javascript, Java, C# and C/C++ has settled in to a regular release cadence of ... I think C++ is the conservative representative at one new version released per 3 years.
It'd be fascinating to know if this is helping or hindering programmer productivity. None of these new capabilities seem to be step changes (all the oomph for programmer productivity that I've seen have been IDE tooling, LLMs and GPUs). I'd be impressed if they even managed to be incremental changes - in this case a vector API sounds nice enough gor example but the projects that need this must be on the margins.
These changes come with costs - tutorials obsoleted, version fragmentation introduced, huge new surface areas for bugs and security problems. Most of these languages became popular without fast release cadences (or in spite of them, Python 3 looking at you). It is quite amazing that none of them have decided to leave well enough alone. Is it the classic of programmers not being able to defend that position against people with ants in their pants, or is there a genuine community will to keep revising this stuff?
Surely there has to be some popular language where the custodian would think it is good enough to set in stone bar hardware-forced updates.
It'd be fascinating to know if this is helping or hindering programmer productivity. None of these new capabilities seem to be step changes (all the oomph for programmer productivity that I've seen have been IDE tooling, LLMs and GPUs). I'd be impressed if they even managed to be incremental changes - in this case a vector API sounds nice enough gor example but the projects that need this must be on the margins.
These changes come with costs - tutorials obsoleted, version fragmentation introduced, huge new surface areas for bugs and security problems. Most of these languages became popular without fast release cadences (or in spite of them, Python 3 looking at you). It is quite amazing that none of them have decided to leave well enough alone. Is it the classic of programmers not being able to defend that position against people with ants in their pants, or is there a genuine community will to keep revising this stuff?
Surely there has to be some popular language where the custodian would think it is good enough to set in stone bar hardware-forced updates.
With Java, they are executing it pretty well these days. Old code pretty much works out of the box, so you get the improvements for free.
Some language-level improvements are significant enough to get people excited (e.g. virtual threads).
And standard library improvements are pretty low-risk as well.
Some language-level improvements are significant enough to get people excited (e.g. virtual threads).
And standard library improvements are pretty low-risk as well.
The only breaking changes I have run into are:
1) The "new" module system. (Which is, IMO, way to hard to disable for legacy code)
2) Removing some old crypto support from the default provider. And removing even mire support when a "secure valudation" flag was set. Probably for the best, but still broke stuff.
Other than that, the only Java code that really feels legacy is:
A) Pre generic collections.
B) an overuse of design patterns (normally not a language issue, although there are still a few bad APIs in the standard library)
C) Long form classes where a lambda would suffice.
Given how much the language has changed, that's a pretty impressive list. And a day with a linter can modernize most of a codebase without much effort.
1) The "new" module system. (Which is, IMO, way to hard to disable for legacy code)
2) Removing some old crypto support from the default provider. And removing even mire support when a "secure valudation" flag was set. Probably for the best, but still broke stuff.
Other than that, the only Java code that really feels legacy is:
A) Pre generic collections.
B) an overuse of design patterns (normally not a language issue, although there are still a few bad APIs in the standard library)
C) Long form classes where a lambda would suffice.
Given how much the language has changed, that's a pretty impressive list. And a day with a linter can modernize most of a codebase without much effort.
> where the custodian would think it is good enough to set in stone
While it's nice to be able to have a "complete" language, a language that receives no updates or changes is a dead language. When people use the language, are interested in making it "better" (in their mind at least), they are building community, holding discussions and overall generating interest and keeping the language alive and useful.
If you don't allow people to make any changes, then these people will lose interest and abandon the project, and slowly over time it will die.
There are some exceptions, like C that are so embedded in everything that it doesn't matter (it still gets updates sometimes), but languages like python or java or ruby where there is no clear "best" have to be competing with one another for people to choose that language
While it's nice to be able to have a "complete" language, a language that receives no updates or changes is a dead language. When people use the language, are interested in making it "better" (in their mind at least), they are building community, holding discussions and overall generating interest and keeping the language alive and useful.
If you don't allow people to make any changes, then these people will lose interest and abandon the project, and slowly over time it will die.
There are some exceptions, like C that are so embedded in everything that it doesn't matter (it still gets updates sometimes), but languages like python or java or ruby where there is no clear "best" have to be competing with one another for people to choose that language
Has the buzz for Java ever come from Hot New Features? As I recall that buzz was 80% marketing budget from Sun then Oracle, the stability of the platform and the ready availability of programmers.
If anyone ever picked Java for its features, their judgement should be questioned. The thinking might well withstand that questioning, but it isn't an obvious choice on the basis of features. I mean, Java itself is an obvious choice - but not because of its features. You can show me languages with much better feature-sets and I'll nod, agree then recommend Java for production use. The features just aren't the selling point.
If anyone ever picked Java for its features, their judgement should be questioned. The thinking might well withstand that questioning, but it isn't an obvious choice on the basis of features. I mean, Java itself is an obvious choice - but not because of its features. You can show me languages with much better feature-sets and I'll nod, agree then recommend Java for production use. The features just aren't the selling point.
Java was in real danger in the seven years that it took to go from 5 to 7. Very little of substance was added and it didn't appear like there was a path forward to get any real new features added to the language.
Yes, Java is not the language to use if you want the hot new PL ideas in your language. But languages need to continue to move forward because it's not like PL research is dead either.
I think Java does a really good job now at being conservative with what they add while still keeping things modern enough that people aren't abandoning the language. Once features have proved themselves in other, less conservative languages, the Java team can add them, with the benefit of seeing what sorts of problems might arise.
Yes, Java is not the language to use if you want the hot new PL ideas in your language. But languages need to continue to move forward because it's not like PL research is dead either.
I think Java does a really good job now at being conservative with what they add while still keeping things modern enough that people aren't abandoning the language. Once features have proved themselves in other, less conservative languages, the Java team can add them, with the benefit of seeing what sorts of problems might arise.
No, but new features have staved off competitors from taking over Java's buzz. If Java still had the feature set of Java 8, it would have lost a lot more market share to other JVM languages like Kotlin, Scala, Groovy, Clojure, etc.
Common Lisp hasn't seen any language updates since 1994 and yet people here keep talking about it.
The standard hasn't been updated. But progress happens in implementations and libraries.
Sustained standardization mostly harms/ruins programming languages.
That said, it would be good to see a Common Lisp standard which cleans up outstanding issues (like whether, when an exit point for a dynamic control transfer is chosen, are the inner exit points below it torn down before the transfer takes place, or tear-down-as-you-go?)
And also standardize some common practices.
A standard way to include special characters in strings would be nice. The C-like escapes perhaps: \n newline, \u123F for unicode and whatever.
That said, it would be good to see a Common Lisp standard which cleans up outstanding issues (like whether, when an exit point for a dynamic control transfer is chosen, are the inner exit points below it torn down before the transfer takes place, or tear-down-as-you-go?)
And also standardize some common practices.
A standard way to include special characters in strings would be nice. The C-like escapes perhaps: \n newline, \u123F for unicode and whatever.
I totally agree.
Common Lisp is mostly an esoteric hacker's toy (unpopular statement here) and it falls into a unique niche that isn't used by many
Until recently Java always seemed conservative. That's not "fun" or very interesting for a programmer, but it does offer some certainty. Java 8 bucked the trend with some major but highly useful additions, and ever since it seems like it has been going down the C++ path of accreting everything under the sun.
Java has always been conservative about maintaining backwards compatibility and introducing new keywords, but the java.* and javax.* packages have been growing larger and larger since day one.
I do think Go and Kotlin have kicked the Java community into high gear, though. A lot of the recent (or upcoming) features are direct answers to features found in those languages.
I do think Go and Kotlin have kicked the Java community into high gear, though. A lot of the recent (or upcoming) features are direct answers to features found in those languages.
A bigger standard library is one thing, but new classes and methods are easier to get accustomed to than additions to the core language spec with features like type inference or pattern matching.
I think Kotlin especially is responsible for this change. All that effort almost feels pointless now that Java has kinda stolen its USP.
I think Kotlin especially is responsible for this change. All that effort almost feels pointless now that Java has kinda stolen its USP.
> accreting everything under the sun
Maybe you're thinking about Scala? What I see is that Java is conservatively incorporating the established, proven good parts of other languages. The changes have been great - if perhaps a bit late, but that's by design.
Maybe you're thinking about Scala? What I see is that Java is conservatively incorporating the established, proven good parts of other languages. The changes have been great - if perhaps a bit late, but that's by design.
> These include statements before super(…), which would give developers greater freedom in expressing constructor behavior – meaning string templates. This would make it easy to express strings that include values computed at run time – meaning scoped values. This would enable sharing of immutable data within and across threads; and implicitly declared classes and instance main methods.
I don't like the restriction on code before super. But I don't have a clue what they are referring to here. The code example doesn't use a template either.
I don't like the restriction on code before super. But I don't have a clue what they are referring to here. The code example doesn't use a template either.
PositiveBigInteger(long value) {
if (value <= 0)
new IllegalArgumentException("non-positive value");
super(value);
}Once you call super, you invoke the base constructor. This can cause issues beca not all fields in the sub class has been set yet. Setting the fields before calling super prevents this issue.
Trivial method calls such as „toString“ can already cause issues and it’s worse once you want to guarantee certain value types properties.
Trivial method calls such as „toString“ can already cause issues and it’s worse once you want to guarantee certain value types properties.
The intention for "nothing before super" is clear, but that rule never delivered on its promises. Because all those footguns are still in place, in field initializers as well as in function calls inside the super() argument list:
class Sub extends Super {
int field = footgunA();
Sub() {
super(footgunB());
}
}
As far as I know `footGunA` can only be a static method and cannot leak `this`.
This is perfectly fine as far as I'm concerned.
This is perfectly fine as far as I'm concerned.
I should have checked instead of replying from memory: It's actually footgunB that is refused by the compiler. footgunA is accepted and will even call happily into an overridden implementation from a field initializer in the superclass. That way you can get a method to see a final field null on one call and non-null on the next.
That paragraph appears to be plagiarized from an Infoworld article [0] but with nonsensical changes to the punctuation (e.g. some of its semicolons changed to "– meaning"), which is why it makes no sense.
[0] https://www.infoworld.com/article/3714933/jdk-23-the-new-fea...
[0] https://www.infoworld.com/article/3714933/jdk-23-the-new-fea...
I agree that the wording of that was really weird. String templates aren't really the first thing that comes to mind when thinking of "freedom in expressing constructor behaviour".
Idk why you got downvoted. Clearly this feature is not about "string templates" -- it's very generic.
Is there any estimate on the % of code running on the JVM that was Java code?
Kotlin, Clojure, Scala, Groovy, Jython, JRuby to name a few.
Then: this announcement is only about new features in Java-the-language right?
Projects like Loom, Panama, Amber, Valhalla are then the JVM projects iirc.
Kotlin, Clojure, Scala, Groovy, Jython, JRuby to name a few.
Then: this announcement is only about new features in Java-the-language right?
Projects like Loom, Panama, Amber, Valhalla are then the JVM projects iirc.
Contrary to what vocal Kotlin advocates might believe, Kotlin only matters on Android, and that is thanks to Google pushing it no matter what.
https://spectrum.ieee.org/the-top-programming-languages-2023
https://snyk.io/reports/jvm-ecosystem-report-2021/
And even so, they had to conceed Android and Kotlin on their own, without the Java ecosystem aren't really much useful, thus ART is now updatable via Play Store, and currently supports OpenJDK 17 LTS on Android 12 and later devices.
As for your question regarding numbers, mostly Java 74.6%, C++ 13.7%, on the OpenJDK, other JVM implementations differ, e.g. GraalVM is mostly Java 91.8%, C 3.6%.
https://github.com/openjdk/jdk
https://github.com/oracle/graal
Two examples from many others, https://en.wikipedia.org/wiki/List_of_Java_virtual_machines
https://spectrum.ieee.org/the-top-programming-languages-2023
https://snyk.io/reports/jvm-ecosystem-report-2021/
And even so, they had to conceed Android and Kotlin on their own, without the Java ecosystem aren't really much useful, thus ART is now updatable via Play Store, and currently supports OpenJDK 17 LTS on Android 12 and later devices.
As for your question regarding numbers, mostly Java 74.6%, C++ 13.7%, on the OpenJDK, other JVM implementations differ, e.g. GraalVM is mostly Java 91.8%, C 3.6%.
https://github.com/openjdk/jdk
https://github.com/oracle/graal
Two examples from many others, https://en.wikipedia.org/wiki/List_of_Java_virtual_machines
Any reason Kotlin is not being adopted outside android? I haven't used Java for like a decade - is it that Java improved well enough to kotlin not being competitive anymore? E.g. Spring Boot seems to have kotlin support. Kotlin 2.0 compiler seems also around the corner, same with jetbrains-compose.
I think the Jetbrains team are dropping the ball when it comes to Kotlin on the JVM. They seem to be focusing their energy on KMP, and I’m not sure they have the capacity to deal with all the platforms they want to target (Kotlin/JS, Kotlin/Native, Kotlin/JVM, KMP, Jetpack Compose (?) etc). That being said, I’d strongly encourage others to try Kotlin as a Java alternative for server-side applications (Spring Boot integration is really nice, for instance). It’s such a delight to use! And it’s still my favorite language. Some features I especially like:
- context receivers (think of them as implicit parameters that are checked at compile-time)
- null safety. This is a BIG one, especially if you’re coming from Java.
- structured concurrency. Java still doesn’t have this. Note that SC is different from what was introduced in Project Loom.
- immutable variables, data classes, value classes etc.
- context receivers (think of them as implicit parameters that are checked at compile-time)
- null safety. This is a BIG one, especially if you’re coming from Java.
- structured concurrency. Java still doesn’t have this. Note that SC is different from what was introduced in Project Loom.
- immutable variables, data classes, value classes etc.
Kotlin is growing in usage. Not as fast on backend obviously because Java is still perfectly serviceable but it's still definitely growing.
The area Kotlin excels in isn't as a pure Java replacement to be used by Java devs but rather a JVM language palatable to the Python/Javascript/Ruby/Golang crowd. It's very very hard to convince such people that they should even try Java but Kotlin is much easier to at least get them to try and show them it's really not hard at all.
The area Kotlin excels in isn't as a pure Java replacement to be used by Java devs but rather a JVM language palatable to the Python/Javascript/Ruby/Golang crowd. It's very very hard to convince such people that they should even try Java but Kotlin is much easier to at least get them to try and show them it's really not hard at all.
The Python/Javascript/Ruby crowd has JVM implementations to look for.
Had.
One of the most egregious destructions of great value in the modern world wasn't the collapse of the Key Bridge or the destruction of the library of Alexandria -- it was when Jython, a wonderful implementation of Python2 on the JVM, died because it was too much effort to upgrade it to support Python3. So much value and capital, destroyed because of the damn 2to3 fiasco. ALL FOR WHAT? For goddamned PRINT STATEMENTS?
Now all the libraries have moved on, so Jython is not so useful -- you can do toystuff but you can't import any serious modern python library anymore, which you could a decade ago! And you got real multithreading with no GIL to worry about it! It was ahead of the real CPython2!
It was more than just a way to integrate and glue together Java and Python code -- it was actually a viable alternative Python runtime. It's a big reason I've never forgiven or started retrusting the python community after the 2to3 fiasco. It just shows it's not a serious language like java that actually cares about backwards compatibility and is able to advance anyway.
Hey, what ever happened to Groovy? It was like Scala/Kotlin but without taking itself seriously at all, much more akin to perl than to C++.
One of the most egregious destructions of great value in the modern world wasn't the collapse of the Key Bridge or the destruction of the library of Alexandria -- it was when Jython, a wonderful implementation of Python2 on the JVM, died because it was too much effort to upgrade it to support Python3. So much value and capital, destroyed because of the damn 2to3 fiasco. ALL FOR WHAT? For goddamned PRINT STATEMENTS?
Now all the libraries have moved on, so Jython is not so useful -- you can do toystuff but you can't import any serious modern python library anymore, which you could a decade ago! And you got real multithreading with no GIL to worry about it! It was ahead of the real CPython2!
It was more than just a way to integrate and glue together Java and Python code -- it was actually a viable alternative Python runtime. It's a big reason I've never forgiven or started retrusting the python community after the 2to3 fiasco. It just shows it's not a serious language like java that actually cares about backwards compatibility and is able to advance anyway.
Hey, what ever happened to Groovy? It was like Scala/Kotlin but without taking itself seriously at all, much more akin to perl than to C++.
Did Jython even ever supported all non pure python libraries? The biggest moat of cpython is huge ecosystem of native libraries such as numpy, scipy, scikit, pillow, pandas, opencv, pytorch, tensorflow etc. This is the reason why PyPy is not mainstream. Without all those libraries and ecosystem around it python wouldn't be that useful and for the same reason Jython wouldn't be that useful even if supporting python3 and having the fastest JVM.
Groovy is still around in projects that haven't yet moved their gradle configs to Kotlin (which includes a declarative syntax basically identical to Groovy builders). Purely dynamic-typed languages are a hard sell these days, especially when they're as pokey and memory-hungry as Groovy.
Check out GraalPy! It’s like Jython but it’s on Python 3 and supported by Oracle. My company is still using Jython, but we’re finally tearing out our Jython implementation and replacing it with GraalPy since it’s much more performant and it’s going to stay up to date with Python development.
Whaaaa? I will definitely check it out next time I have a use case. Thanks. How compatible is it?
There is a compatibilty chart:
https://www.graalvm.org/python/compatibility/
It can even run some C-wrapper python libs, as it can run LLVM code.
I switched back recently (from Kotlin to Java). I'm not 100% happy with the switch. Despite new Java features, it comes nowhere near providing Kotlin's terseness. But a few of the reasons that made me try this switch include being uncomfortable with the closed and proprietary nature of the Kotlin's evolution and that the only IDE support available is via a product owned by the same company. I know Oracle "owns" Java but it feels different - they have no incentive to limit the marketplace for developer tools and IDEs.
I also prefer a smaller languages - and I feel earlier versions of Kotlin were beautifully balanced in this regard with a small(ish) number of powerful and orthogonal improvements over Java. The language has grown significantly since then at a far faster rate than Java - maybe approaching C# velocity.
Finally, and I realise that a lot of effort has gone into addressing the issue in recent releases but compile times were much worse for me than equivalent Java.
I also prefer a smaller languages - and I feel earlier versions of Kotlin were beautifully balanced in this regard with a small(ish) number of powerful and orthogonal improvements over Java. The language has grown significantly since then at a far faster rate than Java - maybe approaching C# velocity.
Finally, and I realise that a lot of effort has gone into addressing the issue in recent releases but compile times were much worse for me than equivalent Java.
First of all, I think many projects just waited before dipping their toes in kotlin.
Now that java itself is adding many functionalities inspired from other languages, it's much less appealing.
I saw some backend projects at $company, and after 2 or 3 years, the decision was made to only use java on new files, and convert kotlin files to java when they are touched. Why? The kotlin compiler was so much slower that it was noticeable, while javac is still very fast. Another reason is available talent not related to Android. Lastly, its value proposition wasn't high enough to justify a different language, especially with java 17 and later.
That being said, even quarkus provides kotlin apis nowadays, so it's not like it doesn't happen.
Now that java itself is adding many functionalities inspired from other languages, it's much less appealing.
I saw some backend projects at $company, and after 2 or 3 years, the decision was made to only use java on new files, and convert kotlin files to java when they are touched. Why? The kotlin compiler was so much slower that it was noticeable, while javac is still very fast. Another reason is available talent not related to Android. Lastly, its value proposition wasn't high enough to justify a different language, especially with java 17 and later.
That being said, even quarkus provides kotlin apis nowadays, so it's not like it doesn't happen.
When I was a consultant, what I saw was that almost all new code in java codebases at multiple projects/clients was entirely Kotlin. No idea what the person you're replying to is on about.
This is also the case at my (large) company. We have a lot of Java code around, but anything new is Kotlin. The teams pretty universally strongly prefer it.
Congratulations, you are part of the 18% Kotlin on JVM and 10% language relevance numbers from the reports I shared.
Being one in six java developers isn't worthy of a congratulations I think, but thanks anyways. But it does show how wrong your statement was about Kotlin only being an Android thing.
It is, because most teams using Kotlin on JVM are Android shops writing server side code.
There are other reports to dive into.
There are other reports to dive into.
I disagree. I've never been in an "Android shop", and still seen plenty of Kotlin code (all the places I mentioned mainly had React Native apps). You have some preconceptions that probably aren't correct, and try to make all reports fit that narrative. Just accept that lots of people use Kotlin without having anything to do with Android.
Like all guest languages on the JVM, its domain outside godfathers' mobile Kingdom won't move the needle to rewrite the Java ecosystem.
[deleted]
18% is way too large to just dismiss it as "irrelevant"
Java pulls in the best language features from kotlin and scala, which reduces the edge of using those languages
This is an overly simplistic take.
Java hasn't taken that much from Kotlin really, sometimes even gone in a completely opposite direction (for instance with Loom).
Java has taken a few things from Scala but I would hardly call them the best features. Java will never adopt what truly makes Scala stand out, on purpose.
Java hasn't taken that much from Kotlin really, sometimes even gone in a completely opposite direction (for instance with Loom).
Java has taken a few things from Scala but I would hardly call them the best features. Java will never adopt what truly makes Scala stand out, on purpose.
While java has evolved a lot, I still find it hard to go back. The stream syntax and similar things will never match how easy it is to do proper functional programming in Kotlin. I do miss real pattern matching, though.
Kotlin has stagnated for the last few years (!) due to JB dropping everything to rewrite the entire compiler (twice).
In the meantime, Java took a lot of the good features and made them even better, e.g. Java has actual pattern matching and Kotlin doesn't.
In the meantime, Java took a lot of the good features and made them even better, e.g. Java has actual pattern matching and Kotlin doesn't.
Compilation is slow as balls and there's only 1 viable ide. You're going to have to spend extra time onboarding Java developers and it just doesnt add enough to be worth it
Simply inertia. Java is what people know and hire for unfortunately.
Java is good enough and Kotlin does not add anything substantial worth of switching.
Google provides first-class support for Kotlin. Oracle does not. Kotlin does not evolve with JVM. For example they introduced coroutines to imitate blocking code and few years later Java decided to create green threads, making the feature essentially obsolete.
Kotlin made sense in Java 1.7 time, when Java seemed to be stale and kind of dead. Things changed since then.
Google provides first-class support for Kotlin. Oracle does not. Kotlin does not evolve with JVM. For example they introduced coroutines to imitate blocking code and few years later Java decided to create green threads, making the feature essentially obsolete.
Kotlin made sense in Java 1.7 time, when Java seemed to be stale and kind of dead. Things changed since then.
Kotlin is amazing on the backend. Lot's of successful startups do it. Larger shops are adopting it. SpringBoot is (albeit not as big as Google) also fully on the Kotlin bandwagon. Ktor is there for the purists.
> that is thanks to Google pushing it no matter what.
No, it's because Android is stuck on Java 8, so if you want any language progress you need to look further to something that can run on top of it.
No, it's because Android is stuck on Java 8, so if you want any language progress you need to look further to something that can run on top of it.
This announcement is a mixture of JVM improvements (Vector API) and Java improvements (other stuff).
What is the best way to get up to speed with modern Java? My background is having taught myself a very long time ago with Ivor Horton’s books but zero professional experience with the language.
Core Java by Cay Horstmann (https://horstmann.com/corejava/) is a well-structured and concise review of major features. Historically, the most interesting chapters were scattered across both volumes. So completely skipping the "Fundamentals" volume was ill-advised while the "Advanced Features" volume had some boring and mostly unnecessary chapters.
I'm very disappointed by the non-announcement that the String Templates preview feature is being completely removed.
Third Preview https://openjdk.org/jeps/465 was last updated at 2024/03/21 17:42
Are you sure they completely removed it or you meant something else?
Are you sure they completely removed it or you meant something else?
Yes they did, because the feedback was mostly negative, so it is back to the drawing board.
https://mail.openjdk.org/pipermail/amber-spec-experts/2024-M...
https://mail.openjdk.org/pipermail/amber-spec-experts/2024-M...
Completely gutted from the OpenJDK, last I checked. See here for the culprit PR: https://github.com/openjdk/jdk/pull/18688
Is it? Last I checked (https://openjdk.org/jeps/465) it was being proposed for finalisation. Where did you read it's being removed instead?
See my reply to the sibling comment by stefanos82.
They completely rehauling this feature. It won't be finalized in the current state.
Ok interesting, where I can I read about why they decided to back it out after 2nd preview?
They found a better/simpler abstraction.
Here is the mailing list (I link to the reddit thread, because there are some useful comments): https://www.reddit.com/r/java/comments/1ba0brh/update_on_str...
Here is the mailing list (I link to the reddit thread, because there are some useful comments): https://www.reddit.com/r/java/comments/1ba0brh/update_on_str...
Thanks!
It is removed in Java 23 but hopefully will be back in Java 24 once they finalize the ergonomics around template processing.
Java doesn't have enough features?
A bunch of these "features" are removing existing arbitrary restrictions in the language. Some of the features are JVM improvements not tied to Java.
It has fairly few features compared to most of its peers and has always been very conservative in adding more.
It has too many of the wrong features and not enough of the right features. This is the problem with bolting stuff onto old languages - a lack of cohesiveness.
At which point does a language have enough features? Does any language have?
It really depends on your preferences and what you're trying to do. I would say most languages do have enough features for most usages, to be honest. In the rare occasion the language does not, why not learn another language that fits your needs better? I know maybe 5 or 6 languages well enough to know their pros and cons and between them, I normally know exactly which language I would use depending on the objective, sometimes it may even be Java, but it could be any of the other 5 as they all have slightly different advantages.
It really depends on your preferences and what you're trying to do. I would say most languages do have enough features for most usages, to be honest. In the rare occasion the language does not, why not learn another language that fits your needs better? I know maybe 5 or 6 languages well enough to know their pros and cons and between them, I normally know exactly which language I would use depending on the objective, sometimes it may even be Java, but it could be any of the other 5 as they all have slightly different advantages.
There is always Go for those that don't like features.
Arguably, it doesn't. New features can be necessary to stay competitive, such as the Vector API to utilize vector instructions.
Really enjoyed reading the comments. Seems like few people see programming language features as basis vectors of the solution vector space. The more features you add the more cognitively complicated the search for the solution in this space is. It's not "just +1 feature", it's "+1 dimension" essentially.
Unsurprisingly, you will find people who argue even Lambdas went to far, and others who are willing to endure Lombok, multiple annotation processors, or precompilers to work with more advanced features.
Java is a surprisingly small language
At long last!