Ted Neward anticipates solutions to runtime downloads, DLL hell, and other nightmares, realizing Java is in a similar boat...
And lest anybody start to think otherwise, the JVM presents the same problem as the .NET Runtime, and when we solve the .NET Runtime versioning issues, we'll have solved the JVM ones, using the same solution.
The linking problem has been solved for Java... there is the GNU Compiler for Java, as well as commercial native Java compilers. JNLP is intended to solve versioning problems. I have used it, but never in the presence of versioning problems.
The bigger answer is time. Systems will thrash less as they mature. This is for better or worse, since the ability to change even undesirable features is inversely proportional to the number of dependencies applications have on them.
Now is a good time to bring up a theme of mine: the software world has a few examples of highly dynamic systems; the rest are evolving to become more like them, truly. Now is a good time to point out that highly dynamic systems like Lisp and Smalltalk have a long, proven history of backwards compatibility:
- Because they are mature. They've been around for decades.
- But also because they allow themselves to be amended and redefined down to their core.
If your application requires a feature that comes out of the box in another dialect or from a previous version, chances are good you can take that feature with you to a new dialect or version. If you wish the root class Object had a feature the vendor did not think to include, you can add it yourself just in the applications that you designate.
No comments:
Post a Comment