views:

306

answers:

9

We sell packaged Java web applications to some of our customers. It's basically a collection of servlets, some SOAP web service and some static resources. We don't do EJB nor any other Java Enterprise fancy stuff.

Some of our clients are running IBM WebSphere Application Server v5.1, hence we are limited to Java 1.4 for the run-time and the development. Of course, we would like to do our development using Java 5 (or even better Java 6). Doing SOAP in 1.4 requires an external lib (we use AXIS, but it's aging). We can't use enum, boxing, generics... It's becoming harder to find 1.4 compliant third-party libraries.

The customers are currently satisfied with this old-but-working-well setup. We would like them to upgrade their Java run-time. In this case, it means upgrading to IBM WAS 6.1 or 7.0?

What can we tell them? What's in it for them?

So far I've got:

  1. Better performance as JVM is much more efficient in Java 5 (even better with Java 6). I can't put figures on it, though. Not sure if IBM VM has improved a lot (one of our client is running on AIX).
  2. Support. IBM WAS 5.1 can only be supported through special extended support programs.

They are big corporations, so they plan their solutions more than a year in advance. They select a mature product today and they deploy it years later. The product then has a few months before being end-of-life.

See IBM WebSphere Application Server comparison

A: 

Perhaps because Java 1.4 has reached EOL on 30th Oct 2008. And so, their security can be compromised!.

Show a couple of examples, where, security has actually been compromised due to Java 1.4.

They will be sufficiently scared IMO.

pavanlimo
Except that this doesn't apply to an IBM JVM.
Pascal Thivent
+8  A: 

You could tell them the costs of their decision.

If they continue to choose Java 1.4 then adding a new feature will cost $yyy. If they upgrade then adding the same feature would cost $xxx. Presumably they also have a cost of upgrading their systems. If you can show them that the savings on the newer version of Java exceed the cost for them of upgrading their system then they can see that they will save money if they upgrade.

Obviously it is difficult to give exact values for the development costs, but if you can estimate that development would go for example roughly 30% faster (and therefore be 30% cheaper) on a newer version of Java then you can get a rough figure at least.

Mark Byers
+11  A: 

Java 1.5 has reached end of life November 3, 2009.

So neither 1.4 nor 1.5 are supported any longer which means no security fixes.

So basically the only supported Java platform currently is Java6 (aka Java 1.6)

a_horse_with_no_name
This. There is no platform where developing for earlier than 1.6 makes any sense any more because there's just no support for things that old.
Donal Fellows
This applies to Sun's JVM but the OP is very likely using an IBM JVM.
Pascal Thivent
Those dates are for non-business Java SE. Oracle sells extended supports for businesses. According to http://www.oracle.com/technetwork/java/eol-135779.html#j4b Java 1.4 is supported up to 2018, Java 5 up to 2019 and Java 6 up to 2021.Also, for IBM web Application Server, the Java run-time is part of the product. So if a company negotiates some sort of extended support, it's up to IBM to figure out how they will provide fixes. WAS comes with the IBM Java SR run-time (there something special for Solaris ... I think you may also use Sun Java).
gawi
On more pragmatic ground: When was the last time you absolutely needed a fix in the java run-time? Unless you are doing multimedia, GUI or accessing devices, chances are you found a work-around. Or maybe I'm saying that because I'm mainly exposed to the very mature Java 1.4...
gawi
Speculating: For big organizations, the risk of migrating to java 5 (or 6) might be greater than being unsupported or partially supported for a while. What's important is that the software has been certified to run in a given environment. They need support while they are building the system. The hard part is to make the architecture to work. Afterwards, they can manage. There is always extended support if you are willing to pay. I agree that lacking support from your providers reflects a bad architectural planning.
gawi
@gawi: Big organizations ought to be planning their exit strategies to later versions. Even leaving aside official support, they're going to have problems with hiring developers, and with satisfying user expectations (with the product I'm working on, we're in the process of jumping from 1.4 to 1.6 precisely because of user demands for advanced scripting support). Moreover, sticking with the product to the bitter end is an unwise strategy anyway; after all, it's what's left so many developers suffering from IE6. Plan to migrate (but don't panic over it, of course)…
Donal Fellows
+1  A: 

Tell them about security. I'm not sure if sun still deliver patches for older versions (pavanlimo answer).

Pierre 303
+1  A: 

While I agree with the other answers given, another consideration is have you considered there situation? Have you written the application in such a way that it plays well with others? I've been a system admin for a while now and one of my biggest gripes is the number of development houses that think that we should change our IT environment when they are ready. And of course if there are 2 or more such development houses supplying products to my site then there is conflict.

Have you written your app in such a manner that I could run your choice of Java version and the (pick your number but its likely to be greater than 2) other versions of Java that I require, usually on the same server, to support the other equally important applications? And suggesting backward compatibility is irrelevant - the other vendor will not support me unless I'm on their chosen version.

Karl
Yes. We've been considering the client's situation and we've always made the best we can to fit their requirements. My question could have been formulated: "In September 2010, is it reasonable for a big organization to still require Java 1.4 compliant software?" Big organizations are slow to move to recent technologies and they have plenty of good reasons for that. I was just wondering if our clients were the slowest amongst the slow ones. Note: I have sympathy towards sysadmins and architects. I want our solutions to fit. That's why I'm asking.
gawi
A: 

Why not go to java 6? Both java 1.4 and java 5 have reached their end of life.

fastcodejava
Any reference showing that IBM JVM 1.5 reached EOL. It might be the case, I don't know, but all the posts here seem to miss the fact that the OP is using WAS and an IBM JVM (and his version of WebSphere might not even support a more recent JVM).
Pascal Thivent
+3  A: 

You're in business to satisfy your customers. They have a need (be it real or perceived) to stick with an obsolete platform.

So, say "yes," but let them know you plan to increase your maintenance and upgrade prices for the old platform on a date certain. This is a perfectly justified price increase; you need to maintain expertise and equipment to make sure your code works on an old, unsupported, and conceivably insecure platform. You're delivering real value to them by supporting their current infrastructure.

And be happy you're not in the diesel engine business. If you were, you'd have plenty of customers with world-war-ii era technology.

Ollie Jones
+4  A: 

First of all, the only SDK that is supported with a given version of WAS is the SDK that actually ships with the product (in other words, IBM won't support running WAS on another JDK, if this matters).

Secondly, WAS might actually not even start with a more recent version of the SDK (WAS 6.1 won't start with IBM JDK 1.6 for example).

  • WAS 5.1: J2EE 1.3, JDK 1.4.2
  • WAS 6.0: J2EE 1.4, JDK 1.4.2
  • WAS 6.1: J2EE 1.4, JDK 1.5
  • WAS 7.0: J2EE 1.5, JDK 1.6

So requiring a more recent runtime will probably be synonym of big migration: qualification of the JDK and application server, training of admins, migration of platforms, migration of applications, update of monitoring, deployment tools, regression testing, etc. This is generally a complex and extremely slow process with big conservative companies.

In your case, you could maybe consider branching your software and offer different versions and:

  • only do maintenance on the old version
    • and define an EOL date for the old versions (you can't maintain it Ad Vitam Aeternam)
  • offer new features on the new version only
  • offer more aggressive pricing on the new version

There must be a good reason for your customers to adopt a newer version and it must out-weight the cost of a migration.

Pascal Thivent
Our products are a tiny fraction of what the customers are running. So we don't have that much influence on their web architecture planning. Best we can do is convince them to make the move earlier and maybe a bigger move (why not go to WAS 8.0 in 2012? It will be GA by then). Another option I'm considering is to ask our customers to run our application on isolated servers (e.g. a recent JBoss or event a WebSphere 7.0 if the client is willing to pay). This might be an opportunity for the customer to experiment a bit about new products and technologies.
gawi
I'm retaining the "branching" strategy and "new feature on new version only". Defining EOL date for products you sell is a very important thing however it should be done during the sale.
gawi
+2  A: 

Been there... Clients can be stubborn. I have used RetroTranslator(http://retrotranslator.sourceforge.net/) and Retroweaver(http://retroweaver.sourceforge.net/) to have Java 5 features. Nothing can be done on the performance side though.

As for Java 1.5/1.4 EOL there is Java for Business program for Java customers - they are not EOL if you pay for them...

Daniel Voina