Indeed, at a compiled level, byte code is mostly long lasting.
I haven’t fired up a 10 year jar file recently but it would not surprise me if it Just Worked.
The success of that is twofold. First is simply that whatever changes are being made to the JVM, they’re mostly forward looking and don’t deprecate running code.
The other is that the conventional packaging mechanic is, essentially, a static binary. A “fat jar” is the term of art, with all of the dependencies bundled in.
But there’s still potential problems. They’ve been removing large subsystems from the JDK as of late. XML, web services, Java FX are poster examples. So legacy binaries depending on those will fail outright.
These can be added back to the Java runtime, but still “one more thing”.
Of course from the source code side, Java suffers dependency hell and code rot along with the best of them. Network based dependencies up and vanish. Long standing projects may not publish 10 year old jar files any more.
Also, Java has had other clods dropped into its churn. Oracle shutting down the java.net website was a huge sudden black hole in the community consciousness of Java. Overnight thousands of articles, blog posts, forum entries, and other artifacts vanished like Keyser Soze. Leaving behind a debris field of dead links across the internet.
So, to be fair, the JVM is a boon. I really like Java, and it’s still going strong. The VM architecture and the comprehensive nature of the Java runtime has made the moving of running code across systems much easier. As someone with an enterprise Java background, used to deploying WAR and EAR files, I got to mostly avoid the entire Docker and other such family of infrastructure. Install a JDK, install an App Server, all fairly trivial to isolate, and the system is ready to go.
But in the large, it takes more than a VM to get things accomplished. There’s always an eco-system at play.
And one primary characteristic of eco-systems is they evolve. Time marches on, and waits for no one.
Thank you for your thoughtful and interesting comment.
I too like Java a lot and think it's a great technology.
I can see how a runtime for a compiler (such as the JVM) doesn't need to change much over time: if the compiler produces the right code in 2000, then the code is probably still right in 2020, it just could use more features of the ISA that were introduced since then.
On the other hand, the design of platform, library code and framework code is an ecosystem that is desperate to transform over time as better approaches to solving technical and business problems are found.
Indeed, at a compiled level, byte code is mostly long lasting.
I haven’t fired up a 10 year jar file recently but it would not surprise me if it Just Worked.
The success of that is twofold. First is simply that whatever changes are being made to the JVM, they’re mostly forward looking and don’t deprecate running code.
The other is that the conventional packaging mechanic is, essentially, a static binary. A “fat jar” is the term of art, with all of the dependencies bundled in.
But there’s still potential problems. They’ve been removing large subsystems from the JDK as of late. XML, web services, Java FX are poster examples. So legacy binaries depending on those will fail outright.
These can be added back to the Java runtime, but still “one more thing”.
Of course from the source code side, Java suffers dependency hell and code rot along with the best of them. Network based dependencies up and vanish. Long standing projects may not publish 10 year old jar files any more.
Also, Java has had other clods dropped into its churn. Oracle shutting down the java.net website was a huge sudden black hole in the community consciousness of Java. Overnight thousands of articles, blog posts, forum entries, and other artifacts vanished like Keyser Soze. Leaving behind a debris field of dead links across the internet.
So, to be fair, the JVM is a boon. I really like Java, and it’s still going strong. The VM architecture and the comprehensive nature of the Java runtime has made the moving of running code across systems much easier. As someone with an enterprise Java background, used to deploying WAR and EAR files, I got to mostly avoid the entire Docker and other such family of infrastructure. Install a JDK, install an App Server, all fairly trivial to isolate, and the system is ready to go.
But in the large, it takes more than a VM to get things accomplished. There’s always an eco-system at play.
And one primary characteristic of eco-systems is they evolve. Time marches on, and waits for no one.