4 ms·

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".
lmm 3y ago
In return the process of using a new version of their container orchestrators/runtimes/etc. will become more painful than a Java upgrade ever was.

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".

lmm 3y ago

In return the process of using a new version of their container orchestrators/runtimes/etc. will become more painful than a Java upgrade ever was.