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
