public inbox for mauve-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Jeroen Frijters" <jeroen@sumatra.nl>
To: "David Gilbert" <david.gilbert@object-refinery.com>,
		"Roman Kennke" <roman@kennke.org>
Cc: <classpath@gnu.org>, 	<mauve-discuss@sourceware.org>
Subject: RE: Testing JDK bugs?
Date: Thu, 27 Jul 2006 14:56:00 -0000	[thread overview]
Message-ID: <D92197D0A6547B44A1567814F851FA6827A538@LEMBU.sumatrasoftware.com> (raw)
In-Reply-To: <44C8BAFF.6080001@object-refinery.com>

David Gilbert wrote:
> The theory is easy:  Mauve should test AN implementation against THE 
> spec.

Pardon me for beating my favorite horse again, but this assumes that the
spec is somehow more valuable than code and/or that the spec doesn't
contain bugs. In the real world both are buggy and users rarely care
about the spec, especially when their app works on the RI, but not on
our implementation.

Allow me to rebut another issue that often comes up: "We'll make it spec
compliant and when someone finds an application that depends on the RI
behavior then we'll copy that behavior."

IMNSHO, this is actually a very dumb approach. It makes our
implementation worse than the RI in two ways:

1) Apps coded against the RI (possibly) don't work out of the box.
2) Apps coded against our implementation (and spec) run the risk of
breaking in the future when we randomly decide to start emulating the RI
instead of the spec.

Of course, things aren't black and white and issues should be decided on
a case by case basis, but considering the spec holy is not doing anybody
any service.

Regards,
Jeroen

  reply	other threads:[~2006-07-27 14:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-27  9:49 Roman Kennke
2006-07-27 13:08 ` David Gilbert
2006-07-27 14:56   ` Jeroen Frijters [this message]
2006-07-27 16:32     ` David Gilbert
2006-07-27 17:01     ` Andrew Haley
2006-07-28  7:56       ` Jeroen Frijters
2006-07-28 12:33         ` Sven de Marothy
2006-07-28 14:51         ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D92197D0A6547B44A1567814F851FA6827A538@LEMBU.sumatrasoftware.com \
    --to=jeroen@sumatra.nl \
    --cc=classpath@gnu.org \
    --cc=david.gilbert@object-refinery.com \
    --cc=mauve-discuss@sourceware.org \
    --cc=roman@kennke.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).