maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <>
Subject Re: Multiple JDK versions
Date Thu, 27 Jun 2013 00:27:04 GMT

In telecommunications <> 
and computing <>, a product or 
technology is *backward* or *downward compatible* if it can work with 
input <> generated by an 
/older/ product or technology.^[1] 
<> If 
products designed for the new standard can receive, read, view or play 
older standards or formats, then the product is said to be 
backward-compatible; examples of such a standard include data formats 
and communication protocols 
<>. Modifications 
to a system that do not allow backward compatibility are sometimes 
called "breaking changes <>."

Java has a good history of backwards compatibility.
Forward compatible is almost impossible for any designer (Tiff standard 
is the only exception that I know and they only did it by defining that 
there will be no other version that 42)  and Java is not.

You can safely compile with Java 1.5 and run it on 1.6 and 1.7 run-times.

If the code is written for 1.6 and uses a 1.6 feature then you cannot 
compile it in 1.5.
If the code is written for 1.5, you can compile it with 1.5 compiler (or 
1.6 or 1.7 and 1.8, etc) and run it on 1.6 or 1.7 with no difference 
except better performance.

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.


On 26/06/2013 4:52 PM, Mark Derricutt wrote:
> -1 on this. The JDK is *not* 100% backwards compatible.  It's FORWARDS 
> compatible yes, but not backwards.
> One case I know of is that certain String methods in JDK6 went from 
> taking (String s) as an arg, to taking (CharSequence c) as arguments, 
> if compiled against JDK6 -even if targetting 1.5 bytecode- the 
> compiled method signature looks for CharSequence, which when run on 
> JDK5 fails with method-not-found and blows up.
> There -are- legitimate cases for compiling with JDK5/JDK6 as your 
> boot-class-path - for this - the toolchains plugin is your answer.
> Mark
> Baptiste MATHUS wrote:
>> +1  on the question, do you really need to build for both versions? 
>> As JDK
>> is backward compatible, you could for example build only with1.5.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Ron Wheeler
Artifact Software Inc
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

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