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:
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).
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
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)
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.
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.
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.
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...
Tell them about security. I'm not sure if sun still deliver patches for older versions (pavanlimo answer).
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.
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.
Why not go to java 6? Both java 1.4 and java 5 have reached their end of life.
Related
I have an old web application compiled with Java 5, which for various reasons is not easily upgradeable to a newer version of Java, and which currently runs under Java 5.
My question is whether running the old web application with a newer version of Java (without recompiling the application with the newer Java version and assuming this will not lead to runtime errors) going to mitigate in any significant manner the security risks of the older Java runtime environment?
(I am speaking specifically of security risks related to the older Java runtime environment, I am aware of the fact that passing to a newer Java version will not reduce security risks related to XSS and the like).
Generally it is best to keep your Java runtime up-to-date. If there are any security risks mitigated by upgrading depends on the application, of course. A "Hello World!" application is likely not to be affected, as it has no security requirements, no attack vectors and doesn't use much runtime components anyway (attack surface).
However, a web application commonly runs on an application server, which will likely use Java for its TLS implementation. That means that it is likely that your TLS implementation has not received an upgrade in years. Although Java has some advantages compared to C thwarting some attacks, other vulnerabilities will certainly be present. For instance, Heartbleed is extremely unlikely to be an issue because it depends on buffer overruns, and Java has internal protection against those. PKCS#1 v1.5 padding oracles are likely to apply because it depends on the actual implementation.
As the Java executable itself is not particularly riddled with easy to exploit bugs, it mainly depends on what functionality is used from the runtime classes of your server, libraries and application (in that order, the server is much more likely to have a large footprint). Upgrade your Java version and your server + libraries. Some utility libraries may have less priority depending on their functionality, but stay vigilant. You don't want to have a vulnerability if e.g. Apache Commons Codec has sprung an issue.
Even more important: create an update and upgrade strategy for your system and adhere to it. The amount of testing depends if you have to update or upgrade your system; if well implemented you could go for automated testing for updates and do a full round of testing for upgrades. Hopefully the libraries use semantic versioning so upgrades can be distinguished from updates.
If running it on newer versions won't lead to runtime errors depends on the application; it won't if it was build with Java portability in mind, in all likelihood. It is however possible to abuse the Java language to such a degree that it will fail. For instance, I've seen an application crash from one runtime to another that incorrectly implemented equals while that element was kept in a list.
For such an old application I think it is time you a full round of testing and possibly a code review to assess if compatibility issues are a topic or not. I've had Java 1.2 apps run without a hitch, but as stated, it depends on how the application was programmed. I'd certainly recompile the classes (where possible) to the latest version, both for compatibility and performance issues.
You may first want to migrate to Java 8 before going to Java 11 (both are long term support releases). Java 8 is end of life, but you may want to do a double step because you've been so far behind. Probably that Java 8 version is then just for a short functionality test.
You're probably already need licensing for your Java installation, but I'd make sure that you cover things commercially as well. With Java 8 and 11 there should be a few options worth perusing.
Note that Java 10 onwards is 64 bit only. I've seen 32 bit versions of Java 10 from other vendors, but I'd not upgrade to those as you'll put yourself in another corner to get out of.
Is it best practice to develop and deploy on the EXACT same JRE/JDK versions (assuming you can control both ends)? Say you are running JDK 7_45 in production but have 7_51 you your development box. Is that potentially problematic - in your experience? I'm guessing the best practice would be to have them match but just wondering how problematic it could be assuming you are at least using the same major release. I suppose this also goes towards backward compatibility of JVM minor release versions. In the typical user space, I could be running Java apps built over time using many different Java development version JVMs yet all 'should' be expected to run on any JVM version. Would have to 'expect' that since I cannot obviously control the user's installations. My question is more related to the fact that I AM able to control both ends (dev and prod) so would it be wise to use the same JVM/JDK versions? Seems like the obvious answer is YES - use the same versions - if you can.
Generally, developers tend to have the latest version of the JRE/JDK installed on their development environments (Windows/Linux/OSX). This is fine, as long as you ensure that the program will run on older versions as well. So, you can develop on one version and use different version on production, as long as you extensively bug test with the older version to allow for backwards compatibility, or specifically state you are requiring a newer version of Java than is available on the user's system.
Where can I see statistics about the most used Java versions?
(I want to develop applications that will run on most systems)
According to StatOwl, Java 6 has reached a 70% adoption rate.
Version 1.6, update 11 enabled background upgrades so it will always be current. 70% of java installs are version 1.6. Stick with 1.6
http://www.statowl.com/java.php
http://www.oracle.com/technetwork/java/javase/downloads/index.html
Unfortunately a high percentage of system have very old versions of Java or no Java at all.
I suggest you develop for Java 5. Any system which doesn't have this at least probibly should have it installed.
You can make use of Google trends, they have a nice graphical view as well.
It wont show you the most used, but it will show you the most popular according to Google searches etc.
Java 5 has been deprecated for a full year now at this point, leaving Servers that still run it at a full year of security issues that are not patched, and never will be. I'd say stick with Java 6. We don't write Software with Windows 95 or OSX 10.3 in mind either, do we? Sometimes it is time to tell the users to update their software.
Java Tools and Technologies Landscape Report 2016 (Zeroturnaround): https://zeroturnaround.com/rebellabs/java-tools-and-technologies-landscape-2016/#java-versions
Java version and vendor data analyzed 2017 (Plumbr): https://plumbr.io/blog/java/java-version-and-vendor-data-analyzed-2017-edition
Is there some statistic on how widely people use various JRE's? I'm asking, because I created a program (using JDK 1.6), and found that it would not work on JRE 1.5 and older. So, do I need to bother making it compatible, or maybe the percent of JRE 1.5 out there is too small?
Here is some stats:
http://www.statowl.com/java.php
Don't really know how it's calculated... I think come from users browser, but don't know which websites.
You need to have your JDK emit bytecode for older JVMs with the -target SDK_VERSION argument to javac. Bytecode from one version of the JVM is not compatible with an older release of the JVM.
Thanks to comment
The above only works if you are not using functionality that older JVMs don't have, for example, if you took advantage of the Java Desktop API, which was introduced in 1.6, you wouldn't be able to target an older JVM anyway.
I won't throw statistics your way, I don't really know what your application is/does/who it's intended for, but there are companies and people who still use older JDKs - perhaps due to heavy investment in some specific release of the JVM and it would require significant time and testing to ensure that moving to a newer version does not break their existing software/code, or perhaps some software strictly mandates it. I worked with software from a company (which shall remain unnamed) that ONLY wanted a specific patch revision of an older JVM - their software refused to work on anything newer.
Um yes plenty of enterprises use earlier versions of Java. You simply need to decide what your lowest level target JVM is. Don't forget you can use the -source & -target parameters to specify the type of source code and byte code compatibility with earlier versions.
I don't know of any statistics, but for what is worth I am certain people use Java 1.5. If your app is geared toward general public, I don't think you need to bother, but in specialized environments it might be.
If your application will be for consumers, you will probably be fine relying on 1.6.
Most places that are still running 1.5 are for business applications that have not been updated.
If you're not using any Java 1.6 specific features, you can pass a command line argument to javac to target the 1.5 framework. The argument to add is -target 1.5. Obviously this wouldn't work if you're using any new features shipped with 1.6.
We provide a popular open source Java FTP library called edtFTPj.
We would like to drop support for JRE 1.3 - this would clean up the code base and also allow us to more easily use JRE 1.4 features (without resorting to reflection etc). The JRE 1.3 is over 7 years old now!
Is anyone still using JRE 1.3 out there? Is anyone aware of any surveys that give an idea of what percentage of users are still using 1.3?
Sun allows you to buy support packages for depreciated software such as JRE 1.4. For banks and some other organizations, paying $100,000 per year for support of an outdated product is cheaper than upgrading. I would suggest only offering paid support for JRE 1.3. If anyone needs support for this, they can pay for a hefty support package. You would then shelve your current 1.3 code base, and if a customer with a support contract requires a bug fix, then you could fix the 1.3 version for them, which would likely just mean selectively applying a patch from a more recent version.
Even JDK 1.4 reached the end of its support life in Oct 2008. I think you're safe.
But don't take it from me. The people that you really need to ask are your customers. Maybe putting a survey up on your download page and soliciting feedback will help. If no one asks in three months, drop it.
Why not have your program report back what version of Java it is being run with. This will give you an idea of your user base.
I highly recommend dropping support for Java 1.3, and instead of doing a minor upgrade to Java 1.4, why not use Java 1.6? There have been massive improvements since 1.3. You really are missing out.
End-of-life is normal part of software's life cycle.
The real question you should ask/answer is whether you have a compelling business need to add features to the "old" versions. If not, you can continue to offer it for customers who need it -- but encourage everyone else to take the latest & greatest which requires 1.4 (or 1.5/1.6).
It's difficult to give figures for what companies use internally. There do exist figures for browser plugin installation, but Sun's figures are confidential.
1.3 support stopped some time ago (Solaris 8 vintage support dragged on for a bit). 1.4 has completed its End of Service Life, but is likely to be supported under Java for Business for yonks. IIRC, if you try to download 1.4 from the archives at sun.com then you are asked for some information such as an e-mail address. 1.5 is more than half way through its service life (but its still quite common on Macs).
It's not that difficult to use 1.4 features optionally. You just need to load one class via reflection (or just package it differently) and then have a 1.4 and 1.3 implementation of a light abstraction over the new features.
Why not only do critical patches for 1.3 & 1.4 if anyone actually requests them and do all new releases on 1.5 - the current oldest version supported by Sun?
I was developing with jdk 1.4 for a long time while jdk 6.0 was out. We couldn't upgrade(clients this, servers blablabah). At some point, we just upgraded without talking too much about it. Clients upgraded without being annoying, "this upgrade will fix lots of security holes, many bug fixes, improved performance :-)".
Right now, I try to keep my code compatible with jdk 1.5, I have no concern at all for people running 1.4 and below. At some point, they'll understand that it is in their best interest to "try" upgrading.