harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Wielaard <m...@klomp.org>
Subject Re: Implementation comparisons
Date Sat, 05 Nov 2005 10:25:24 GMT
Hi George,

On Thu, 2005-11-03 at 15:41 -0600, Archie Cobbs wrote:
> George Harley1 wrote:
> > I would like to ask for some opinions on measuring how "correct" a new 
> > implementation of a J2SE class is. Consider if someone develops a clean 
> Very good question and one that is asked (and sometimes answered)
> in various forms all the time on the Classpath mailing list. The
> approach there has been pragmatic.. basically the comparision is
> of course always versus what the JDK does. If the spec says nothing
> but JDK behaves like X, then Classpath typically behaves like X, etc.
> If the spec says X and the JDK does Y, then Classpath usually does X.
> The harder cases are when the JDK behavior and spec disagree, or the
> JDK has a bug but applications rely on that buggy behavior, etc.
> These are taken case by case.

Yes, and you should always work from real books and not just the javadoc
that IBM and Sun publish publicly describing the core library.
Unfortunately those descriptions are not really concise and clear enough
to be used as spec. Luckily there are several in depth books about
various parts of the core library. O'Reilly and Addison Wesley publish
some very good titles. Since real programmers use these books and the
examples they give they are often a more solid base to work from.

And it involves Testing, Testing and Testing!
In the end it matters what real world applications do and need. So
before all you should test against applications (preferably Free
Software applications that you can study the source code of). Then
whenever you find the documentation unclear or when writing new code you
should write a Mauve unit test to make sure any corner cases are handled
correctly and no regressions in behavior are introduced in the future.
And of course whenever you find a real application that depends on a
particular way the core library works and you decide to change the
behavior of the library you have to clearly document that and again
write a Mauve unittest.



Escape the Java Trap with GNU Classpath!

Join the community at http://planet.classpath.org/

View raw message