Yes - best decision we made.

Running a new startup now and choose modern Java (JDK 21+) with Spring Boot and it's been fantastic. Have previously built startups using both Haskell and Python/Django in the past. Ignore the folks talking about it not being cool, heavy, boring or whatever - modern Java is just super nice and quick to work with.

Some positives we noted,

- "good-enough" integrated type system & language features, e.g. immutable records, type inference, generics, sum and product types with exhaustive pattern matching, lambdas, streams (along with the new stream-gatherers). We feel the gain isn't enough to switch to Kotlin anymore.

- Fantastic tooling, from IDEs, build systems, cloud integrations, remote debugging, settings configuration etc.

- Massive ecosystem - there are libraries for everything, and all major vendors, including cloud providers and most startups, have a Java SDK

- Spring Boot is a great framework, especially for API backends coming from Django - setting up things likes OAuth and OIDC was super easy. Spring AI is developing rapidly, for instance it got MCP support within a week or two of it being released

- Verbosity can be tamed with annotations processors, and Lombok if you desire (we do but understand some don't like it). JSpecify helps with null-checking.

- Performance is great, you just don't have to think about it at a startup scale, and Loom / Virtual Threads makes it even easier to build performant web services without the mental overhead of building `async` systems

I could go on, and like all things there are of course negatives, but we took the plunge and have been really happy with it.

That's my feeling. For me the only missing feature is WASM compilation. It's a shame that GraalVM native compilation is not targeting it.

I am using Kotlin with Quarkus for my healthtech startup (founded last year), mainly because it just works. JVM is a very optimised piece of software, and it can handle almost anything you throw at it. And I like writing Kotlin, which I think is more expressive compared to something like Go, while being less verbose than Java. Contrary to popular opinion of not touching ORMs, I use Hibernate, and it might be the best ORM available. None other ORM library comes close - but that's just my opinion. Sure, I can handwrite SQL queries, but as a startup, my data schema is always changing and I don't want to spend my time updating those raw queries when Hibernate can do it for me. I use it at my day job as well.

Why did you decide against Panache? Im experimenting with moving my booking system from node to Java and at crossroads between spring and quarkus. So far quarkus CLI tooling and ability to generate REST client code is incredibly productive and pleasant, but panache feels a bit different from spring data that Im used to.

Yes, using the latest version of Java to build the back-end services for an on-chain asset management platform, GLAM, on Solana.

Love Java because of how robust the JDK is with respect to Collections, Concurrency, IO and Cryptography. At the same time you can pick and choose exactly what modules you need to keep your application light weight. Also, I find Java has become more of a joy to write in recently as project Amber continues to release features every 6 months. (https://openjdk.org/projects/amber/)

Outside of the base and java.net.http JDK modules, the only external library I rely on is Bouncy Castle for the ed25519 utilities it provides. Considering some of the services sign financial transactions, it is nice to be able to minimize the risk of a malicious take over of a 3rd party library.

Only using AI for generating some of the more manual labor code.

If you are interested in building on Solana in Java check out https://github.com/sava-software/sava and https://docs.glam.systems

I think as long as Java has a massive backing, more people are going to want to use Java and create a self-perpetuating cycle. Even if the frontend tech changes, like Java to Kotlin to Scala, etc, the backend will always be the same. The JVM is an amazing piece of software with a massive community behind it, and I dont see that changing anytime soon.

I worked for a startup that used Kotlin. The language itself is not that bad (if you ignore the engineers that want to use every single time all the features the language has to offer), but the ecosystem was awful. We were using Gradle, and Spring Boot: just too much magic for my taste. Gradle itself is a beast I never fully understood, and I don't comfortable working with such tools (the Gradle userguide has over 1000 pages https://docs.gradle.org/current/userguide/userguide.pdf)

On the other hand, Go is a breath of fresh air; the tooling is simple and one can actually learn them in no time. There's less magic, and so a bit more of repetition, but I can live with that.

I don't see the advantage of having the JVM to be honest. I just don't see why it would be needed in 2025 (the "Write once, run anywhere" is not relevant anymore).

JVM's advantage has not been "Write once, run anywhere" for a long time - we all run code in docker containers anyhow. The real advantage is stability and tooling availability

Gradle and Spring Boot are not a part of the JDK, so it seems unfair to discount Java due to their poor designs.

The startup that I work at had started as a project a contracting company had taken on, and they had chosen Java Spring Boot to handle their REST API backend back in 2020.

Although probably not the decision I would have made, it's actually a pretty nice ecosystem that has scaled really well and been fairly easy to work with. Java 21 has _most_ of the QoL features that I like (I'd still really like a `?.` null operator that I can chain together) as well as the ability to reach for JPQL/SQL easily with JpaRepositories when performance is needed.

It's been fairly easy to onboard devs to the project even if they have not had previous experience with Java, and has maintained relatively decent code quality over the last 4 years.

I'm currently working on a LLM project for them that is being completed in Python, however, due to most of the tools being python-first and most of the LLM talent being python-first.

Would you choose Kotlin instead?

Kotlin would have definitely been a step up over Java purely for null safety.

In hindsight, RoR or Django would probably have been a better starting place considering their financial constraints (non-technical bootstrapping founders), but now that they are larger and more established Spring Boot seems a great framework given their current situation (the originally contracting code needed a major re-write anyway so I'm not sure that would have actually costed more time to go from RoR/Django -> Spring Boot)

I've done some work for a startup that uses Java as well as some other Java related technologies you might consider outdated. Their founder is an older guy and wrote the MVP himself. But hey - it all works and does the job quite well.

You can create an API and query databases with just about anything.

Great question! I know a couple of startups that are using it, and I am also using it as an independent consultant. It's not optimal for every scenario, but you can't really fail with it. You'll just move slower (or work harder) if what you're developing doesn't align well with its ecosystem and ways of doing things.

Big problem with Java in startups, its hard to do huge changes. The strong typing means you need to change a ton of code. Much easier to build off the cuff software in typescript. Really depends on what youre building though.

JVM is a heavy old begemoth. That is the core reason behind it not being popular among startups.

This doesn't mean it's bad (sometimes you need big gun, something mature and advanced), just out of many startups' immediate scope.

Java is not heavy. You can use GraalVM native compilation, and it will be as light as Golang. Modern frameworks like Quarkus or Helidon are lightweight. Sure, if you are working for an old style Java shop stuck with Java 8 and JavaEE. That's another story...

"heavy" here is used in a very broad, general sense - that includes legacy, features, traditions, existing codebases, practices, reputation, community, libraries, ecosystem, mindset, infra, learning curve etc.

Having few examples that jumps out of the tradition doesn't make something as a whole suddenly different.