CODEWITHSUNDEEP
javabackwards-compatibility
Ben Xu
Ben Xu

Reputation: 1309

what is the general java API compatibility rule

in detail: if we use public API for example, write java program for example , in JDK 1.4, if should run correctly in all version above it. in all update version in 1.4, in 1.5, 1.6 and 1.7?

Also , what is the combability rule between different updater versions , for example 1.6.22 and 1.6.23 what can not be changed, what can be changed? of course, public API definition can not be changed, how about others? javadoc? internal API definition, implementation?

It will be great if someone can point a concrete official document on this topic. thanks,

there is one example in java document bug, that they intended not to change between updater version. see https://bugs.java.com/bugdatabase/view_bug?bug_id=6475885

this should be one of its big picture, but we better to have a complete description on this.

need to know the complete story so that we feel safe to upgrade to bigger version.

Upvotes: 7

Views: 556

Answers (5)

linuxbuild
linuxbuild

Reputation: 16133

if we use public API for example, write java program for example , in JDK 1.4, if should run correctly in all version above it. in all update version in 1.4, in 1.5, 1.6 and 1.7?

Upvotes: 0

Stephen C
Stephen C

Reputation: 718826

The general rule is that any code that is written and compiled against the APIs of Java X should run on Java Y where Y >= X.

There are occasional exceptions to this; e.g. where the application's behaviour depends on some undocumented behaviour (typically a bug) in Java X that was corrected in a later version.

AFAIK, there is no single document that lists these incompatibilities. The release notes for all of the Java major releases include a list of changes that could result in breakage of older code.

Having said that, the prudent approach is make sure that you thoroughly test / retest your software when you upgrade to a more recent Java release. And if your software is shipped to customers / clients, let them know if / when it is safe for them to upgrade, and (if necessary) provide them with fixes for any problems that your testing has uncovered.

need to know the complete story so that we feel safe to upgrade to bigger version.

Feeling safe is beside the point. Thoroughly test your application on the later version. That is the only practical solution. And that would be the case even if each and every incompatibility was exhaustively documented.

Think about it. How can you know for sure that your application won't somehow be affected by change XYZ? Or that some 3rd-party library that you use won't be affected? Answer: you can't.

No manner of complaining here that you think that Oracle should handle this issue differently is going to make any difference. Not that I think that they could handle this better without changing their business model. How much would you be prepared to pay for a Java platform that guaranteed there were no version compatibility issues?

Upvotes: 7

irreputable
irreputable

Reputation: 45443

I don't think JDK ever changes an API that breaks backward comparability (except unintentionally).

They introduced @deprecated tag in the very beginning, probably thinking that they may need to do some API cleanup in future. But that never happens. No @deprecated API has ever been removed, or behavior changed.

Upvotes: 1

Tony Kennah
Tony Kennah

Reputation: 316

Almost anything can be changed between versions there are no set rules for such things. Use the release notes to publish changes or review them between versions such as:

http://www.oracle.com/technetwork/java/javase/jdk7-relnotes-418459.html

Usually only bug fixes are the cause of minor versions (like you detail 1.6.22 - 1.6.23), or simple enhancements which are only ever good things. When the major version numbers change then you can expect more major changes but you still "hope" for reverse compatibility.

Upvotes: 1

Andrew White
Andrew White

Reputation: 53496

This is not a full answer but I will add that will-it-run and will-it-compile are two different things. Keywords introduced in 1.5 will prevent some 1.4 code from compiling but the byte code will run just fine.

Upvotes: 2

Related Questions