non hélas, et c'est plutot facile de savoir pourquoi (une simple requete dans un moteur de recherche Internet)
Envoyé par darklinux
Compatibility Guide for JDK 8 https://www.oracle.com/technetwork/j...e-2156366.html et plus précisément https://www.oracle.com/technetwork/j...6.html#A999387
Incompatibilities between Java SE 8 and Java SE 7
Java SE 8 is strongly compatible with previous versions of the Java platform. Almost all existing programs should run on Java SE 8 without modification. However, there are some minor potential incompatibilities in the JRE and JDK that involve rare circumstances and "corner cases" that are documented here for completeness.
This section describes Java SE 8 incompatibilities in the Java Language, the JVM, or the Java SE API.
Note that some APIs have been deprecated in this release and some features have been removed entirely. While these are incompatibilities, they have been called out in separate lists. For more information, see Deprecated APIs and Features Removed from JDK 8.
A Maintenance Release of Java SE 8 was performed in March 2015. Incompatibilities arising out of this release are marked accordingly.
How and When To Deprecate APIs https://docs.oracle.com/javase/7/doc...precation.html
What "Deprecated" Means
You may have heard the term, "self-deprecating humor," or humor that minimizes the speaker's importance. A deprecated class or method is like that. It is no longer important. It is so unimportant, in fact, that you should no longer use it, since it has been superseded and may cease to exist in the future.
Java provides a way to express deprecation because, as a class evolves, its API (application programming interface) inevitably changes: methods are renamed for consistency, new and better methods are added, and fields change. But such changes introduce a problem. You need to keep the old API around until developers make the transition to the new one, but you don't want them to continue programming to the old API.
The ability to deprecate a class, method, or member field solves the problem. Java supports two mechanisms for deprecation: and an annotation, (supported starting with J2SE 5.0) and a Javadoc tag (supported since 1.1). Existing calls to the old API continue to work, but the annotation causes the compiler to issue a warning when it finds references to deprecated program elements. The Javadoc tag and associated comments warn users against using the deprecated item and tell them what to use instead.
When to Deprecate
When you design an API, carefully consider whether it supersedes an old API. If it does, and you wish to encourage developers (users of the API) to migrate to the new API, then deprecate the old API. Valid reasons to deprecate an API include:
- It is insecure, buggy, or highly inefficient
- It is going away in a future release
- It encourages bad coding practices
Deprecation is a reasonable choice in all these cases because it preserves "backward compatibility" while encouraging developers to change to the new API. Also, the deprecation comments help developers decide when to move to the new API, and so should briefly mention the technical reasons for deprecation.
It is not necessary to deprecate individual member fields (properties) of a deprecated class, unless of course you want to explain a specific point about a property.
il n'y a pas que Java et ses API qui sont concernés par les fonctionnalités dépréciées et autres discontinuités des langages