harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Implementation comparisons
Date Sat, 05 Nov 2005 17:58:20 GMT
Mark Wielaard wrote:
> 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. 

I agree with the observation, and yet they are 'the 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.

At the risk of sounding boring, it is worth noting that the books'
material is usually copyrighted and licensed too -- so we have to be
careful not to copy examples from any reference material into Harmony's
implementation or test suites where the license is incompatible with the

> 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.

Fully agree, of course to be called 'java' we have to pass the JCK too.
 There is no substitute for running key applications though.


> Cheers,
> Mark 


Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

View raw message