Ron Wheeler wrote:
So always compile with 1.5 and make a package for 1.5 and copy it to
files with 1.6 and 1.7 names.
If the managers don't know how Java JVM works they will be impressed
by how fast you can deliver new packages in so many operating systems
and really impressed at the speed with which you can bring out 1.8
support.
Well yes generally - however this week I had code that when compiled ON
JDK7 but targetting JDK6 worked fine, but targetting JDK7 failed to even
compile.
This was the in part my discovery of this new javac error message:
[ERROR] .../TransactionFilter.java:[112,11] exception
javax.validation.ConstraintViolationException has already been caught
turns out, javac now enforces/tracks the loss of visibility in catch
blocks, in this case, above the ConstraintViolationException catch block
was one for ValidationException , this is ConstraintViolationExceptions
super class.
However, I was pointing out the just "compiling to JDK5" doesn't really
help much, but you are correct and I got my terms backwards - I refer to
this quote that I posted on my own darn blog ;p
http://www.theoryinpractice.net/post/18036749530/java-has-never-been-future-compatible-and-will
Java has never been future compatible, and will never be. I just want to
make sure that is clear, because if you've been under the impression
that it was 100% future compatible or that there was an implied contract
I can assure you that is not the case. There are numerous times in each
release where fixing a bug will break somebody. It is just the nature,
or physics, of the situation.
-- Richard Bair on bundling a JRE per-application for desktop applications.
If you want to be JDK5 compatible, compile for, and WITH JDK5.
