Could you elaborate on which issues you ran into. We are in the process of upgrading to from jdk7 to jdk8 (at-least for the services we see having a long lifespan) and it would be great to hear some real world experience.

Java 6 was released in 2006. Java 7 was released in 2011. Java 6 was EOL'd in 2013. That seems like a long enough timeline for people to have migrated sensibly.

I'm crying laughing right now. Businesses rarely see the advantages of upgrading something "Already Works". Now you could agree (and be right to a point) that it's the responsibility of developers/ops/etc to convince the business side but in my experiance the people writing the code are far enough detached from the people making decisions that they have next to no voice. My last job I saw an upgrade from Drupal 5 -> 7 and currently I work on framework that was last actively developed on 5 years ago (never versions have been released, they are now 2 major versions ahead of us which is a lifetime in PHP as of late with all it's changes). A lot of times you come into a place that is so far behind that to move up to the newest version would be equivalent to a full re-write (whereas moving up over time would have been possible had there been a bigger push for it).

I don't know if that contradicts what I said. If your upgrade strategy is "never," then no matter what the long-term support window is, you're going to go over it. If it's "only when I have to," making one obvious marker for when one might "have" to sooner rather than later keeps some people from falling so far behind that "to move up to the newest version would be equivalent to a full re-write."

Why would you care about end of life then, it works as is.

2 years is not a long time to migrate large system that works fine except for minor maintenance. It isn't just time, it is finding budget for churn work.

> We have a project three months on so far making our Java7 code work with Java8.

What crazy thing were you doing that required a 3+ month rewrite?

I had one experience in java6 to java7 migration. The issue was a partly overriding of a list implementation. That list implementation was used in a for loop. The way the for loop was iterated across over was different in the two java versions.

e.g.

  for(Object a:list){
    a.doSomething();
  }

In java6 it was equivalent to

  for (int i:i<list.length();i++){
    list.get(i).soSomething(); 
  }

In java7 it was done like this

  Iterator iter = list.iterator();
  while(iter.hasNext() { 
    iter.next().doSomething(); 
  }

The original programmer had overridden the get method but not the next method in the iterator method. (Actually just called toLowerCase on a list of strings).

Oracle did nothing wrong, the programmer only partly overriding the list implementation was broken. This kind of programmer error is too common and is normally the reasons that upgrades become an issue, i.e. its the equivalent of using undefined behaviour in C and then scream when your compiler upgrade burns down your house.

Ah, this is why I never see these kind of issues. He subclassed a list just to modify the list to return lowercased output always, preventing any method of ever accessing the original multi case text.

At any rate, all of the java 6/7 code I've ever had has ported to java 8 without any changes. Assumed it was the normal experience.

In my case in 500,000 lines of code or so it was the only example. Nothing like the stuff I found in a different job going from 4 to 5! The enum keyword was painful! and then we found class names in the database instantiated at runtime with reflection once the migration was "finished". Some programmers are mean to those who come after.