Deprecation schedule

[Bruno Medeiros]

On 27/11/2010 17:04, Stewart Gordon wrote:
> On 26/11/2010 23:44, Jonathan M Davis wrote:
>> On Friday 26 November 2010 15:19:37 Jason House wrote:
>>> T2 - This should be quite long. There's no
>>> reason to leave active projects with a non-compiling code base just
>>> because an API in a low priority area has changed. I would say something
>>> like 6-12 months. What do other languages do?
>>
>> Java marks stuff as deprecated and then _never_ removes it.
> <snip>
>
> Thinking about it now, I can see why. Java .class files don't contain
> implementations of the Java APIs - they pull them up from the JRE on
> demand. So if stuff were removed, old programs would stop working, not
> just stop compiling.
>

Yup, there are no equivalent of "executables" in Java compilation 
artifacts, only the .class files which are the equivalent of "shared 
libraries". Thus binary compatibility is a constant issue.

> Though I suppose they could do something like declare Java 1 obsolete,
> and then another few years down the line start to remove stuff.
> Maybe
> with a warning for anyone who tries to use a Java 1 app that it may not
> function correctly.(Do .class files store such version info?)
>

.class files do have version info, but that relates to bytecode 
compatibility only, it specifies to the minimum *VM* interpreter 
required (1.4, 1.5, 1.6, etc.). But it says nothing about the minimum 
JRE (standard library) required, which can be higher (but not lower).



The problem with removing stuff in the JRE in a breaking manner, is that 
in enterprise software you often have a system with *lots* of 
middleware, libraries, other third-party software, etc., in the same 
Java program. If just one of them requires that deprecated API, removing 
that API could make the whole system not run, in newer VM's at least. 
And often such software is closed-source, so you can't just modify it to 
run on newer JREs. So they have to be very mindful of that.

The other thing (especially with APIs) is that sometimes there is no 
significant advantage in actually removing deprecated stuff: just having 
the people switch to an alternate component/library is good enough (like 
the Calendar example). Removing is only more significant when the two 
APIs (newer and older) cannot coexist at the same time (or cannot do so 
easily).


-- 
Bruno Medeiros - Software Engineer