Did Microsoft kneecap Java, judge asks
-
The way I understand it, all Sun always wanted to do was to ensure the JVM was Java compliant. Sun insisted that anything else shouldn't be called "Java" and I believe they were correct to do just that! "The folly of man is that he dreams of what he can never achieve rather than dream of what he can."
MS's JVM is now compliant, and has been for many years. It's just not the most recent JVM, because sun has enjoined them by law from supporting the most recent JVM. The thing is, Sun settled with Microsoft, and agreed to allow Microsoft to continue shipping MS's JVM until 2008, now they want to change the deal. -- Where are we going? And why am I in this handbasket?
-
In our case. IBM. Webshere coupled with DB2. Its not easy to migrate between Websphere, BEA or Sun One. And as well as having them do half the code, you don't have the in house people who know what the thing does underneath. Just as stuck. It would be a huge project to migrate. Just moving databases is a hassle. One system had to have a change of DB - Sysbase to Oracle because the version of Sybase does not suport Unicode - so if the client did not speak English, they were knackered. Supprisingly even the German clients and other European clients had problems. Discounting a vendor, beacuse of tie-in is stupid. You either comit your strategy to them because they provide the best all round products or not. Not so you can switch to an equally bad platform, or even in this case to one of the vendors you had already assesed, but dropped earlier in the procurment process.
Sorry, but if you feel "tied-in" to WebSphere and DB2 then there is a problem with your design. J2EE's core requirement is one of adhering to standards and all the application server vendors provide implementations which at least support the standards. It is then up to developers/administrators whoever, to decide how much to tweak the code to take advantage of vendor specific functionality but that is their choice. As for being restricted to DB2, there is no reason why you can't configure WebSphere or any other major application server to use whatever back-end database you have, for example, Oracle. The migration issues you talk about and the difficulty of finding the right staff or training them are common to many projects, and are nothing to do with whether J2EE is suitable for your purpose or not. J2EE, although mature, is a developing technology and I don't for one minute want to trivialise the selection and procurement process let alone migration, but what usually concerns we developers and technical architects is what business constraints already exist - what support contracts have our enterprises already got with people like IBM etc. These are the real factors that tie us in to specific vendors, not the technical issues such as platform constraints, etc. For example, as you say "commit your strategy to them because they provide the best all round products" - this is often a pipe-dream for the techies - actually selecting the best product for the task? I've never been involved in a project yet where development have had free rein to use whatever they think is best for the job. There's always some support contract we have to honour, or there's some legacy system that needs to be integrated. Certainly the latter is well handled by J2EE, and is perhaps one reason why J2EE still commands such respect in the back-end server market. "The folly of man is that he dreams of what he can never achieve rather than dream of what he can."