I've been using the Vector APIs for years now, and I'm still waiting for them to GA!

They are useful for neural information retrieval (RAG, memory), which relies heavily on content vectorization and similarity matching using their dot products.

And still funny today, not all jokes survive that long.

Why do they want the jokes back?

The long pause between the knock and the answer took 30 years

You misunderstand, xxx360NoScopexxx is now the default.

News at 11.

Language that runs on the explicit design philosophy of letting other languages experiment first and then incorporating their lessons learned once the dust has settled is late to implement a feature.

I never cared about those kind of syntax sugars. I was happy with IDE/static checkers, lombok, mapstruct, etc.

I missed generators like that virtual threading for example.

btw: i was referring a single point when oracle bought sun and "closed java".

This thing is a-ma-zing. It is truly a wonder. It is something to behold. The "Disruptor" pattern.-

Agentically convert to rust, get more trades faster

the long pause is the JVM starting up

Don't put a 30gb heap on m4 boxes and you'll be okay

If I'm not mistaken, OpenJ9 runtime offers some kind of precompilation and fast startup.

We often use the latest version of Java at my work place. We haven't had any issues with upgrading, so there's no benefit of waiting for an LTS. There's no big process behind it either. The developers just quietly change the version as part of keeping the project up to date (BAU)

It may be that we are shielded from edge cases because we are based on Spring, which is probably the most tested piece of software before new versions of Java are released. But it's my impression that the risk of upgrading to a new version of Java is not the same today as it was in the past. The only advantage of an LTS is that it is supported longer, so that you can postpone the upgrade if you really want. It's not as if the intermediate releases are inferior or less safe.

At my last job, we only used LTS in production. Upgrading Java was always a long process, but that's more due a legacy monolithic app across thousands of servers.

You can almost think of the LTS releases as a major release and the non-LTS as a minor release, so really this could be 25.2. The current Java release schedule is to maintain a consistent and predictable release cadence instead of pushing big new features every 6 months.

To misquote Bart Simpson:

Let me get this straight: we're behind the [other languages] and we're going to catch up to them by going slower than they are?

Gotta go faster if you ever wanna catch up. However, Java is also purposefully slow. Everything is extremely considered. And while it means it takes a while before you get a feature it tends to be pretty good.

Typeclasses caught me by surprise. Smart move by the java team.

Granted, I havent' used either for a couple of years, so my knowledge is a little rusty. Yes, some of them are "just syntax sugar", but man oh man does it make C# such a pleasant language to work with.

Used to work at a company which had services both in Java and C#, so some of Java's decisions or indecisions felt like pain points when switching between the two:

- Proper IEnumerable with proper iterators that in turn enables Linq (but in general permeates everything and is insanely easy to use and build upon). E.g. building an async service that behaves like an IEnumerable? Implement two methods.

Collection is halfway there, but I honestly cannot remember what was irking me about it in comparison to C#.

- Properties. Yeah, yeah, sealed classes, records and all that. Often you still need plain old classes.

- object initialisers. Which makes constructing anything a breeze. And on top of that you don't need manual .of methods for anything Colleciton-like if it'sa an IEnumerable.

- extension methods.

- named and optional arguments in functions

- null coalescing operator

- generics over primitive types (unless it was already implemented, I remember seeing a JEP about it)

- async/await. Yes, I know: different approaches to concurrency and all that. A lot of unnecessary verbiage could still probably be hidden behind a friendlier syntax.

- (sadly impossible in JVM to type erasure, only including this because I remember needing it many moons ago) generics metadata in runtime

- .... definitely a bunch more I don't remember at this point ...

I don't think modern Java is a 'move fast ~and break things~' environment. It's a comparatively stable platform with an enviable focus on backwards compatibility. The maintainers have talked about "last mover's advantage" when it comes to introducing new language features. Java has a checkered history when it comes to novel programming language features, so I think this is good.

Granted, the maintainers are more inclined to deprecate and remove parts of the API than has historically been the case but it is mostly obsolete things like applets. And you may need to keep a close eye on runtime flags and their effects.

Move fast and break things does not describe Java well at all.

Their process is still very deliberate, they go to some lengths to avoid getting it wrong when they add new features to the standard. New features have to get through their preview phase successfully before becoming final. [0]

They're also pretty committed to not breaking existing source code or bytecode.

[0] https://openjdk.org/jeps/12 JEP 12: Preview Features

I started programming when Java 6 was relatively new. Back then it was about 3-4 years in between releases. Although I don’t write much Java any more, I’m happy to see changes shipping more frequently now.

Graal is based on OpenJDK. OpenJ9 while using a separate JVM and JIT leverage the openjdk class path as well as the build environment and various other things.

I don’t think there’s a single alternate implementation that doesn’t leverage a good chunk of openjdk somehow

Right. There's a "Java SE" (platorm spec) version, and a JDK version that corresponds to it, but not everything in the JDK affects or is dictated by the spec.

BTW, Java is developed "code first", which means that we first work on the implementation in OpenJDK, and then extract the relevant spec changes from it.

But that is still somehow a "feature" of the Java 27 release according to Oracle.

It's a feature of the OpenJDK JDK, which is, indeed, the Java implementation done by Oracle (with contributions from others). The language is very careful, as you can see in the announcement: "JDK 27, the reference implementation of Java 27". The Java SE 27 spec is here: https://www.jcp.org/en/jsr/detail?id=402

One of the more prolific opensource projects, but apart from the JEP process not very open access (which is a fair choice the contributor('s employer) can make).

I'd read it.

I didn't read the parent comment as being particularly positive in their description; it didn't sound like it was being stated as a good thing to me.

Mads Torgersen's previews and such are enjoyable and upbeat, for example.

10 years ago I was working at a place that was building Python systems that had dependency graphs too complicated for pip to handle. I was able to solve the problem for my system with a "wheelhouse" system that could compute a list of wheels that could be installed to build it but the confidence of my team in Python had flagged.

I had a sheaf of notes about the problem and figured out the math to build a proper dependency resolver for Python and tested out a lot of ideas such as being able to use http range requests to get the metadata out of wheels on PyPi without having to download the whole wheel.

The problem I had no solution for though was "how to stop developers from trashing the environment that the dependency manager runs in." The data scientists I worked with had an astonishing target for wrecking anything at all. Myself I would have my poetry's environment got bad for reasons I didn't understand every few months ago.

I also found the Python community just didn't care that pip didn't really work right. The most seductive form of blub is "I can accept using things that fail intermittently." I got a job coding Java and Javascript and never built the package manager.

Then uv came along and managed to sell itself as "crazy fast" which did connect with people more than "correct". Written in rust, uv would have beaten my system in the fast department, and since it is a binary, there is no way anyone can screw up a Python it depends on -- as I see it, both technical and marketing genius!

Generally fairly painless in recent years, you need to divide the .NET timeline into original timeline ( .NET 1.0 -> Framework 4.8 ) and "core" lineage/timeline.

The Core (smaller, but also properly crossplatform) project begun in 2014, fairly major rewrites with breaking changes in the new releases up until 2019 (.NET Core 3.1) and 2020 (the 5.0 release that became the official major "unification" with most parts of Framework having newer alternatives and being "complete" even if 6.0 and 7.0 patched holes).

Projects started with core 3.0/3.1 in 2019 have a pretty easy and clear upgrade path without major breaking changes up until today.

It's not JS/Node volatility, and the cleanups in the language/runtime were well worth it in hindsight (still maintaining old 4.8 applications running under IIS), also 4.8 is still nominally supported so there's no immediate stress in upgrading (There are better semantics today, but with huge projects those semantic differences, mainly no lazy-loading by default are a risk).

Yep. Anything else is probably in Apache Commons somewhere.

Sometimes the thing built into the .NET platform is great, sometime it is just crap but developers will use it anyway and it sets back the ecosystem.

There is this division of labor between systems programmers and application programmers and often we think systems programmers are better because they know more about algorithms and data structures and compilers and assembly language and such. On the other hand, application developers understand how to reconcile the mental model of managers and employees and customers with computers, reality and common sense and, once they get experienced, see the commonalities between all the run-of-the-mill bizapps that we are coding all the time.

Application programmers do a lot better at applications framework than systems programmers and make things like Ruby on Rails and Spring. Systems programmers make terrible things like ASP.NET MVC (I worked out a way to do MVC with ordinary ASP.NET, why couldn't they, with access to the platform internals?)

If you go with the wrong one you may end up having to switch at some point, and that can be painful.

https://en.wikipedia.org/wiki/Log4Shell

https://learn.microsoft.com/en-us/dotnet/core/install/window...

Also, the page reads like an open source “We’re finished, we’re tired.”

I mean it's short and concise and there are additional resources that provide more detail. IMHO it's not a bad thing.

“The good old people from Sun working at Oracle” is now Oracle as well.

it wasn't about Oracle trimming the fat. Java 8 took 3 years to release and then Java 9 another 3 years.

They had to commit to half a year release cycles and LTRs every 2 years. Since then the releases became a lot more predictable. Whatever is not ready is not released (or is there as a preview feature).

This more agile approach is a lot better in my experience and we see that the changes made are more relevant and what people actually want.

I don't get this either. You can even lock the language level if you really don't want it, or you can just ignore it.

Because unless you are the only person maintaining your codebase other people in your organization will start using the cool new syntax sugar and optional functionality. So you will be forced to deal with it as it starts showing up in your codebase.

Some of those ways come from just plain object initialisers. Which are amazing and sorely needed in Java.

That's why you get `new List<T> { };` Because it could be `new ComplexObject { <fileds and properties> }`.

Same for `new`.

Some come from type inference which Java also has.

That's why you can have `List<T> foo = new List<T>();` and `var foo = new List<T>();`

It's not really "7 ways to assign a new empty List<T>". It's "7 ways to create an object", and Java several of them, too.

You don't really have to use the latest C# version, though. Install the latest .NET and you get the performance improvements without usually having to change anything about your code.

People complain, but most of the actually used changes are in things that continually used where I find painpoints.

Not 100% on board with the collection expression changes (I found fluent Linq chains usually more readable), but they're improving painpoints so I think it'll work out in the end hopefully.

Most new syntax features make code more readable. For those that don't there are company style guides and `AGENTS.md`. The C++ philosophy comes down to "if it works ship it" and I don't think you're expected to use every single new feature.

It's a normal open source announcement without the corporate bullshit. No fatigue. No doom. Just facts! /s

Also, the page reads like an open source “We’re finished, we’re tired.” announcement rather than the razzmatazz of a Microsoft release.

I think this is because the JRE/JDK upstream releases are a bit like Linux kernel releases: all the major first-party feature development goes on in subprojects that maintain their own "living forks" during feature development, with the teams on these features doing PRs against the fork's own "main"; that "fork's main" having its own subproject maintainers who ensure a mess isn't made of it; and then those maintainers eventually polishing up that fork-main into a single big one-shot PR to upstream once the feature-as-a-whole is ready.

(Compare/contrast: the Linux kernel's mm, rt, and kvm feature development efforts.)

Because of this, the top-level "project maintainers" (i.e. the people who decide what gets merged into upstream main) aren't really the same people as these subproject people who care deeply about these new features. They want to ship stuff people want, but they personally mostly deal all day with requests to merge 1. small bugfixes, and 2. features so small that no JEP is needed.

But then, every once in a while, they have to deal with a request to merge one of these huge subproject upstreaming PRs. And sure, it's already heavily reviewed by the subproject's maintainers, who they trust. But they do still have to audit it and learn it and create a stabilized release path for it. "Handover" stuff. And that's tiring!

So, given that the toplevel project maintainers write the release notes, I'm not surprised they come off as weary about releases.

(That being said, for purely PR reasons, the toplevel maintainers could ask the subproject staff to contribute their perspective to the release notes of a release that merges their work? But this could also just-as-well be a separate blog post—which would probably be better for sharing. I don't think I've ever seen a centralized Java blog [is there one?] but I think the subproject teams do tend to have them.)

yeah - they took forever, one reason being that Sun was in financial troubles and then acquisition took a long time.

Second was about licensing and Apache Harmony.

So, eventually they dropped most of the big things that were planned - Project Lambda with closures, Project Jigsaw with modularisation, Collection Literals. They eventually came back, but took a while to implement, so it was a prudent decision to make.

Java releases used to be glacial multi-year affairs. Lots of discussion of features that then missed the release train and you knew they'd not be with you for another multi-year period.

They made a conscious decision to switch to a regular six-month cadence and it's been all the better for it. The preview-mechanism has been terrific there too, allowing half-baked features to be aired without absolutely committing to something that turns out to be flawed.

Edit: Ninja-ed by Romario77's sibling comment :)

I am looking forward to it, and many other things planned for Java!

That's about letting you do Expression<int>, not about removing type erasure or otherwise allowing overloads based on type parameters.

interesting. So less specialization on one side but also less fragmentation.

the page reads like an open source “We’re finished, we’re tired.” rather than the razzmatazz of a Microsoft release.

The vibe selects the audience perhaps.

People who are tired and just want to finish their work like the first style. People who want to do more cool work more quickly, maybe without finishing, like the second. Depends on the work, I suppose.

"The Java Story" documentary by CultRepo on YouTube is pretty great. A major topic is the release cadence which some other comments here are mentioning / joking about.

A first step of Valhalla that is ...

Falls behind how? Isn't it still ahead? Kotlin keeps changing too, you know!

Really? I don't thinks so. There is a reason JEP 539 is in preview. There is a reason internal annotations exists in current valhalla jdk prototype and upcoming java 28 such as @jdk.internal.vm.annotation.NullRestricted, @jdk.internal.value.ValueClass.newNullRestrictedNonAtomicArray. Also, there is a reason value classes are allowed to be null. This is because nullness types will be a key factor to the java language.

Project Valhalla will go into Java 28

Unfortunatley without specialized generics and without the performance benefits that are supposed to come with it. They were too slow with Valhalla.

You really need to dare to try something else, Kotlin has been available for many years and the cost for a Java shop is super small since the same tools work with both. I’ve used also Dart which is lots of fun. Even Typescript can be a good alternative depending on what you’re doing. All have nullability guarantees and a nicer type system than Java while being in the same ballpark in terms of performance.

The elephant in the room is the standard library (collections). It isn't even type safe yet, because some methods were around before generics were added. And collections are too core for anyone to be able to agree on a 3rd party standard.

The JDK team made a decision awhile ago to hold the Vector API until value types are final. That's why the API has been incubating so long.

I would, or C#

IME they're both in a place where Rust is maybe ~40% faster for a decent CRUD web application server, but with go you need to write much lower level code to get there (e.g. using composable generic iterators will ruin your allocations, so it's all manual for loops). You can write idiomatic high level Scala and get the same performance. Which could be as simple as the go compiler offers no ability to force inlining and has way too low of a complexity threshold, but that basically makes reusable code unusable in high performance situations.

The whole go team's philosophy tends to also revolve around assuming their users don't know what they're doing, which is annoying. Like an inline keyword: thinking you know better than me doesn't mean I'm not going to inline it; it means I'm going to manually write it inline myself in the code, and then think the language sucks because it's tedious, error-prone, and verbose. Or they tend to mark lots of stuff private for no reason, and e.g. with TLS 1.3 they just ignore your config because they think they know better, etc.

Isn't this mostly about java cold start costs? It might be that other people are optimizing for steady-state performance, not transient startup performance.

It's sad - I spent a good 12 years writing Scala every day and it was the ideal language for my brain. Until it wasn't - sbt got too complex for it's own good, everything became "very smart" developers over-using implicit conversions, you couldn't find a project that wasn't an opinion war on cats vs whatever. It collapsed on the weight of it's own smugness.

go and kotlin aren't it, gleam scratches the itch but I can't justify writing code that would impossible to hire for.

scala situation is a real shame.

I think it used to be common to just look for smart people and assume they can run with whatever stack. Wasn't that the point of abstract algorithm questions etc. (basically an IQ test)?

Lots of companies where software isn't the focus see it as a cost center, so they'd prefer to hire lower-IQ specialists instead of higher-IQ generalists, because the latter are more expensive/have more options.

Java is almost always significantly faster than Go because the Go runtime does a poor job of exploiting large memory page, doesn't support text-on-huge-pages, and barely supports profile-guided optimization. With HotSpot you get all of this and more for free. Go is fine but Java is peak.

Golang is not faster than Java, the opposite in fact. With native image, Java can be used for sidecar applications as well.

This made me chuckle.

Aside: Scala dev here - but I only talk about how wonderful it is with people I trust (mostly Go and Rust developers I used to work with).

Also, Scala Native means I don’t always have to worry about the JVM depending on the use case.

ScalaJS is fun too.

You could, but it's not as fast as Java, especially under heavy workloads, its telemetry is nowhere near as good, and it's much less popular.

It's unsafe in many applications due to not having exceptions

Are you guys keeping up with the Java LTS releases?

Many of those are getting addressed. Value types are in the works, generics specialization for primitives, and even type classes.

What better options are there if starting from scratch? The only thing IMO that comes somewhat close is C# for general backend systems.

Jruby is nice - runs Ruby on a Java Virtual Machine with full concurrency and Ahead Of Time compilation

Yes.. lol. The biggest argument now is Kotlin having nullness by default in the language. Just check around the comment section. Now java is planning to have them which will further help jvm to optimise for performance. Not sure what the next argument will be after.

Mostly I think they are a mistake, like in ordinary application code instead of catching close to the throw you want to do a lot of

  try {
     ...
  } finally() {
     ...
  }

to make sure things get torn down that have to be torn down and let the exception go to the top of the unit of work and probably to whatever drives the work unit. You can probably do better than logging the raw exception and moving on to the next work unit but you can do much worse. That is, you want a default "sloppy" error handling approach that's correct that you can do without thinking and avoid other kinds of "sloppy" coding encouraged by checked exception such as catching exceptions locally without doing the right thing globally.

Occasionally though I have built something really sensitive, like an authentication filter for a web site which has at least 5 ways to log in and in that I have a hierarchy of exceptions and use checked exceptions heavily to document all the ways things can go wrong and felt like "the type system really has my back here" but that is like 5% of the Java I write.

Scala's ZIO also demonstrates that they're a great idea and can be perfectly ergonomic, but you need type inference, which Java devs were resistant to for a long time (maybe still are? I remember lots of "how will I ever know what `val a = new Animal()` is???"). If you infer the exception type, they're basically invisible except for when you forget to have some place in your program to handle them, which is exactly what you want.

I don't think I can recall a time...

I appreciate that there is a _ton_ of different experiences out there when it comes to solving problems, but I _have_ encountered exactly the case I was describing, which is what led me to my original question. Isn't the fact that it was a checked exception that led you to "consider retrying a network failure, you immediately need to start thinking about distributed systems failures, idempotency, and all that good stuff" worth it as opposed to an unchecked exception you may not realize is being thrown?

I'd argue that checked exceptions are still worth it, even though all the problems pointed out do exist. And that's because it works to inform consumers of what a producer is doing. Haskell has the IO and Maybe monads; Java communicates the same information through IOException and other domain exceptions.

Many times I've decided to switch from one function to another, or even an entirely new library, because the checked exceptions told me that it was doing far more than I expected, and I was not comfortable introducing those new failure modes.

It's far from perfect, one still has to handle nulls and wrapped/merged exceptions, but overall I like this language feature.

Perhaps you are the trip you expected to blow up first.

That's less of a thing nowadays if you use the newer APIs that accept Charset instances instead of the charset name as a String.

A lot of that is coding style. I’ve also seen a lot of hard-to-debug issues in Python caused by reflection, weird decorators that muck around with name-mangled symbols, and bytecode manipulation. You can even manipulate the traceback object so it’s more difficult to make sense of why the exception comes from.

It took me quite a long time to accept that the recommended unit testing library manipulates bytecode so that the exception message for `assert a == b` prints the values for both.

You forgot runtime agents!

IMO compile-time annotation processors such as Lombok and MapStruct are far from the most magic part of Java. They're straightforward code generators. Their impacts is localized to where they get applied and you can actually see the code that's generated. They're very good for diminishing boilerplate. They're no worse than Rust's very standard #[derive(xyz)] proc macros.

Having the code being generated on the fly (instead of a one-shot) means it follows the rest of the structure it's derived from i.e. equals() and hashCode() don't risk to be forgotten when adding a field to a class (hello maddening Map<> lookup errors)

Also, yes, Lombok is _funky_ in how it works but there are "pure" alternatives like AutoBuilder and AutoValue if one cares.

And another positive point for Java: checked exceptions. It's verbose, but knowing exactly in which ways a function can fail is extremely helpful for building robust applications.

Sorry, but no, Java has the worst of both worlds here. It has checked exceptions AND unchecked exceptions, AND errors which are like unchecked exceptions but won't get caught by a normal catch-all (you're not supposed to catch Throwable, but it's the only way to prevent some dynamically loaded plugin code ten layers deep in the stack from breaking your invariants or stopping your periodic scheduled task due to an errant NoSuchMethodError or NoClassDefFoundError).

And you can't easily use checked exceptions with Java8-style functional code, since interfaces like Function aren't generic on the exception type. Which leads to aberrations like UncheckedIOException, which exists only to make IOException usable in the functional world.

It works well enough with plain Ruby and plain Javascript. It ported a Rails 7, Vue 2, vuetify 2, vuex app to Rails 8 (ok, easy, I did it myself at least once), Vue 3, Vuetify 4, Pinia. I had to visually check the SPA, of course.

Re: Java 27. I work with TON and this looks like something I can build. No pressure, but I can walk you through the approach if you want.

Everyone has to deal with other code that might not even be from the same org. The "check it in CI" answer isn't an excuse either. You're bolting on so much extra crap that way.

I just don't see why nullability is a problem in the first place.

Null Analysis can be checked and enforced by the CI.

Can you explain what the issue is with nullability here? Is the concern that someone's code returns null in normal circumstances but doesn't document that well, so you don't check if null? Cause if it's an error situation, one way or another some exception has to be thrown.

I admit I haven't worked in Java for years, but no project I've seen at my current company (the only one I've worked at since agents have been a useful thing) is anywhere close to removing all dependencies. From what I've seen, people want to spend tokens on new things, not things that are already known to exist. Even if you can reinvent the wheel, it's not something that an employer is going to be particularly happy to subsidize.

I don't think I've encountered an external library that returned partially constructed objects returned nulls (at least not without a @Nullable). There are probably cases of this existing, but those types of libraries don't tend to see a lot of users.

The standard library writers can go first.

I use Kotlin as my main language and I’m very satisfied with it.

Any serious project will be using NullAway and annotating everything (or, indeed, using Kotlin).

Otherwise, yeah, you're still in for a world of pain.

It's a panic in Go, not an exception. In practice that's usually a whole process crash. You can catch panics and kinda use them like exceptions, but it's not conventional.

Sure it does:

https://github.com/uber-go/nilaway

Not exactly the same solution as JSpecify, since it doesn't rely on annotations, but it's also more ergonomic.

I'm not comparing this to "null-restricted types", since that's a draft JEP that hasn't made it even into a preview feature. Go also had multiple proposals for explicit nilability in types, and while they probably have less prospect of ever seeing the light of day compared to Project Valhalla, as things currently stand, Go is in the same position as Java: They are both extremely prone to NEPs out-of-the-box and they both have external tooling that can help you avoid them.

Java null checkers have more comprehensive coverage potential compared to Go, but Go is the more ergonomic one here. You don't need a single extra annotation on your code.

Go panics.

The ecosystem has (at long last) standardized on JSpecify (https://jspecify.dev) for nullability annotations. JSpecify allows you to annotate a package or module with `@NullMarked` and your IDE and build (via ErrorProne+NullAway, typically) will check for null safety.

If you develop a library in Java and use it from Kotlin, the built-in Kotlin null-safety will recognize the JSpecify annotations on the library.

Null-restricted types are on the roadmap. See: https://openjdk.org/jeps/8303099

You're drawing a distinction that doesn't matter in practice. If you encounter a NullPointerException incident then you either didn't annotate your code or you didn't run the tooling. (In fact before even running your CI suite, any serious IDE will tell you immediately that you've mishandled null somewhere.)

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.

but what many people do not know is that debugging NPEs in Java is easier now - they carry more information about the source

Unfortunately, no, they don't. Not after your application has been running for a while; newer JVMs arbitrarily decide you don't need the stack trace anymore, and all you see in your logs is "NullPointerException" (unless you still have the logs from several weeks ago, just after the last JVM restart, which might still have the full stack trace). Older JVMs were better, since they always had the full stack trace; debugging NPEs was easier with them.

Really?

Unlike C it is trivial to catch a NullPointerException and confine the crash to the unit of work. And unlike C you are not talking about insanely dangerous pointers, you're just talking about an NPE.

I'll admit it's a hassle when something wasn't initialized properly and then you get a null pointer exception at some unrelated code much later. It's not always easy to debug. Catastrophic? No!

There are a lot of third party tools that can check for null safety and a lot of work is being done to make Java's initialization safer but also a little more flexible, there is

https://openjdk.org/jeps/8303099

and there are all sorts of practical answers. Nulls in Java are low on my list of annoyances, way behind front end programmers who pepper my CSS files with "!important" because they don't know about precedence (though maybe they think my .clazz.clazz.clazz selector is brain dead!)

I don't really think about it too much, it works fine. We don't use Optionals, I'm not sure why you brought that up. I'm not a dogmatic person in this respect, rather pragmatic. I'm sure Kotlin is great, and I'd enjoy writing it, but for now, the vast majority of the finance world runs on Java, so it's what we use. I find it easy to work with, which counts for a lot.

java is a great language for server side projects. it is actively maintained, the biggest issues with it have JEPs, and it’s very friendly to AI authors

Java's ecosystem is lingering since Oracle brought the language, and it's at the point where you should really look if the things you want to use are still in the state of the art, or if they felt behind every other language.

And if you are starting from scratch, whatever part of the ecosystem you use, I'm not optimist on its situation improving with time.

I use Java for hobby projects, I think it's design choices make it a nice minimalist language for "classic OOP" style: dynamic dispatch, encapsulation etc.

Nowadays a lot of code is written with mostly procedural style with some functional characteristics, I wouldn't use Java for that.

Asp.net is also a pretty good alternative to the ubiquitous nodejs?

Microsoft has come a long way since Satya Nadella took over in early 2014. The open-sourcing of .NET Core that same year was a huge step forward. Seeing a 'Microsoft Loves Linux' slide that year was something I did not have on my bingo card. VS Code and the GitHub acquisition demonstrated Microsoft's interest in fostering good relations with developers instead of alienating them. I do wish GitHub had stayed independent, though.

Microsoft is a business and will always put their business objectives first. In my opinion, they have a non-zero amount of evilness. I do not support them jamming Copilot into every available crevice. I still think they make dumb choices, like every imperfect organization. However, C# is a powerful and intuitive language, and for Microsoft shops that already run a lot of Windows and SQL Server it makes a lot of sense.

No shade to the JVM. I've mostly enjoyed my time in that space. I do believe the choice between Java and Kotlin, the wide variety of vendor JDK distributions and IDE fragmentation make the JVM stack a bit more difficult for newcomers to break into.

Consistent ecosystem with state of the art tooling (Visual Studio)

Majority of things provided from MS instead of having to rely on 3rd party, especially nowadays when supply-chain issues are huge concern

Null pointer dereference problem. Solved for greenfield C# projects and Kotlin

If your app requires a specific JDK version and your OS wont support, you can run that JDK version in a modern JVM: https://www.graalvm.org/latest/reference-manual/espresso/

Stability is a good point, although I am curious where JS and Node stand there now. They're not at the level of Java or .NET by any means, but the JS ecosystem has definitely begun to slowdown over the last few years. I've used express for the server and winston for logging for years and years now and they've very stable at this point.

I guess I'm asking this as an open question: Where are we in the "move fast vs stable" spectrum with Node these days? Definitely not rock solid, but it's moving in that direction I feel.

I wrote about it 13 years ago, some of it still stands true. https://news.ycombinator.com/item?id=5857495

There's a difference between number of programs and number of LOC (the latter is related to the number of people involved). I am not aware of any SDK targeting the industries I mentioned that "doesn't bother with Java". It's not only a popular choice in those industries, it's not only among the top choices, but it's the top choice by a large margin. Look at wanted ads in those industries to see that. Overall, there are only two languages as popular as Java or more, and they are JS and Python: https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...

Open telemetry is about how telemetry data is reported, not how it's collected. It's hard to compete with JFR on the breadth and depth of low-overhead, in production telemetry, built into the standard library and the JVM itself.

I don't know what compiler and GC quality has to do with how people are making software these days, and I don't think state-of-the-art optimising compilers and GCs are terrifying at all. Go opts for more traditional, simpler algorithms under the assumption that for many purposes they're good enough. That may be so, but sometimes workloads really are very demanding, and you need the best performance.

Time and again we see Rust or C++ programs spend 30-50% on memory management.

30-50% of what?

Haven't they heard of Gradle or Bazel?

Let's use tools that are 10 years behind

Yes and that's exactly what modern tooling is missing. Try to develop for node.js 0.2.12 on today's update of Visual Studio Code. See? No enterprise-level collaboration for ya.

Go has null pointer dereference problem.

Which Java famously does not have.

Rust is too low-level for typical enterprise app where requirements changes twice a day. You end up spending time and tokens fighting with borrow checker.

In my experience, you do not spend tokens fighting with the borrow checker anymore, newer models are smarter. But it might not be ideal for a lot of CRUD applications.

C# is MS product, which is no-go for some folks.

This is 2026, it's not 1996 anymore. .Net works on Linux and Microsoft is as friendly towards open source and open standards as a Big Tech company can be.

If anything, it was Oracle which more recently sued another company for using a JDK alternative. And this was a lawsuit that, if accepted, could have put the entire idea of API compatibility in danger and deal a severe blow to the Open Source movement.

Anyone who is morally bothered by MS but is unfazed by this is probably just mentally stuck in the 1990s.

Kotlin probably would be the answer.

I love Kotlin, but I'm afraid that's not the case. The conservative organizations that choose Java out of inertia, would keep choosing Java over Kotlin, even if Kotlin is a better JVM language which is facing no downside.

For anyone who doesn't need to be on the JVM or work with JVM tooling, Kotlin doesn't cut it. It doesn't have null pointer dereference problem in theory... Only it does in practice if you're using any Java API that may return null (all these bang-decorated "Platform types"). Generic type erasure can only be overcome in inline functions with reified types. And building and deploying artifacts without docker is still a mess.

I found Kotlin extremely publishing for Java shops in the past, and I've converted multiple departments totaling over hundreds of employees to use Kotlin. But that was before AI. The rationale was simple: Java is an entrenched language that leads to bloated code, slow development cycles and way too many avoidable bugs in productions. Kotlin solves some if these issues, and it's very easy to learn for a Java engineer, while still letting you keep all of your tools and libraries. And as a language (putting ecosystem aside), I find it better than either Go or Typescript, and far more ergonomic than Rust[1].

But all of these arguments die with AI. Rust is just as ergonomic as any other popular language today if you're using an agent, and the fact that an engineer spent their lifetime writing Spring Boot programs in Java you don't have time to let them learn a new stack from scratch doesn't matter anymore.

Sure, there are many companies where letting AI write the code is still not acceptable, but most of these workplaces will accept AI agents sooner than they accept Kotlin.

I feel a bit sad since I like many ideas about Kotlin (especially how amenable it is for making DSLs) but we've lost that opportunity

--

[1] Unless you have to write highly concurrent code without any data races.

I think of Java/Kotlin and Spring as a secret weapon for startups. My workplace was a startup 5 years ago and it's amazing how things just worked as expected, leaving us more time to focus on the product. We have tried a few alternatives over the years, such as a few services in Rust, but the people who implemented those have usually seen the advantage of using a stable ecosystem after a few years. It's unfortunately something you need to experience yourself instead of being told by someone else.

claims processing - TypeScript, lots of ETL tools with Go.

medtech - .NET and TypeScript.

We embedded angular in our old Java client for hospitals. The user thinks he just opens a new window, but it's chrome in Java, which opens angular frontend, for our Java backend.

Cross platform C# is certainly getting huge in healthcare and medtech recently though.

Greenfield doesn't imply startups, does it?

From what I see, most software being created in these spaces isn’t made by startups.

Any mainstream language can be reliable. Java is a good choice for greenfield projects when it fits the organisation’s existing stack, expertise, or the broader industry ecosystem. Just like any other language.

Banks, telcos, etc. aren’t monoliths either. They use plenty of different languages depending on the team, system, and requirements. Java isn’t inherently the choice for greenfield software just because reliability matters.

JavaFX is a hidden gem. I really like the programming model with its binding and scene graph and CSS.

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.

Here is a niche one:

When you want to make a game and support modding with pretty much zero development effort.

I once tried Kotlin for a pet project, but after a while switched it back to Java, since it's good enough, IDE support is better, it's much faster.

I guess if you use/like Intellij it's ok.

C# gRPC story is really, really good, too.

When you’ll have tons of low skilled devs contributing to an important but boring application that will last a while

It's a stable known stack. It's not hard to find Java developers and the AI Agents are probably pretty good at writing Java too. A Java backend will just sit there and do its job happily forever and you can bolt on whatever front-end you want. Spring Boot has been kind of the standard way to do Java web applications for probably a decade if not longer. It works fine has all the bells and whistles when you're ready for them and most Java developers who work on the web know Spring already.

As for an individual developer doing a side project, you should use Java if you haven't used it before to get exposure to it. It's a fundamental component of enterprise software and if you've never used it before take the time to learn something new.

roughly 100% of the time

Yeah. Why use a statically typed reliable language with a good ecosystem if I can also vibecode in Python.

Good question - am using for a greenfield AI startup in SF. Been a great decision so far: great ecosystem, bulletproof runtime, fantastic performance and new quality features arriving on a steady schedule. "Boring technology" at its finest.

At the risk of a shameless plug - blogged about it recently at https://mandeepgill.net/2026/08/31/java-for-an-ai-startup/

Often? It's a relatively modern language with enough functional programming features to keep mid-high blub programmers happy. Yeah there's cruft; all mature languages have cruft.

Kotlin is the obvious replacement, but the tooling isn't as good and the community isn't as large. Java keeps getting better, and in ways that diverge from Kotlin - eg, virtual threads vs async/await/coloring. From the perspective of language design, I prefer Kotlin. But I keep picking Java anyway, and I don't see that changing soon.

Go is openly hostile to functional programming. Dynamic languages aren't even in the running. Rust is too low-level for line-of-business software. C# is too Microsoft. The remaining alternatives are too obscure.

It's decent for backends. I'd rather use JS, but there can be performance or ecosystem reasons to use Java. They fixed a lot of the gaps it had. JS used to have a big edge in async-await while Go had n-m multithreading, but now Java has the latter.

anecdotal evidence: I‘m working on a product in circular economy space at the moment (chemical trader). I chose Java because it just works and allows us to focus on business, no npm supply chain drama, no „how can I integrate my go microservice with a customer SOAP endpoint“ problem, time to hire under 2 months etc.

That's one benefit of using Java actually. You can always find Java developers.

Also - and this is very subjective - I find developers who have similarly low view of software development and high view of simple languages, to be very good team mates. We can laugh at the realities and move on pragmatically.

Well, ask yourself this, why use a hammer to drive a nail when a rock can do about the same?

Same reasoning here, Java is "enough" in of a lot of areas that make it desirable for a lot of things, it is fast enough, stable enough, has lots of libraries and apis for a lot of things you may want to do, and the jvm makes it reasonably portable, among other things.

Love Java vs Hate Oracle... My life is a shit show