Francis, unfortunately what you are mentioning as backward
compatibility breaking are NOT valid arguements. You are talking about
some different JVM problems (and that is not SUN - and you were
refering to it), and than different path and classpath possible
problems. Those are not official SUN distributions and their philosphy
may be different from the creators one.

Just to clarify: Sun has kept the backward compatibility and has done
this with major versions too. There may be a single exception: Java
1.1 -> Java 1.2, but even about this I cannot say it for sure, because
I don't remember having API problems or thing like things (but my
memory can be bad after all this time).

best regards,

./alex
--
.w( the_mindstorm )p.

PS: I am not associated in any ways with SUN Co. I just like that the
readers are correctly informed.

On 9/17/06, Francis Cianfrocca <garbagecat10 / gmail.com> wrote:
> On 9/17/06, Alexandru Popescu <the.mindstorm.mailinglist / gmail.com> wrote:
> > Can you please point me to real examples? Java is one of the few
> > languages I know that has guaranteed backward compatibility. So, I
> > would really like to hear real examples, otherwise this sounds like
> > missinforming. And please do not mix backward compatibility with bugs.
> >
>
> 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?
>
> 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.
>
> 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.)
>
> 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.
>
>