GregorianCalendar fixes

Mark Wielaard
Fri Nov 28 12:38:00 GMT 2003


On Fri, 2003-11-28 at 04:39, Stephen Crawley wrote:
> Mark Wielaard <> wrote:
> > On Fri, 2003-11-28 at 02:03, Stephen Crawley wrote:
> > > The over-arching principle for Mauve testcases is that the behavior of
> > > Sun's Java implementations is the "gold standard" for conformance
> > > testing.
> > 
> > I don't agree. We should not create Mauve tests to validate some
> > proprietary library implementation.
> I don't understand what you are saying here.

Sorry, was way past my bedtime. Maybe I should have taken more time
explain. I was mainly disturbed by the suggestion that some proprietary
implementation should be pointed out as the "gold standard" and that if
that same implementation decides not to fix bugs then it isn't a bug.

There are lots of examples of bugs in some widely used implementations.
Mauve points those out. For example floating point string
representation, or solving the solutions for some quadratic equation and
very possible representations of date and time. I haven't checked Ito
his test yet, but I hope you agree that even though some implementation
might claim say that a certain month has 35 days then it is obviously a
bug and not according to spec. What you seem to want is a list of bugs
in certain implementations according to Mauve and an explanation why
that bug is or isn't solved in that implementation. We don't provide
that. Even though it might be useful for some of our users.

>   We are not building Mauve
> tests in order to validate Sun's implementation.  Rather, we are
> building it to check that other implementations (including Classpath)
> conform to the accepted specification for Java.  The ultimate
> specification for Java is (according to Sun) the behaviour of Sun's
> reference implementations.
> Are you suggesting that there is a more appropriate or more definitive
> specification of Java?  If so, what is it, and why is it more
> appropriate or definitive?  

No. Since Sun says what Java is and claims trademark on products which
carry that name. It is their definitive specification: "The thing that
according to Sun is Java". So by definition Mauve isn't The Java

But there are publicly published documents and books about the libraries
and what Mauve can claim is that it is a testsuite that follows these
publicly published specification as closely as possible without favoring
any actual implementation.

Mauve is a reference test suite that everybody can use and study and
might even adapt (to better reflect their understanding of the spec) and
publish its own version, which validates differences between core
library implementations. In that sense Mauve is its own specification.

And for our users it is certainly very useful to use Mauve to compare
implementations against the currently dominant proprietary
implementation to see if another implementation can be used to easily
migrate away from the that implementation.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the Java-patches mailing list