Is there any benefit to upgrading Java 7 compiled code to Java 8?

Question

If I understand the question correctly, you want to know if the bytecode produced by javac will be "better" in Java 8 than in Java 7.

The answer is probably not, they constantly fix bugs in the compiler and that sometimes leads to more efficient bytecode. But you will not see any significant speedup from these fixes for Java 8 as far as I can see, the changelog only lists 2 major changes between versions.

The oracle website is terrible and I can't seem to get a list of bugfixes related to javac between versions, but here is a non exhaustive one from OpenJDK. A majority of the ones I can manage to find are fixing errors. So by updating to Java 8, there is a chance it wont compile any more due to javac more correctly following the JLS and there will be very little to no "improvements" to the bytecode.

The main benefit is that Java 8 has the latest bug fixes where as Java 7 isn't being publicly updated.

Also if you are going to run code on an Java 8 JVM, you may as well have just one version of Java installed.

Java 8 might be faster, and it has better support for new features like G1. However, it might be slower for your use case so the only way to know is to test it.

Is there any technical benefit to upgrading the compiled code to the latest Java 8 JDK?

If you are asking whether there is any benefit in re-compiling Java 7 code in a Java 8 compiler, the answer is; almost nothing.

The only subtle difference is that there have been minor differences to the Java API, so there might be very subtle differences the Java 8 compiler might find that the Java 7

Other minor differences are the magic number at the start of the file, possibly the order of the constant pool. The byte code is basically the same, even the support for invokedynamic which was added for lambdas existed in Java 7 but just wasn't used that way.

It could help by creating awareness.

When you switch to Java8, you might find additional warnings being emitted by javac. Example: type inference has been greatly improved with Java8. And that could eliminate the need for @SuppressWarnings annotations in your current code base (and when such annotations are no longer required, the compiler warns about that).

So, even when you don't intend to modify your code base today, switching to Java8 could tell you about such things. Increasing your knowledge can help in making informed decisions.

On the other hand:

• I saw some questions here about (rare) situations where Java8 refused to compile Java7 code. So, switching to Java8 also carries a (minimal) risk of running into that kind of problem.
• And: even when you don't intend to touch your code base today, there is a certain chance that you change your mind later on. And then, when not paying attention, you might exploit Java8 features. Which could complicate "field updates"; as you now have two versions of your source code to maintain!
• Then: in case you have customers running the product using a java7 jre; you have to be really careful about the binary fixes you give to them. We have such a setup; and I have wasted time more than once because I accidentally put a single Java8-compiled class onto a Java7-driven test system. That simply can't happen when your dev and test/customer setup is all Java7.

Long story short: there are a few subtle advantages, and certain risks (where the significance of the risks mainly depend on your overall setup).

I would do for at least these facts.

1) HashMap internals (it is faster under jdk-8)

2) Lots of bugs fixed that might be transparent for you (runtime optimizations) that will make your code faster and better without you actually doing anything.

3) G1 Garbage Collector

EDIT

From a technical point of view this sounds more like something to do with Ahead of Time Compilation or something that a compiler might improve by analyzing the code more. As far as I know such things are not done in java 8 compiler.

From a developer point of view - there are plenty. Increased productivity is the most important one for me.

EDIT 2

I know only two points that matches your second query:

–parameters

to preserve the method parameter names.

-profile

Called Compact Profile Option for a smaller footprint.