What are the performance implications of using a JAR with an older language level in a modern project?`

Question

I work in a corporate environment with several widely-used, infrequently-updated Java libraries in its repositories. Some of the libraries quite old, and were compiled using language levels as far back as JDK 1.5 (Java 5).

Nearly all of our actively developed Java projects are using Java 8 or newer, but they are dependent on one or more of the JDK 1.5-level JARs.

Are there performance penalties for using JARs with very old bytecode versions? Can the modern JIT update old, inefficient bytecode on the fly?

Answer 1

Remember: Write Once , Run Everywhere! In your case, the slogan really fits.

Generally, there's no reason to touch old Java code if it's doing its job.

The bytecode hasn't changed much over the years, the bytecode instructions understood by a Java8 JRE are 99% the same that were present already in Java2 - there were very few additions, so from that point of view there's no need to update the old bytecode. It will run even faster under Java8 than under Java5, as both the JRE with its HotSpot engine and the class library have improved a lot.

The changes in the class file format are more about metadata, and the class-file version number also makes sure that you don't run a Java8 program under a Java6 JRE where half of the Java classes and methods are missing.

What changed a lot, is the Java class library and the source language. And as an old library couldn't know about the changes to come later, it might turn out to be less efficient than a newly-written version using all the features from later Java releases. But my guess is that the performance gained by a redesign of the old libraries isn't worth the effort.

And finally the general advice on performance questions:

• If it ain't broken, don't fix it (= don't optimize before you know that you have a performance problem).

• Before optimizing, use a profiler to find out where your bottlenecks are. Believe me, the bottleneck is hardly ever where you expect it.