2

On our project it was decided to upgrade to java8. However it seems not quick deal as we're using Spring 3.1.x, Tomcat 6.x, PowerMock tests and other legacy stuff. In order to quickly do it we have only one solution compile our project against Java 7 and run it on Java 8.

I know that "is something compiled as example for Java 5" then it can be safely used on any Java runtime starting from Java 5 and up, but it will fail with a "unsupported major class version" error on Java 1.4 runtimes or even below.

Is that a good practice at all ? Especially I am interested in a good references that it can be safely used or understand the risk against it.

Did anybody face with some problems ?

user1459144
  • 4,439
  • 5
  • 28
  • 35
  • In this question I am trying to understand whether it's an common way to have such difference (whether it's a common solution) or hear if smb. had some problems. – user1459144 Mar 26 '15 at 13:47
  • Short answer: it's almost always fine, for bigger systems make sure to test them extensively. One common source of problems is code that depends on the order of HashMap iterators (which are undefined but *usually* stable given the same input and the same JDK version). – Joachim Sauer Mar 26 '15 at 13:47
  • @user1459144 "Good practice" is subjective. But we can more easily answer what works and doesn't (hence the duplicate question). – Duncan Jones Mar 26 '15 at 13:48
  • @Duncan what risks will we have ? in case no risks probably it will be good to provide some analysis reports that such solution works well for known big projects etc. – user1459144 Mar 26 '15 at 13:54
  • 1
    That’s what happens implicitly when the user updates the JRE and runs the unchanged applications. It’s not “good practice”, it’s just what backwards compatibility is all about. – Holger Mar 26 '15 at 13:56

0 Answers0