I'm currently on a project where we are using an older version of JBOSS 4 from about 8 years ago and recently given the task to upgrade it to the latest version. When I discovered all the myriad details necessary to update the code base, it made me question whether java is even an ideal programming environment.
Here's a short list of necessary upgrades.
JMS - originally written in JBOSS proprietary JBossMQ, no longer supported must be rewritten in HornetQ.
Web Services - originally JAX-RPC, no longer supported need new WS conventions
EBJ 2.0 - no longer supported, rewrite to EBJ3
JNDI - to EJB3
XML files - a bazillion to port both JBOSS proprietary and EJB3, etc., etc.
When going over this list it represented a very large significant effort that could last a year.
I found it so frustrating that there wasn't a straightforward migration method, I came to the conclusion that the best method is to get up and running on the new server with the code as it should be represented(WS, EJB3, Messaging) then try to port all the old ****.
If my recollection is right, I remember Weblogic being much more forgiving, or is it?
This project has kind of crushed my rah rah feelings about java being an ideal long haul programming environment when you nearly have to scrap and rewrite your code after only 8 years because of the myriad J2EE changes! Makes me wonder if we wouldn't have better value on something cheap and simply like PHP.
Please weigh in. : )
To start off the conversation i feel that Java EE in earlier times had its set of flaws. In addition to that however, coding applications using proprietary APIs seems like a sure shot way to increase your development efforts down the line should you choose to scale up and move to a different vendor. You are correct in saying that WebLogic is much more forgiving when it comes to backwards compatibility; but i personally would always recommending sticking with the standard APIs than committing to the proprietary ones in case of any AppServer.
The advantage of Java over PHP would obviously be the much higher performance and scalability that it can achieve out of the box. For a quick set of comparisons take a look at the following link.