@Supported design issues

[Phil Race]

That isn't at all what @deprecated means.

"Encouraged for new development" doesn't mean everything else is 
@deprecated.
These are all part of the Java SE platform spec, and are documented as such
and are fully supported .. a focus on compatibility is very important to 
a lot
of our customers, even if that's not you.

-phil.

On 3/17/13 12:10 PM, Daniel Latrémolière wrote:
>
>> 1. I suspect that the percentage of deprecated APIs is less than 0.1 
>> % ..
>>     So removing 1 ouf every 1,000 methods is not exactly going to make
>>    a huge difference here.
>>
>> 2. Some methods were deprecated at a time when the policy was to
>>     encourage people to use "newer" API, even though there wasn't
>>     anything very wrong. with the old one.
>>     For example Component.show()/hide() were deprecated
>>     in favour of Component.setVisible(boolean) although as far as I know
>>     there's absolutely no problem with the former.
>>     So such a policy would not be something you could apply 
>> automatically
>>     you'd need to go examine each case to understand it.
> Yes or no for 0,1%, depending if you include some big parts like AWT, 
> Swing, CORBA which are obsolete for many developers, because they are 
> not considered up-to-date for their domains (UI, RPC) and their 
> development is stopped. In this case, deprecated or obsolete API are 
> concerning important domains, like:
>
>   * UI (AWT -> Swing -> JavaFX),
>   * date management (Date -> Calendar -> JSR 310)
>   * RPC (RMI, CORBA, WebServices, REST like JAX-RS: not all are used
>     even if winner depends of project).
>   * LDAP dedicated API are provided by vendors like Apache Directory,
>     OpenDJ for replacing JNDI (not evolving since Java 1.4 and seen
>     not sufficiently specialized).
>   * Logging API is split between java.util.logging, Log4J, SLF4J
>     (depending of project).
>
> Other domains has evolved (like IO, NIO, NIO2) but contains some 
> complex differences: e.g. Path vs. File. Considering File as 
> deprecated in Java7 is frequent even if it is not official: 
> http://stackoverflow.com/questions/6903335/java-7-path-vs-file
>
> Another related problem for a developer is that many parts of API show 
> their age given others enhancements: e.g. Math/StrictMath classes were 
> introduced before Integer/Long/Float/Double classes but would probably 
> not have existed if order was inverse (static methods are notoriously 
> difficult to find, because we don't know by default the class 
> containing them).
>
> Globally, an API designed before Java 1.5 has usually be updated for 
> generics but not for enumerations and only partially for annotations. 
> Now, seeing an int for describing an enumeration in an API became 
> surprising (like Modifier in reflection). Marker interfaces (like 
> java.io.Serializable, java.util.RandomAccess) have same problem 
> against annotations. The reason is simply that Java 1.5 is old: it has 
> 8.5 years. API designed before have accumulated a technical debt and 
> are not seen up-to-date.
>
> I think, I have covered big parts of Java API, concerning all 
> developers, with various names (deprecated, obsolete, technical debt) 
> for only one problem: feeling of an old API and need of cleaning it.
>
> NB: With static methods in interface, you will probably have the same 
> problem in some years:
>
> 1) First round: add factories methods in interface.
> Developer speaking: When I want an instance of an interface it is 
> always difficult to search a subclass and only after that call its 
> constructor. I want to go to the expected interface and call a static 
> factory for all my frequent usecases, then: please add some static 
> methods like followings in List class (and all other interfaces with 
> implementations provided by default):
> public static <E> List<E> newRandomAccessList() {
>    return new ArrayList<E>();
> }
> public static <E> List<E> newLinearAccessList() {
>    return new LinkedList<E>();
> }
>
> 2) Second round (some years after): remove them from public API.
> Developer speaking: I do not need to see AbstractList, ArrayList and 
> LinkedList because I don't call them directly, at least in 99% of my 
> usecases. This is a List-related implementation detail only useful 
> when I want to create my own custom List for a highly specific and 
> performance-sensitive usecase. Remove these classes from public API 
> and put them in another library not seen by me by default, excepted if 
> I really search it.
> In Javadoc, I only see the signature of method, and not the code of 
> method (implementation detail), then I don't want to see these classes 
> only implementing interfaces (implementation detail): the factory 
> method in interface is sufficient with one paragraph in the Javadoc 
> giving tradeoffs of each implementation provided by default.
>
>> 3. Removing methods *from the doc* and *from the runtime* each
>>     have their consequences, from the doc would discourage new uses
>>     but make it harder to understand old code. I think a long ago 
>> ill-fated JSR
>>     for javadoc improvements pondered hiding deprecated methods if
>>     you didn't want to see them. Remiving from the runtime would
>>     break apps, and in some cases people don't have the option to change
>>     and fix.
> Currently, profiles are clearly reducing some API complexity for 
> developer.
> NB: JavaFX doclet seems to remove methods with prefix impl_ from Javadoc.
>
> I think it seems sad, that one of the biggest differences between Java 
> and shorter language like JavaScript is static typing: it give an 
> excellent accuracy when used for automatic refactoring in Java. Given 
> static typing, IDE have added many automatic refactoring and some 
> mechanisms for helping updating code (e.g. generics), JSR 308 has also 
> some inference tools.
>
> But bytecode refactoring (AOT in build process or JIT in ClassLoader) 
> was mostly used for supporting new Java code with old JVM 
> (Retroweaver, Retrotranslator) and not the inverse: supporting old 
> Java bytecode on new JVM. I thought it was possibly used for executing 
> JavaME program on JavaSE JVM but I am not sure.
>
> <utopia>
> I hope of a future where Java easier refactoring (given static typing) 
> would help evolving Java faster by breaking direct compatibility while 
> keeping sufficiently real compatibility (old programs are only 
> slightly slower in compatibility ClassLoader). With easier evolution, 
> Java API can be better organized and developer become happy.
> </utopia>
>
> NB: I never used "Java platform" because I think Java is slowly 
> evolving, for developers, to become more a library for their 
> application, than a platform containing application. Having an 
> integrated JVM in each application is a big change in compatibility 
> requirements, because developer has control on compatibility and it 
> will possibly relax some constraints.
> 1) JavaEE applications are evolving to include server and not inverse: 
> http://www.adam-bien.com/roller/abien/entry/why_not_one_application_per
> 2) JavaSE applications are evolving to include JVM and not to run on a 
> JVM provided by OS: mobile OS prohibiting shared libraries and 
> security problems of OS-global JVM define the rules: 
> http://fxexperience.com/2012/06/application-deployment-with-javafx/
>