Java Legacy Upgrades
JCrete 2014
Java Legacy Upgrades
| Java Legacy Upgrades | |||
|---|---|---|---|
| Convenor: James Scobbie | |||
Participants:
| |||
Summary:
Why? Not everyplace is always at the cutting edge of technology. Some places stick as long as possible to the same environment with as little changes as possible (for example banks and large public institutions). In these environments there are often strict rules as to which versions of which software are allowed for use. Getting software officially added to these lists may be a long and painful process. It can happen that software products remain in use even after their vendor has declared end-of-life. Developers tend to find a way to work around the strict software control in order to be able to do their work. It may also happen that a security department forces fast upgrades when a software product becomes end-of-life, because if security holes are discovered, patches will not be provided any longer.
Examples In 2012, in a bank which was still running Java 1.5 and Windows XP as platform for its trading system. Management had only authorized Windows XP with Java 1.5 and a specific version of Java 1.6. Applications were running close to their limiti in memory, because of Windows XP is only a 32 bit system. To keep the applications running, heap size would be configured differently for different machines. Users would be expecting to have to restart the application sometime in the afternoon on a busy trading day. Just removing that memory limit saw performance increases. The end-of-trading-day crashes disappeared. The reason to stick so long with outdated products seems to be the fear of change. The stability of staying with the JVM currently in place is valuable. Some not so used features may stop working when moving to another JVM version. If you aren't testing this feature in your automated test suite, or the test suite coverage is sparse, you may not catch the fact that it is not working any longer for months - until some user needs to use it. If you discover that functionality is broken after having rolled out the upgrade, this is a big problem, as often there is no longer a viable rollback available. In another bank, an upgrade from Java 1.5 to Java 1.6 on a 64bit Unix server worked without problems. To test, just normal load and acceptance tests were run. The acceptance tests were partly Selenium and mostly manual testing, pretty informal. Load testing was very well defined using jmeter, which had been used for several years. In another bank in 2014 still using Java 1.6 and Tomcat 6 and no upgrade in sight. Another customer (mid size bank) is looking at upgrading from Java 1.6 to Java 1.7, Java 1.8 being considered as too new. The user desktop is currently running Java 1.6, the developers get Java 1.7 on request. On the Java 1.5 performance problems which could be clearly identified existed. When the software provider was contacted about fixing these problems, their answer was that it would not be fixed for Java 1.5, as the problems no longer exist in Java 1.6. Some banks treat different products very different, for example remaining on the cutting edge of the banking system, but staying with an old Java version. The same people are responsible, but behaviour is different depending on the software product. This banking system it is a bit like SAP, you get the system and then you need to customise it yourself. So every time there is an upgrade the customisations need to be manually migrated the new updated version. Maybe getting new features (for the banking system) is more important than upgrading the JVM, which doesn't get you new features. When you are fully responsible for the operations, you can choose the technology yourself. Management often seems surprised when software products become end-of-life, even if this is announced many months in advance. When then the security section decides that the end-of-life product is taken off the allowed-products-list, engineers may have to scramble to perform an upgrade in a hurry. Asking software product vendors to continue supporting products which they consider end-of-life as a way to keep legacy operations running, may be very expensive (a participant quotes that Oracle requested 100000$ in support costs just to discuss the issue). Miscellaneous
| |||
Recommendations:
| |||
