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 ASL. > 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. Regards, Tim > Cheers, > > Mark > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
