Earlier quoted context omitted.
Fair, although even there I don't know if I'd call that "lots" at just 23 added or modified methods that aren't in preview
There are also bug-fixes and performance improvements that are not going to show on the page I linked. I do think it’s plausible this is a smaller release. Not that this was the real point of the discussion, but I think it’s still just a good idea to have more than one release a year. It keeps things moving smoothly, and lowers the cost of missing a release, which has beneficial effects.
Java 27
151–160 of 427 posts
Re: Java 27
#152Earlier quoted context omitted.
They lack in performance, stability (compatibility), observability (telemetry), productivity, or some combination thereof. They are chosen, of course (especially C#; Go and Rust are far behind), but not as much as Java.
I don't agree. If anything these newer languages have better tooling and new projects are always built from ground up to support open standards like open telemetry
Re: Java 27
#153Earlier quoted context omitted.
They lack in performance, stability (compatibility), observability (telemetry), productivity, or some combination thereof. They are chosen, of course (especially C#; Go and Rust are far behind), but not as much as Java.
Saying that Go lacks in those is just showing how people are making software those days. It’s just terrifying. As to Rust - we all, hopefully, agree that it’s great language, but not for some startup making websites or Mongo based, boring backends. It’s great for the stable, system level products.
Re: Java 27
#154Earlier quoted context omitted.
They lack in performance, stability (compatibility), observability (telemetry), productivity, or some combination thereof. They are chosen, of course (especially C#; Go and Rust are far behind), but not as much as Java.
I think you have a biased view. The number of stuff written in Rust in the last couple of years has absolutely exploded. For example, I see a lot of projects now that provide SDKs in Rust but don’t bother with Java. And I say this as someone who still writes most of my code ( or tell my LLM to write) in Java.
Doesn't bother to disclose it of course, because what, you don't check everyone's profile in every discussion to make sure they're not biased? What, you don't just know who every user on this site works for? You dummy you :)
Re: Java 27
#155Earlier quoted context omitted.
It’s still missing null safety, right? Which means it’s still a hard no for me.
It is really not a big deal nowadays, the problem of the same scale as having index out of bounds error (no language has good defence against this, yet it is not a catastrophe).
Re: Java 27
#156Earlier quoted context omitted.
I think you have a biased view. The number of stuff written in Rust in the last couple of years has absolutely exploded. For example, I see a lot of projects now that provide SDKs in Rust but don’t bother with Java. And I say this as someone who still writes most of my code ( or tell my LLM to write) in Java.
Yeah I mean he literally works on Java at Oracle, so may just be a little biased. Doesn't bother to disclose it of course, because what, you don't check everyone's profile in every discussion to make sure they're not biased? What, you don't just know who every user on this site works for? You dummy you :)
Re: Java 27
#157Earlier quoted context omitted.
Nullability annotations + tooling makes this a non-issue in practice.
I’m not sure how long it will take, but please - can we stop saying that annotations like @IHopeThisWontBeNull is a toy for kids and, having so many years of incidents caused by those and having LLMs to write and fix the code, we can rely on language and compiler already?
I get that some people feel like it ought to be built-in to the language rather than a separate tool... but people's personal feelings are irrelevant to the lived experience of my day-to-day work, where worrying about null is truly a thing of the past.
Re: Java 27
#158Serious question: when should one use Java for greenfield projects in 2026?
JavaFX is fairly high up for "I want to run the same UI on Mac and Windows, and I don't want it to be an Electron web app in a box".
It's not as portable as Swing, as it has some platform specific binary components to it. But it works fine on mainstream platforms. For me Swing portability is not worth giving up the FX model.
Just be aware that if you happen to bundle in the Web view component, you're basically adding WebKit to your distribution. I did this with a small project because I wanted to have a "help" screen with Markdown -> HTML. Easy, but "expensive". It simply adds a big chunk (10-20Mb) to your distribution.
(Now I have a very crude Markdown renderer for this task, which is a 100 lines code, and I'm working on a better one -- but I have yet to pull the trigger on the latest FX with its new Rich Text component, which could change everything.)
One hot tip with cross platform FX, however. Embed your fonts. The font suite is not common across the distributions, and the CSS does not honor the font fall back (i.e. if not XXX font, then YYY font), so if the runtime doesn't have your specific font, it collapses to the System font. So, embedding the fonts you use helps a lot with cross platform stability. Plenty of free fonts, I have not had a real problem with this. But it can be one of those O.o moments when you test on other platforms and encounter it the first time.
Re: Java 27
#159Re: Java 27
#160Earlier quoted context omitted.
Go and Rust have much worse tooling for enterprise-level collaboration
Do they? It felt like every dev that worked on our Java behemoth at a previous job was elated to switch to Go.