Java compatibility? (was Re: Not a bash, just the facts)

[Dalibor Topic]

Alan McKinnon <alan <at> linuxholdings.co.za> writes:

> 
> On Sunday 26 March 2006 04:44, Michael R. Head wrote:
> > On Sun, 2006-03-26 at 09:29 +0800, Michael T. Richter wrote:
> > > On Sun, 2006-26-03 at 02:59 +0200, Alan McKinnon wrote:
> > > > Java is backwards-compatible.
> > > >
> > > > One exception: deprecated features.
> > >
> > > This translates to "Java is backwards-compatible, except where it
> > > isn't", Alan.  That's not resoundingly persuasive.  ;)
> >
> > Has any deprecated feature ever actually been removed?
> 
> I was wondering that myself three posts back. Some reading meanwhile 
> indicates:
> 
> No.
> 

Sort of.

There have been changes that break binary compatibility between different J2SE
releases. For example, when wheeled mice became popular enough to have to be
supported somehow in AWT, the constant denoting the number of possible AWT mouse
events had to be incremented. Changing the value of a constant is a binary
compatibility breaking change, of course, see the Java Language Specification
for details. It's a pretty bad API design, anyway, but we're stuck with it.

There have been quite a few annoying cases where the spec and/or behaviour of
methods has changed radically between releases. System.getenv() went from sort
of working, to always throwing a runtime exception and back to hopefully working
between three different J2SE releases.

Fortunately, the (comparatively few) really messy bits and pieces at the
specification level are something the average Java developer does not have to
care about, since he's not writing a free software implementation of it. :)

cheers,
dalibor topic