maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From virg g <>
Subject Re: Multiple JDK versions
Date Thu, 27 Jun 2013 04:33:33 GMT
Thank your all for all your suggestions. I am really grateful to you all.


On Thu, Jun 27, 2013 at 6:51 AM, Mark Derricutt <> wrote:

> 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] .../[**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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message