https://en.wikipedia.org/wiki/Backward_compatibility
In telecommunications <https://en.wikipedia.org/wiki/Telecommunications>
and computing <https://en.wikipedia.org/wiki/Computing>, a product or
technology is *backward* or *downward compatible* if it can work with
input <https://en.wikipedia.org/wiki/Input/output> generated by an
/older/ product or technology.^[1]
<https://en.wikipedia.org/wiki/Backward_compatibility#cite_note-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
<https://en.wikipedia.org/wiki/Communications_protocol>. Modifications
to a system that do not allow backward compatibility are sometimes
called "breaking changes <https://en.wiktionary.org/wiki/breaking_change>."
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.
Ron
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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
