Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If you're doing green field JVM developer and NOT using big frameworks like Spring or an app server it is pretty safe to use the intermediate releases.


... if you're willing and able to update your entire app to a new JDK the month it comes out.

This is where I hope Java adopts the .NET support lifecycle. .NET also has (relatively) fast-paced releases now, once per year with LTS every other year, but the prior non-LTS is supported for 3 months after the next one comes out. That's still pretty aggressive, but it's very doable with a modern app to upgrade within 3 months.

With Java, JDK 15 support ends this month, the same month that JDK 16 comes out. Not just that, but we're halfway through the month already. So if you're on JDK 15, you now have only two weeks to upgrade and still be supported, according to their official schedule.

https://www.oracle.com/java/technologies/java-se-support-roa...

Edit: I may have been too generous in my reading of their support roadmap. It seems like the previous non-LTS version is immediately out of support as soon as the new one "supersedes" it.


Spring supported each and every java release between 9 and 16. With one release being supported a month later (don't remember which).

I know because I use Spring (and hibernate) and everything just works.

(If you are on the most recent Spring version)


Uh, probably just my narrow corporate world view but... is there any serious development in java NOT using Spring?

Time for me to learn so let me rephrase this question! Those who use java without EE or Spring framework, what are your go-to libraries? What are you using for DI / REST / ORM / Auth etc?


> is there any serious development in java NOT using Spring?

Yes. And I don't just mean people doing Android development.

1) DI: Don't always need DI. For things like injecting values from config, it's really unnecessary given that we have very good control over production, down to building our boxes from a playbook. For things like mocks, plain old Java suffices -- you can roll your own (actually, someone in your team just needs to do it once and it keeps getting improved/forked). Guice exists as a fallback.

2) REST: Jersey + own libraries on top, Retrofit. Using Spring for REST is probably the poorest use for Spring, for me.

3) ORM: you can use "just" JPA. Don't always need an ORM either -- the strategy varies depending on the requirement. Although for some projects I have used Spring Data JPA because it seemed like the easiest path. At least Spring was localized to that artifact.

4) Lots of good OAuth2 libraries as well as things like pac4j. If you're wondering about Spring Security, it's definitely one to consider if you're doing lots of webapps in Java. But in a polyglot environment, a lot of Java code just handles APIs while node handles the UI.

Anyhow, this isn't to hate on Spring or anything -- I use it if it adds value. This is more about not taking the the complexity hit if you can help it. It also makes the code a bit more straightforward and readable.


Different needs for different domains. For example, there's an old pack of machine learning code that I maintain, and it (and a bunch of other Java code that I see from other institutions) does not use or need DI, ORM, Auth nor proper REST, they typically handle processing of non-database data with no or minimal web interaction, and plain old objects are fine for that - if we started from scratch and chose Java instead of some other language, we would still not use Spring for that.


Google used Guice for DI (Or Dagger2 sometimes), rest is it's own thing, orm is "there is no ORM go write your spanner queries", and Auth is it's own thing.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: