4 ms·

All of these nice features of the JDK yet most Fortune 500 companies probably still using JDK8 or 9.

by xyst 3y ago

volkadav 3y ago
With extended support available for JDK 8 until this end of this decade or so, it's going to be a while before the real laggards upgrade, heh. Maybe that'll be my generation's method of funding the retirement RV purchase like the COBOL grognards circa y2k, haha.
ebiester 3y ago
Who's using JDK 9? I understand the JDK 8 bit - the breaking changes in large code bases are a big lift, especially in projects with no significant changes for years. However, if you're on 9, the lift is much lower and primarily on QE. Why stay on 9?
- sverhagen 3y ago
  For large organizations it's also an organizational lift, plus their attraction to have all the latest goodies from the latest JVM versions is probably a little less, so a lot of the same inertia that existing in moving from 7 to 8 and from 8 to 9 is going to resurface for any migration, even if the actual breakages during the compilation step are less.
carimura 3y ago
Most companies I talk to have a mixture of 8 for many stable unchanging applications and [11, 17, latest] for newer stuff.
invalidname 3y ago
That's because most of them haven't "really" migrated to containers. Once this is done the process of using a newer version of Java will become seamless.
- jjtheblunt 3y ago
  Jar files are containers, in some fundamental way, I'd say. Perhaps since they come from Sun and Solaris had zones, et cetera?
  - switchbak 3y ago
    And not, in a more fundamental way. Sharing a JVM just isn't the same thing as a sandboxed process. OSGI was probably the closest thing that tried to embrace that model, and it didn't turn out very well (putting it mildly). If the JVM actually did provide the same guarantees and restrictions as a real container, that would have been very useful.
- sverhagen 3y ago
  In my experience it's more because their compliance team hasn't blessed the newer version for general use. These large organizations don't put the autonomy with individual teams to make such decisions to upgrade technology. So everyone is looking at a centralized authority who then feel the pressure to make a perfect decision, which turns into a hesitation because they also don't have a great process to evaluate a complex piece of technology like the JVM and declare it "perfectly safe and secure". So then the status quo wins. They will even pay companies like Azul to maintain support for Java 7 or 8, rather than making the leap. (And yes, there's probably a small contribution to this problem from source code that's hard to migrate, but as good as Java's been about backward compatibility, I don't think that's a big contributor in earnest.)
  - closeparen 3y ago
    That’s pretty incredible hubris, to worry that something as central and widespread as Java could suddenly stop being safe and secure in a way that only your org can detect or care about.
    - lmm 3y ago
      It's more that their policy doesn't have enough detail to distinguish between Java and one dude's GitHub project. They'll have one policy for "software", or if you're lucky then two policies, one for "software we have a support contract for" and one for "software we don't have a support contract for".
pjmlp 3y ago
Thankfully Java 11 LTS is now the bare minimum in our projects, and I even managed to push for Java 17 LTS on the latest one. Even Android team has acknowledged that despite Kotlin, they needed to improve their support due to third party libraries, with Java 11 LTS last year, and Java 17 LTS coming this year. Both down to Android 12, naturally the usual subset without the graphics/UI related packages.
pron 3y ago
Some significant number of projects still use 8, but all indications are that they're not the majority anymore (I don't have information about Fortune 500 companies specifically).
w10-1 3y ago
Isn't it a success when you can build something that lasts 10+ years? Enterprise has been relying on Java's compatibility promises for decades. It means the business decides when to invest, not the technology. The cost of re-validating and re-integrating a new system far, far outweighs that of re-writing the software, so you only upgrade the software when you're already having to upgrade the system. Mark Reinhold managed to move Java to open-source, to frequent releases, and to supporting alternative languages (Kotlin for Google) and deployments (graalvm for containers) -- all while maintaining compatibility. He entirely effaced the notion that change means breakage. Compare the breakage story in Python and C++ in the same time period.
AtlasBarfed 3y ago
To be fair, JDK8 represents a stable version of Java features and API that is most of what is needed for enterprise Java development. It is basically the stable inflection point of Java's evolution in terms of why Java took over enterprise development. There was a core development intelligence level that JDK8 represented a sweet spot for (ahem, offshoring development). Which is really the core of the hate for Java these days although ... isn't Go the same trap? Most of the post-JDK8 features are moving the language to what Groovy is, but closures, magic string templates, etc, but the IQ level of the programmers for that is a different market availability. Combined with the inherent deployment churn needed for modern JVM version turnover, which most enterprises simply don't have the organizational ability to do, means that JDK8 is going to stick around a LONG time.
- lmm 3y ago
  Nonsense. For that kind of lowest-common-denominator development JDK8 has nothing that JDK6 doesn't; it has some minor quality-of-life improvements to the language, and some performance improvements to the VM, but nothing truly fundamental. If enterprises were trying to stick with a dumb Go-like language they would stay on JDK6. The real reason is simply that JDK9 was a much bigger compatibility break (in practice if not in theory) than any release before or since, and came after a long time of relatively little development. A lot of frameworks weren't compatible with JDK9 until years after release; some older ones may never be. So especially for enterprises that may have their own large internal frameworks, it takes a while.
  - mdaniel 3y ago
    > For that kind of lowest-common-denominator development JDK8 has nothing that JDK6 doesn't I see you are also one of the folks who ignores try-with-resources. And, say what you will about lambdas, it is night and day different between pre-8 and post-8 implementations of those various one-method interfaces such as InvocationHandler Connection fakeConn = (Connection)Proxy.newInstance(cl, new Class[]{Connection.class}, (proxy, method, args) -> { /*something awesome*/ })
    - 3y ago

All of these nice features of the JDK yet most Fortune 500 companies probably still using JDK8 or 9.

by xyst 3y ago

All of these nice features of the JDK yet most Fortune 500 companies probably still using JDK8 or 9.

With extended support available for JDK 8 until this end of this decade or so, it's going to be a while before the real laggards upgrade, heh. Maybe that'll be my generation's method of funding the retirement RV purchase like the COBOL grognards circa y2k, haha.

ebiester 3y ago

Who's using JDK 9? I understand the JDK 8 bit - the breaking changes in large code bases are a big lift, especially in projects with no significant changes for years. However, if you're on 9, the lift is much lower and primarily on QE. Why stay on 9?

sverhagen 3y ago
For large organizations it's also an organizational lift, plus their attraction to have all the latest goodies from the latest JVM versions is probably a little less, so a lot of the same inertia that existing in moving from 7 to 8 and from 8 to 9 is going to resurface for any migration, even if the actual breakages during the compilation step are less.

carimura 3y ago

Most companies I talk to have a mixture of 8 for many stable unchanging applications and [11, 17, latest] for newer stuff.

invalidname 3y ago

That's because most of them haven't "really" migrated to containers. Once this is done the process of using a newer version of Java will become seamless.

jjtheblunt 3y ago
Jar files are containers, in some fundamental way, I'd say. Perhaps since they come from Sun and Solaris had zones, et cetera?
- switchbak 3y ago
  And not, in a more fundamental way. Sharing a JVM just isn't the same thing as a sandboxed process. OSGI was probably the closest thing that tried to embrace that model, and it didn't turn out very well (putting it mildly). If the JVM actually did provide the same guarantees and restrictions as a real container, that would have been very useful.
sverhagen 3y ago
In my experience it's more because their compliance team hasn't blessed the newer version for general use. These large organizations don't put the autonomy with individual teams to make such decisions to upgrade technology. So everyone is looking at a centralized authority who then feel the pressure to make a perfect decision, which turns into a hesitation because they also don't have a great process to evaluate a complex piece of technology like the JVM and declare it "perfectly safe and secure". So then the status quo wins. They will even pay companies like Azul to maintain support for Java 7 or 8, rather than making the leap. (And yes, there's probably a small contribution to this problem from source code that's hard to migrate, but as good as Java's been about backward compatibility, I don't think that's a big contributor in earnest.)
- closeparen 3y ago
  That’s pretty incredible hubris, to worry that something as central and widespread as Java could suddenly stop being safe and secure in a way that only your org can detect or care about.
  - lmm 3y ago
    It's more that their policy doesn't have enough detail to distinguish between Java and one dude's GitHub project. They'll have one policy for "software", or if you're lucky then two policies, one for "software we have a support contract for" and one for "software we don't have a support contract for".

pjmlp 3y ago

Thankfully Java 11 LTS is now the bare minimum in our projects, and I even managed to push for Java 17 LTS on the latest one. Even Android team has acknowledged that despite Kotlin, they needed to improve their support due to third party libraries, with Java 11 LTS last year, and Java 17 LTS coming this year. Both down to Android 12, naturally the usual subset without the graphics/UI related packages.

pron 3y ago

Some significant number of projects still use 8, but all indications are that they're not the majority anymore (I don't have information about Fortune 500 companies specifically).

w10-1 3y ago

Isn't it a success when you can build something that lasts 10+ years? Enterprise has been relying on Java's compatibility promises for decades. It means the business decides when to invest, not the technology. The cost of re-validating and re-integrating a new system far, far outweighs that of re-writing the software, so you only upgrade the software when you're already having to upgrade the system. Mark Reinhold managed to move Java to open-source, to frequent releases, and to supporting alternative languages (Kotlin for Google) and deployments (graalvm for containers) -- all while maintaining compatibility. He entirely effaced the notion that change means breakage. Compare the breakage story in Python and C++ in the same time period.

AtlasBarfed 3y ago

To be fair, JDK8 represents a stable version of Java features and API that is most of what is needed for enterprise Java development. It is basically the stable inflection point of Java's evolution in terms of why Java took over enterprise development. There was a core development intelligence level that JDK8 represented a sweet spot for (ahem, offshoring development). Which is really the core of the hate for Java these days although ... isn't Go the same trap? Most of the post-JDK8 features are moving the language to what Groovy is, but closures, magic string templates, etc, but the IQ level of the programmers for that is a different market availability. Combined with the inherent deployment churn needed for modern JVM version turnover, which most enterprises simply don't have the organizational ability to do, means that JDK8 is going to stick around a LONG time.

lmm 3y ago
Nonsense. For that kind of lowest-common-denominator development JDK8 has nothing that JDK6 doesn't; it has some minor quality-of-life improvements to the language, and some performance improvements to the VM, but nothing truly fundamental. If enterprises were trying to stick with a dumb Go-like language they would stay on JDK6. The real reason is simply that JDK9 was a much bigger compatibility break (in practice if not in theory) than any release before or since, and came after a long time of relatively little development. A lot of frameworks weren't compatible with JDK9 until years after release; some older ones may never be. So especially for enterprises that may have their own large internal frameworks, it takes a while.
- mdaniel 3y ago
  > For that kind of lowest-common-denominator development JDK8 has nothing that JDK6 doesn't I see you are also one of the folks who ignores try-with-resources. And, say what you will about lambdas, it is night and day different between pre-8 and post-8 implementations of those various one-method interfaces such as InvocationHandler Connection fakeConn = (Connection)Proxy.newInstance(cl, new Class[]{Connection.class}, (proxy, method, args) -> { /*something awesome*/ })
  - 3y ago