You don't need examples from me. Just look to your own experience.
Have you ever tried running Oracle and a version of Tomcat that
requires a different JVM, on the same machine? (Yes, I know it's a bad
idea to run *anything* on the same machine with an Oracle instance,
but that's not my point.) Remember porting your AWT applications from
JDK 1.1 to 1.2?
1.1 to 1.2 was a sea change in the Java world, so much so that 1.2 was
when the name "Java 2" came above. However from 1.2 through 1.6 (or 6,
as I guess it's supposed to be called) things have stayed very
consistent. Backward compatibility depends also on the complexity of
applications...Sun, like any software developer, has chosen to fix
problems from release to release. More complicated applications are
more likely to be burned by those fixes...but it doesn't necessarily
mean backward-compatibility was broken. It just means that older code
depended on flaws that were later fixed. I don't think you could
reasonably argue that things shouldn't be fixed, though I agree the
definition of a "flaw" is rather subjective.
It's true that Sun represents that they and their licensees will not
break older code so long as you stick to the "core" (java.*) packages.
(Their disclaimer is "unless they fix a serious bug.") In practice,
the experience has been painful. The OP said that he fears Ruby will
suffer back-compatibility problems in part because there is no large
company to provide the guarantee. My point was that the guarantee of a
large company may provide nothing but cold comfort as you modify your
code to deal with their "bug fixes,"
or worse, ship and maintain multiple versions of your code.
That has not been my experience. Very large applications often have
trouble upgrading, usually because they depended on or were written
around bugs in the original version. Smaller apps almost always just
work.
In my experience with Ruby, there haven't been all that many cases
where an emergency patch had to be made in order to fix a security
hole or other such urgent problem. I don't have any reason to suppose
that Matz, his team, or the community would make it difficult to patch
back versions of Ruby or its libraries in these cases. (The recent
security-emergency with Rails was very different, and quite badly
handled, but the Rails team is not the same as the Ruby team.)
Java is a signficantly more complicated beast than Ruby, but Sun does
try to make a best effort to backport significant changes. However
many shops refuse to upgrade at all. Ruby also has had a far slower
release cycle, meaning that backporting fixes generally only required
making changes to minor revisions. Have any fixes in 1.8 been
backported to 1.6 recently? I don't think so. However I know many
shops that are still on Java 1.4 (and some on Java 1.3) that can't
reasonably expect to get fixes applied to Java 5 or 6 (1.5/1.6) since
1.4 is now almost five years old.
Having said all this, I would stress that strict back-compatibility,
even with bugs, is generally the way to go (except for bugs that open
security holes), and I would prefer more back-compatibility than Ruby
has generally provided in the past. On the other hand, Ruby (like
Java) now produces major revs so infrequently that it's not a terribly
large problem. For all ends and intents, I consider Ruby to be a
stable language.
Stable or slow to evolve? I agree with stable, actually, and most of
the stuff planned for 2.0 I don't even think is all that necessary.
Ruby has never really felt to me like it's missing much, but I may
just be easy to please.
Java has often felt like it's missing things, but when I pair it with
a dynlang like Ruby suddenly it does what it does best very well. Just
like many folks in the Ruby world pair Ruby and C to get the best of
all worlds, I pair Ruby and Java. I think language evolution is highly
overrated in general when there are plenty of languages out there to
fit every task.
