128

I have a old application written using Java 7. It runs fine in a Java 8 JRE. I do not plan on rewriting any of the code to make use of Java 8 features. Is there any technical benefit to upgrading the compiled code to the latest Java 8 JDK?

To be clear, the code is currently compiled with Java 7 and already running with the latest Java 8 JRE. It should already benefit from the Java 8 runtime improvements. This question is whether any benefits would be gained by compiling with version 8 and running with Java 8 compiled byte code.

Also, I am not concerned with non-technical benefits such as developer productivity. I think those are important but not the point of this question. I am asking for the sake of production code that has NO development team. It is purely in maintenance mode.

Rakete1111
  • 47,013
  • 16
  • 123
  • 162
g8torPaul
  • 1,193
  • 1
  • 7
  • 12
  • 2
    Just to be clear. The code already runs with the latest 1.8 JRE and therefore has all of the latest Java 8 bug fixes and runtime performance improvements (to my knowledge). – g8torPaul Feb 02 '17 at 14:23
  • @g8torPaul so your question is to take some java 7 code and compile it with java 8? running still under java 8 right? – Eugene Feb 02 '17 at 14:24
  • 4
    This is a question probably more about bytecode being outputted by the compiler. Maybe make that a bit more clear in your question. – M Platvoet Feb 02 '17 at 14:25
  • @Eugene Yes. Just recompile the code and continue to run it in Java 8. I think there are some advantages, such as bringing on new developers for bug fixes, since most developers are developing in version 8 right now. But I am specifically looking for technical benefits. – g8torPaul Feb 02 '17 at 14:27
  • 2
    So improved developer productivity is not relevant here? – Mick Mnemonic Feb 02 '17 at 14:28
  • 8
    How can "I do not plan on rewriting any of the code" be not clear I can't believe. – eldo Feb 02 '17 at 14:28
  • 3
    This may be somewhat related : http://stackoverflow.com/questions/21732290/java-cross-compilation-benefits-of-latest-jdk – Arnaud Feb 02 '17 at 14:30
  • @MickMnemonic Yes. I am not concerned with developer productivity. I asking for the sake of production code that has NO development team. It is purely in maintenance mode. – g8torPaul Feb 02 '17 at 14:32
  • 2
    @Berger Yes! We need an answer like that but 1.7 to 1.8 version. – eldo Feb 02 '17 at 14:34
  • 1
    @g8torPaul, okay, I undestand. But still, I think that "in maintenance mode" and "do not plan on rewriting any of the code" are a bit contradicting. If you need to provide bug fixes, you might need to refactor existing code and making use of Java 8 features such as lamdbas in these occasions could be quite useful. So even if there is no "technical reason", it might still be a good idea to upgrade. – Mick Mnemonic Feb 02 '17 at 14:48
  • 1
    @g8torPaul : Also have a look at the Compatibillity Guide for JDK 8 : http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html – Arnaud Feb 02 '17 at 15:18
  • 1
    A starting point would probably be to inspect both [Java7](https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html) and [Java8](https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html) specifications for the class file format. Both documents are pretty long though, and there seems to have been a bunch of re-phrasing in Java8 that makes simply 'diffing' the 2 not yield much useable results. – Jorn Vernee Feb 02 '17 at 16:28
  • you will lose the possibility to run it on JRE7 :) – AdamSkywalker Feb 02 '17 at 18:29
  • 1
    I think this boils down to "are any of the new Java 8 bytecodes used when compiling Java 7 compliant code" – CAD97 Feb 02 '17 at 22:37
  • Not an answer to the direct question, but one thing to watch out for if you do try this: Sometimes the API changes between major versions and can cause problems depending on your usage. For example, we had an issue moving from Java 6 to 8 regarding time zone parsing syntax changes; nothing that couldn't be fixed but code did have to be changed (even though it was just a line). – Jon Adams Feb 06 '17 at 18:31
  • @GhostCat - I have been thinking about that the last few days. The highest ranked answer at the moment seems correct. However, I was waiting to see if anyone chimed in with any new hard evidence. I have accepted the answer. – g8torPaul Feb 08 '17 at 16:02

5 Answers5

83

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.

Lii
  • 11,553
  • 8
  • 64
  • 88
Andrew
  • 13,757
  • 13
  • 66
  • 84
  • 4
    Thanks, I have reviewed some of the list on OpenJDK and nothing really stands out there except that it appears they have improved the performance of javac. I agree that it is next to impossible to do a reasonable search of fixes/features between version of Java on Oracles website. The format of the release notes for each version isn't even consistent. My gut tells me that there is no technical benefit to compiling with JDK 8 vs JDK 7. – g8torPaul Feb 02 '17 at 19:01
  • 1
    @g8torPaul unless you are going to use features only available in Java 8, e.g. lamdbas/streams – Peter Lawrey Feb 03 '17 at 09:08
21

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.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • 8
    Correct me if I'm wrong, but OP asks about recompiling the code with Java 8, whereas your answer is about whether to use Java 8 for executing it? – tobias_k Feb 02 '17 at 14:19
  • 5
    I am currently running under the latest Java 1.8 JRE. All of the bug fixes and internal Java code would be provided by the JRE. I don't think this addresses my question. – g8torPaul Feb 02 '17 at 14:21
  • 16
    This simply does not answer the question. If it's "almost nothing" please clarify what the difference is. Otherwise it's just speculating – M Platvoet Feb 02 '17 at 14:38
  • 1
    @Peter Lawrey, You say that ".. the answer is; almost nothing". Do we have any evidence to support that? BTW, I would tend to agree with you. – g8torPaul Feb 02 '17 at 14:39
  • 2
    @g8torPaul Java 8 is designed to be backward compatible with Java 7 and if you are not using any of the features of Java 8, it should produce almost exactly the same byte code. – Peter Lawrey Feb 02 '17 at 14:54
  • @PeterLawrey Is that the case for all of the jdk versions? As in, if I compiled Java code in jdk1.5, and don't use say something like generics, or anything new (for that time), would it produce nearly the same bytecode as 1.3? – Honinbo Shusaku Feb 02 '17 at 20:03
  • 1
    @Abdul 1.5 implemented inner classes a little differently to 1.4 though I don't think 1.3 had them. – Peter Lawrey Feb 02 '17 at 21:29
  • 1
    @AndrewMorton the magic number will be different. Incedental features like the order or constants in the constant pool might be different. – Peter Lawrey Feb 02 '17 at 21:30
  • 1
    @Abdul one difference in 1.5 is that adding Strings used StringBuilder instead of StringBuffer. – Peter Lawrey Feb 02 '17 at 21:31
  • @PeterLawrey Understood. I had a misunderstanding of what "Java is backwards compatible" meant – Honinbo Shusaku Feb 02 '17 at 21:55
21

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

GhostCat
  • 137,827
  • 25
  • 176
  • 248
  • 2
    One example of such a rare "Java8 refused to compile Java7" problem: http://stackoverflow.com/q/41590024/2513200 (a known issue of the Oracle Compiler only affecting Java 8, but neither 7 or 9) – Hulk Feb 06 '17 at 10:36
8

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.

Eugene
  • 117,005
  • 15
  • 201
  • 306
  • 27
    Wouldn't just _running_ under Java 8 already give these benefits though? The real question seems to be, "can I write something in Java 8 that works better than the Java 7 equivalent". – Jorn Vernee Feb 02 '17 at 14:20
  • 8
    I am currently running under the latest Java 1.8 JRE. All of the bug fixes and internal Java code would be provided by the JRE. The Garbage collector is also part of the JRE. I don't think this addresses my question. – g8torPaul Feb 02 '17 at 14:21
  • 8
    @JornVernee OPs explicitly said that he does not want to rewrite anything, so the question, as I understand it, is more like "can the Java 8 compiler do any tricks the Java 7 compiler can't do" – tobias_k Feb 02 '17 at 14:21
  • 2
    @JornVernee The Question is, if code written in Java 7 and compiled in Java 8 executes better then the code compiled in Java 7 – EarlGrey Feb 02 '17 at 14:21
  • @tobias_k @EarlGrey Yeah that makes sense... I guess the phrase "...upgrading the compiled code to the latest Java 8 JDK." is a bit unclear to me. Is there even anything you _can_ do with already compiled `.class` files (in the way of upgrading). – Jorn Vernee Feb 02 '17 at 14:26
  • 6
    Does not answer the question and merely speculates it hasn't improved. – M Platvoet Feb 02 '17 at 14:39
  • @MPlatvoet agreed it was unclear, added two points (the ones I am aware of) that make the javac compiler a bit better then the 7 version. – Eugene Feb 02 '17 at 14:53
  • 1
    maybe it's time to completely update the answer, because your 3 points are totally unrelated to the question now – AdamSkywalker Feb 02 '17 at 18:21
-1

If you have no other reasons to recompile your application, then it probably does not make much difference, as stated in the accepted answer.

However, if you have to recompile it even only once, consider this:

  • Your application source code is compatible with Java 7, and most likely 8 too;
  • In the eventuality that the code does not compile with Java 8, it will probably not compile either with a Java 8 compiler in Java 7 source compatibility mode (-source 7 with javac);
  • Your developers and CI will need to run unit and integration tests against a Java 8 runtime to be as close as possible to the production environment. Developers will also need to run the application on the same Java 8 runtime when running it locally;
  • It is more difficult to compile with a JDK 7 and run with a JRE 8 (in the same build process, or in the same IDE) than doing everything with the same version;
  • There is no benefit of using -source 7 instead of -source 8 if you compile with a JDK 8 and your target runtime is Java 8;
  • Using -source 8 guarantees that the developer is using Java 8 (or later) for both compilation and runtime (as it enforces -target 8).

In conclusion, don't recompile it if you don't need to. However, on the first occasion you have to recompile (due to code changes), switch to Java 8. Don't take the risk of having a bug due to environment mismatches, and don't restrict the developers without a good reason.

Didier L
  • 18,905
  • 10
  • 61
  • 103
  • Second bullet point is not correct. Your post is self-contradictory at several points. – user207421 Feb 08 '17 at 21:19
  • @EJP Second bullet point is more of my experience, but do you have an example which compiles in JDK 8 with `-source 7` but does not compile with `-source 8`? Also, could you please indicate the contradictions as your comment is not very constructive as such… – Didier L Feb 08 '17 at 21:29