Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: domain of kumpera@gmail.com designates
 64.233.170.192 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=bOoLW3b1o8tJ0VDj28+BdgGe+IOnAsOYtaPrRjXyfsbbzY/Q9mAgPrUTdPoKPLXS6tEzZUgJya4T8fyv6Y8OEplkpNsPOW+q7nwECsIc8V9xXSnXeeiPkNHptA5wOz8iuCNLj4yDRg80bRsiE5qArXnGVPrX5BBV7qGm9c1vMcI=
Message-ID: <8cca42d8050528174125633a4@mail.gmail.com>
Date: Sat, 28 May 2005 21:41:40 -0300
From: Rodrigo Kumpera <kumpera@gmail.com>
Reply-To: Rodrigo Kumpera <kumpera@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [arch] VM/Classlibrary interface
In-Reply-To: <4298FE1F.8070506@kaffe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <60510FC8-4503-4149-A7EA-9CEBA018D0FA@apache.org>
	 <42978057.7080403@Jarnbjo.de>
	 <8cca42d805052713343efbce33@mail.gmail.com>
	 <A0E89CF1-F01C-4D84-BAF5-A45D86C8AE6A@apache.org>
	 <8cca42d805052716408c3592f@mail.gmail.com>
	 <42984C95.1060301@kaffe.org>
	 <8cca42d8050528103758498db7@mail.gmail.com>
	 <4298FE1F.8070506@kaffe.org>

On 5/28/05, Dalibor Topic <robilad@kaffe.org> wrote:
> Rodrigo Kumpera wrote:
>=20
> >>b) an accidental mistake, then you fix the small bug in your code, feel
> >>better about the quality of your code, and move on.
> >
> >
> >
> > I agree with you about the first one, but the second is where the fine =
line
> > between pragmatic and retoric solutions line. It's easy to say 'just fi=
x it
> > then', but I hope that Harmony gets more users that a few hackers.
>=20
> I hope so, too. ;)
>=20
> Seriously, though, no VM can automatically fix bugs in other people's
> code. It would be unreasonable to expect that a VM could be able to
> figure out which specific unspecified behaviour from which particular
> release of which particular platform to emulate in order to fullfil the
> expectations of the buggy code. No VM can read the mind of the developer
> of the buggy code, and figure out whether going outside the scope of the
> specifications was a deliberate choice or a mistake. On the other hand,
> the developer of the broken code probably knows what he wanted to
> achieve and can act accordingly.
>=20
> There is nothing rhetoric about that: bad code breaks sooner or later.
> Then it needs to be fixed.
>=20
> Of course, one could throw one's arms up in the air, and shed tears
> about the cruelness of a world where bad code can exist. But just fixing
> the bad code seems to do work at least equally well in practice. ;)
>=20
> > My point is, testing against just the TCK is just not enouth. Testing
> > against real applications is where the real value of Harmony can be
> > asserted. Most free JVMs already do that and nobody seens to be complai=
ning.
>=20
> Nobody is complaining because developers simply fix their bugs and move
> on, be they bugs in Kaffe, GNU Classpath, or some application that
> doesn't run on them due to some mistake a developer made.
>=20
> If you don't think the TCK is good enough for compatiblity, then I am
> sure that the respective JSRs would welcome your contributions to
> improve what your believe to be a problem.
>=20
> cheers,
> dalibor topic


There is a long track of incompatibilities between JVMs and most of
then are subtle, poor specified behavior. A good example is
java.util.ConcurrentModificationException, this exception is thrown in
a best-effort way by the Collection classes. This means that JVMs will
throw this exception as they see fit. I've seen software that did not
depent on this behavior fail because of such problems.

Other good example is the bugtracker for Sun's JVM, there are many
bugs that differ from specified behavior and there might be software
out there that depends on these bugs but never quite realized that.

Broken software is a reality and sometimes the cause is the blur line
between the spec and the RI. You can even find some public methods
somewhere on AWT that takes sun.* classes.