# Should you adopt Java 12 or stick on Java 11? DevFeed: [Should you adopt Java 12 or stick on Java 11?]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2018-10-31T07:02:00Z Content type: opinion Language: en Sources: [Stephen Colebourne]() Topics: [Java](), [releases](), [upgrade](), [Security]() Tags: [java](), [lts](), [openjdk](), [patches](), [releases](), [upgrade]() ## AI overview This article examines whether JVM users should adopt Java 12 or remain on Java 11. It explains Java's six-month release cycle, the role of long-term-support releases, and the compatibility and security-patch risks involved in adopting non-LTS versions. ## Source excerpt Should you adopt Java 12 or stick on Java 11 for the next 3 years? Seems like an innocuous question, but it is one of the most important decisions out there for those running on the JVM. I'll try to cover the key aspects of the decision, with the assumption that you care about running with the latest set of security patches in production. TL;DR, It is vital to fully understand and accept the risks before adopting Java 12. The Java release train There is now a new release of Java every six months, so Java 12 is less than five months away despite Java 11 having just been released. As part of the process of moving to more frequent releases, certain releases are designated to be LTS (long term support) and as such will have security patches available for four years or more. This makes them "major" releases, not because they have a bigger feature set but because they have multi year support. It is expected that Java 11 patches (11.0.1, 11.0.2, 11.0.3, etc.) will be smaller and simpler than Java 8 updates (8u20, 8u40, 8u60, etc.) - Java 11 updates will be more focused on security patches, without the internal enhancements of Java 8 updates. Instead, Oracle want us to think of Java 12, 13, 14 etc. as small upgrades, similar to an imaginary Java 11u20, 11u40 etc. To be blunt, I find this nonsensical. Senior Oracle employees have repeatedly argued that updates such as 8u20 and 8u40 often broke code. This was not my experience. In fact my experience was that update releases primarily contained bug fixes. The only break I can remember was the addition of --allow-script-in-comments to Javadoc, which isn't a core part of Java. As a result, I have never feared picking up the latest update release - and this has been a core benefit of the Java platform. Drilling down into why update releases tend to cause no problems, lets examine the differences between release types: Model Old model New model Upgrade Java major releases Java update releases Java release train Java patches Freque