Java 23: The New Features Are Officially Announced
coderoasis.com
coderoasis.com
At long last!
I haven't checked if this one is correct.
> 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.
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...
I'm digging this steady progress.
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.
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. "
CoreLib and many new libraries are using it heavily to match performance of manually intrinsified C++ code.
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#
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?)
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.
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
I just know I need to branch out. I’m decent at Python and SQL but I could learn some more.
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.
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.
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.
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.
But not sure why anyone would choose Java over Kotlin now that Kotlin exists.
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)
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.
That's absolutely not true. Everything except the old GUI frameworks is multiplatform and even runs better on Linux.
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.
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.
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.
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).
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.
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.
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.
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 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.
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.
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.
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.
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
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.
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.
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 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 think Kotlin especially is responsible for this change. All that effort almost feels pointless now that Java has kinda stolen its USP.
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.
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);
}Trivial method calls such as „toString“ can already cause issues and it’s worse once you want to guarantee certain value types properties.
class Sub extends Super {
int field = footgunA();
Sub() {
super(footgunB());
}
}
This is perfectly fine as far as I'm concerned.
[0] https://www.infoworld.com/article/3714933/jdk-23-the-new-fea...
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.
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
- 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.
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.
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++.
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.
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.
There are other reports to dive into.
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.
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.
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.
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.
Are you sure they completely removed it or you meant something else?
https://mail.openjdk.org/pipermail/amber-spec-experts/2024-M...
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...
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.