-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Forslund wrote: | I haven't used python very much, but I don't see the problem with Java that | people are talking about. Switching to different J2EE servers has nothing | to do with Java itself, but with different environments that these systems | provide (perhaps a lack of sufficient standardization in J2EE?). | Let me try another stab at clarification:
If you write just one application and run it on just one application server things are very peachy. As Dave say's an 'environment' builds up around your work as you use bits and pieces from other projects. This is sort of like a linux distribution. The external components were built with their authors 'environment' in mind. You end up having a chain of dependencies. Moving your 'project' to another J2EE environment easily depends upon you being self-contained within the J2EE specification and not having external dependencies. Anyone who has used linux for a few years must be familiar with this story about keeping all your dependencies in order. Most distributions have an elaborate mechanism for checking dependencies and automatically attempting to fix them.
Here is an example:
Recently, I decided to upgrade to Evolution 2. I started looking for the components for my relatively recent Fedora Core 2 distro. Well, in a very little time I discovered that Evolution 2 needed a more recent Gnome then I had. I looked into what that would take and the simplest path was to wait and upgrade to Fedora Core 3 which has all these parts integrated in. Such a massive upgrade of components within my working distribution as it was running was something I did not wish to undertake.
So, what happens in a 'server farm' that services several developer groups and commercial applications? Well, each of them has made assumptions about the 'environment' that surrounds their execution environment. Some of these assumptions are incompatible with each other. Others are just different, i.e. they could be made compatible, but that requires some work on out part, which we find is not warranted for these applications.
Why is that work not warranted? Because every time you go back to the vendor for support, you have to waste effort explaining and proving that your deviation from their 'environment' is not the cause of the problem!
And so I come back to my initial assertion: It is the distribution of all components, integrated by a vendor, needed to support an application that someone has written, which is an essential part of paid for support.
The concept of support for LAMP and LAMJ is based around this concept, I believe. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBkhvjY+HG7UEwVGERAlidAJ4/4u9Gdj1dV09cQhV1EadDvKqgUACeM3II /r8mw9p3++7pV5lv/Suy/Oc= =Ijct -----END PGP SIGNATURE-----
