 |
Java Deployment is a rather large (and ignored) category. There is a lot of hype about the "Write once, run anywhere" motto Sun shouts about Java. What is not commonly discussed is that by adding the indirection layer of the JVM, much of the difficulty of writing code in other languages is transferred to deployment in Java. In C++ for example, you can code directly against the MFC. Then you just drop your .exe down and add some DLLs and the thing runs. Basically, the code is OS specific, but deployment is straightforward. With Java on the other hand, you can use the same compiled code on multiple platforms, but you have to worry about hooking into a VM and the VM version etc. at runtime.
From here, we'll separate the topic between JavaClientDeployment (J2SE), JavaServerDeployment?(J2EE), and JavaMicroDeployment? (J2ME).
rickcarson:
> ... a lot of hype about the "Write once, run anywhere" motto ...
Well, first up that should be "Compile once, run anywhere". Small C programs (which don't twiddle with the OS) for instance are very portable, but you often need to recompile it for the oddities of the target platform (different sizes of ints for instance). "Write once" is hardly compelling since that has existed for many years prior to Java. "Compile once" is very compelling, because you have much better deployment abilities and fewer platform specific oddities to worry about.
The second thing is that anyone who has ever dealt with the vbrun300.dll (and all the different versions thereof) deployment problem on Windows should see the benefit of Java deployment pretty quickly. From a coders point of view you just slap it all in a Jar file and you're away laughing. From the deployers point of view, yes, you do need to make sure they have a relatively up to date JVM.
But that is still much much easier than the different versioning issues you can get with vbrun300.dll. Also the JVMs have very good backwards compatibility, so even if the client chose not have multiple JVMs installed, upgrading to the latest JVM is almost never the wrong thing to do as you are exceedingly likely to not break any other Java program. Whereas with Windows, upgrading a dll is almost certain to cause other applications to fail.
That said, somehow with J2EE the worlds best language for deployment has become a horrible language for deployment - largely because instead of setting down firm standards, Sun decided to let the vendors define their own configuration languages in XML, which virtually guarantees that the EJBs will not be portable between vendors.
|