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.
Related
in detail:
if we use public API for example, write java program for example , in JDK 1.4, if should run correctly in all version above it. in all update version in 1.4, in 1.5, 1.6 and 1.7?
Also , what is the combability rule between different updater versions , for example 1.6.22 and 1.6.23 what can not be changed, what can be changed?
of course, public API definition can not be changed, how about others? javadoc? internal API definition, implementation?
It will be great if someone can point a concrete official document on this topic. thanks,
there is one example in java document bug, that they intended not to change between updater version. see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6475885
this should be one of its big picture, but we better to have a complete description on this.
need to know the complete story so that we feel safe to upgrade to bigger version.
The general rule is that any code that is written and compiled against the APIs of Java X should run on Java Y where Y >= X.
There are occasional exceptions to this; e.g. where the application's behaviour depends on some undocumented behaviour (typically a bug) in Java X that was corrected in a later version.
AFAIK, there is no single document that lists these incompatibilities. The release notes for all of the Java major releases include a list of changes that could result in breakage of older code.
Having said that, the prudent approach is make sure that you thoroughly test / retest your software when you upgrade to a more recent Java release. And if your software is shipped to customers / clients, let them know if / when it is safe for them to upgrade, and (if necessary) provide them with fixes for any problems that your testing has uncovered.
need to know the complete story so that we feel safe to upgrade to bigger version.
Feeling safe is beside the point. Thoroughly test your application on the later version. That is the only practical solution. And that would be the case even if each and every incompatibility was exhaustively documented.
Think about it. How can you know for sure that your application won't somehow be affected by change XYZ? Or that some 3rd-party library that you use won't be affected? Answer: you can't.
No manner of complaining here that you think that Oracle should handle this issue differently is going to make any difference. Not that I think that they could handle this better without changing their business model. How much would you be prepared to pay for a Java platform that guaranteed there were no version compatibility issues?
This is not a full answer but I will add that will-it-run and will-it-compile are two different things. Keywords introduced in 1.5 will prevent some 1.4 code from compiling but the byte code will run just fine.
Almost anything can be changed between versions there are no set rules for such things. Use the release notes to publish changes or review them between versions such as:
http://www.oracle.com/technetwork/java/javase/jdk7-relnotes-418459.html
Usually only bug fixes are the cause of minor versions (like you detail 1.6.22 - 1.6.23), or simple enhancements which are only ever good things. When the major version numbers change then you can expect more major changes but you still "hope" for reverse compatibility.
I don't think JDK ever changes an API that breaks backward comparability (except unintentionally).
They introduced #deprecated tag in the very beginning, probably thinking that they may need to do some API cleanup in future. But that never happens. No #deprecated API has ever been removed, or behavior changed.
if we use public API for example, write java program for example , in JDK 1.4, if should run correctly in all version above it. in all update version in 1.4, in 1.5, 1.6 and 1.7?
See this table, that shows breaking changes in public jdk APIs
See these official documents about versions compatibility:
Java SE 7 and JDK 7 Compatibility
Java SE 6 compatibility with J2SE 5.0
Incompatibilities in J2SE 5.0 (since 1.4.2)
Java SE 1.4.2 Compatibility with Previous Releases
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.
Are there any known security issues with compiling against an older JDK? For instance lets say Oracle decides to change something in one of their implementations that was to close a security vulnerability. If we compile against the older JDK would we still be vulnerable?
EDIT
We are running against JDK 6 and we compile against Java 5, which is the crux of the issue I was attempting to get at for any one else whom sees this question. For the sake of completeness lets say that in the ant build we target 1.5
EDIT 2
Additionally there is the issue of calls in the application that potentially have private APIs/implementations that are not directly accessed.
Aside from some very hypothetical niche situation that hasn't ever happened yet, the only thing that matters is the version with which the application is executed.
I don't think there are any known security issues that have been "fixed" with #deprecated, because that wouldn't really be appropriate.
There are two issues at play here:
1) You can have your Java compiler produce binaries that are binary compatible with older versions. That affects the language features available to you.
2) You can compile against the Java system libraries of an older version, and that will affect what methods/classes are available, as they are always adding new ones.
But neither of these affects the security of your application. What matters is the runtime version with which the application is executed.
Observe that security problems are fixed between updates, not the major versions, which introduce changes in the language itself. For example, Java 6 is currently at update 21. Java 6 update 19 fixed stuff that was vulnerable in Java 6 update 18.
When Java 6 update 19 was released, updates were released for Java 1.5 and Java 1.4, to fix the same issues in Java 1.5 (update 24) and Java 1.4 (update 26). See the security baseline table here: http://www.oracle.com/technetwork/java/javase/6u19-141078.html
If you compile against JDK 1.5:
Users that are using JRE 1.5 will be vulnerable
Users that are using JRE 1.6 will not be vulnerable
The application will run using the libraries of the users's runtime. Since the vulnerabilities are fixed in Oracle's library, which is now being called by your application, the security vulnerability will be alleviated.
However, since you compile against 1.5, your users will be able to use 1.5. Do anything you can to avoid the vulnerability; if you can't avoid it, detect the JRE version at startup and issue an alert if apporpriate.
If Oracle changes an API (not an implementation) to promote security, they will probably add an #Deprecated annotation but preserve backward compatibility for some time. The annotation will trigger a warning in a newer compiler, but not in yours, and not in the compiled program. (Unless Oracle decides to throw an exception or log a message from the deprecated method.)
I would say that those unfixed vulnerabilities are still there, and you and your app are still at risk.
It'd be the same issue as running with an old, unpatched OS or browser.
It's a good incentive to migrate up to newer JVMs.
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.