Security issues of compiling against older JDKs

Answer 1

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.

Answer 2

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.

Answer 3

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.)

Answer 4

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