Re: [Japi] stacktraces running japitools on harmony
On 11/15/06, Stefano Mazzocchi [EMAIL PROTECTED] wrote: What compiler is producing the jar that you're running this against? Eclipse ECJ 3.2 /me wonders if later versions have fixed this problem Also, is BasicSwingTestCase public in the first place? checking... yeah it's a 'public abstract' class. ... Anyway, cool to see it's not a JAPI bug. It still could be: perhaps I misunderstood the spec or there's an exemption for abstract that I missed. Or the code that's trying to detect this case is broken. I haven't investigated in detail, I don't want to say that it's definitely ecj's bug. Just that that's the area in which we should be investigating to find out where the problem really does lie. Stuart. -- http://sab39.netreach.com/
Japitools 0.9.7 released
I'm thrilled to be able to announce four things: 1) After far too long a wait, Japitools 0.9.7 Life, liberty[1] and the pursuit of Japiness has been released. This release includes the following improvements over 0.9.5: - Almost complete 1.5 language support, including generics, enums and varargs methods. The only missing feature for full language support (and the only blocker for a 1.0 release) is annotations. Big thanks to Jeroen Frijters for doing the heavy lifting of teaching Japitools to parse these features in .class files. - The ability to mark methods as not implemented by adding NotImplementedException to the throws clause. This allows Japitools to give results that more accurately match reality when parts of an API are known to have been stubbed out rather than actually being implemented. - The ability to traverse packages non-recursively (thanks to a contribution from Jaroslav Tuloch), making it easier to correctly specify the packages that are part of a public API, especially when that API is large. The new japiextractpkgs tool allows the list of packages to be extracted from Javadoc documentation. - An Ant task for running Japitools, thanks again to Jaroslav. - Too many bug fixes and minor enhancements to name, including a lot of changes that eliminate false positives and false negatives from the results. Thanks to many people for bug reports, feature suggestions and help in testing. 2) That there is now a Japitools mailing list, [EMAIL PROTECTED] See the mailing lists page (http://sab39.netreach.com/Software/Japitools/Mailing_Lists/52/) for more information. 3) That Japitools has a new homepage, http://sab39.netreach.com/japi/. It's ugly, and it's still a work in progress - some sections are still missing content, and others still have content that hasn't entirely been updated to match the current state of reality. I didn't want to delay any further getting the new release into people's hands. I'll continue working on filling out the content. 4) That Sun are AWESOME today! Stuart. [1] https://openjdk.dev.java.net/ -- http://sab39.netreach.com/
Re: Japi diffs for harmony
Nathan Beyer wrote: No problem on the name change, but doesn't what Stuart is talking about require that methods add this exception to the signature to actually show up in the reports? That's correct. If it's a subclass of RuntimeException (which it ought to be, otherwise it'd have to be in throws clauses anyway and that'd show up as errors already) it makes no practical difference to have it in the throws clause, but it provides a useful way to flag stub methods in such a way that Japitools can detect them. But yes, you have to do the work by hand to actually mark the stubs by setting the throws clause accordingly. Stuart. -- http://sab39.dev.netreach.com/
Re: [Fwd: Re: Interesting discoveries playing around with japitools]
Geir Magnusson Jr. wrote: David Gilbert wrote: A boon? Not at all, Classpath will be (mostly) redundant and will fade away, replaced by Sun's runtime. I'm not so convinced of that. GNU Classpath is under GPL + Exception, so arguably it's not viral to things that link with it. I think it's highly unlikely Sun will release their VM without terms that enable proprietary code to be built on top of it. That'd be particularly counterproductive of them. My speculation would be that they'll release it under two licenses, one similar to the terms they have now, and the GPL as the other. Code released under those terms is clearly not viral. Also, I think the copyright assignment requirement will be a big deal. If OpenOffice is anything to go by, Sun will require a copyright assignment to them; Classpath requires a copyright assignment to the FSF. Yes, that's a little bit different because a lot of developers will trust the FSF a lot more than they do Sun... I actually think it'd be really smart of Sun to not require a copyright assignment at all, but rather require contributing developers to license their code under *both* sets of terms just as Sun itself does. That would allow Sun to continue to use the dual licensing scheme without the stigma of the copyright assignment requirement. And it's very similar (in spirit, if not in details) to the model that Mozilla has used for years - originally to allow Netscape to make proprietary releases based on the contributed code. As far as the suggestion elsewhere in the thread (that I lost, digest mode subscription is painful ;) ) that the GNU people would feel it necessary to fork Sun's Java entirely to maintain their sense of freedom, I don't think this is so. The FSF have fairly strong philosophical disagreements with Linus but have never forked the kernel. They have philosophical disagreements with the ASF sometimes but there isn't a GNU fork of the Apache webserver. I think a GPL'd Java would be considered acceptable - because the license allows the *option* of a fork if Sun proves to be a sufficiently poor steward. But I've never heard of a project being preemptively forked on the offchance the maintainer will make unacceptable decisions in the future. At least I've never heard of such a fork having even the slightest success. A lot depends, of course, on how Sun actually engages the community - I'd say that's even more important than the license, as long as the license isn't *completely* un-work-withable. Understood. For me, an additional requirement is an open and level community, where all participants are working together under exactly the same terms. (Which is where GNU Classpath will be different than what I understand the Sun model will be) I don't consider it a foregone conclusion either way as to whether Classpath will or won't continue with any enthusiasm if Sun's implementation is released under an acceptable license and with an acceptable process for getting contributions back in. There's a lot of momentum behind Classpath right now but it might be hard to justify all the effort to get from (essentially) complete 1.4 and parts of 1.5, to parity with Sun's 6. Either way we live in interesting times :) And either way Sun's release under *any* open source license is a very good thing. Stuart. -- http://sab39.dev.netreach.com/
Re: [Japi] Re: [Fwd: Re: Interesting discoveries playing around with japitools]
On 11/9/06, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Sometimes some climbers manage to get to the other side to find that some people are very welcoming and appreciative of cultural differences while others not so much. Ok, wow, this whole subthread is kind of what I meant by the politics being scary. I think we can all agree that among the Classpath devs and among the Harmony devs there's plenty of goodwill in theory but also a fair degree of disillusionment that the hoped-for level of cooperation wasn't able to materialize. But improving Japitools and having a better understanding of what it does and doesn't do is in the best interests of both projects - and other projects that might want to use it. Japitools isn't affiliated with Classpath btw, I had Classpath in mind when I originally developed it, yes, and it's GPL licensed because I have a mild preference for that license, but I don't feel strongly about it. One of the reasons I started a Japitools list in fact was to try to have some neutral ground for discussions to avoid any perception (or, even worse, reality) that Harmony had any kind of second class status. While I admit that coming from the Classpath side of the fence originally, I have mixed feelings about whether the licensing differences were actually worth starting a whole separate project for. But Harmony exists and I hope it succeeds, just as I hope Classpath succeeds. More interoperable implementations can't hurt. And the interoperable part is where Japitools comes in. So can we all play nice? ;) Stuart. -- http://sab39.netreach.com/
Re: [Fwd: Re: Interesting discoveries playing around with japitools]
On 11/7/06, Stefano Mazzocchi [EMAIL PROTECTED] wrote: btw, I signed up on the japi mail list, so I think we should take it from there. cc'ing both harmony-dev and japitools-list for now so that at least harmony folks are aware the discussion is moving. Feel free to just stick to japitools-list for followups. If you need some CSS/webdesign skills, I'll be happy to give a hand. Heh, yeah, I know it's ugly. I generally know enough CSS and HTML to achieve a particular desired result - it's knowing *what* desired result I want to achieve that's tricky. In theory I like the idea of a site that mimics the look of the results pages somewhat, since that's what most people know Japitools from. It'd be great if that could be achieved while still being attractive and usable though. I'd really love if some Harmony developers would join the japitools mailing list if you're interested in the Japi results and how to make best use of them. I plan to announce both the lists and the new website more prominently when I have a new release to announce as well, but seeing as there was active discussion going on right now, I didn't want to wait. oh, didn't even know one existed. It didn't. I created it about 2 days ago ;) (Yes, the japitools list is on an FSF server. I really really hope that this isn't going to be a political problem for you guys. I selected Savannah for hosting japitools before Harmony even existed, because it made most sense at the time when Classpath developers were the main users. Please don't let that hinder our ability to communicate on something that makes sense for all projects concerned) you kidding? of course I'll join. I'm never quite sure. Some of the politics between the Classpath and Harmony projects have been quite scary from my point of view. Stuart. -- http://sab39.dev.netreach.com/
Re: Japi diffs for harmony
Tim Ellison wrote: I'm no fan of stubs for just such reason. But for those dev's that are following along, there is an org.apache.harmony.luni.util.NotYetImplementedException that is defined for just such purposes. Would you consider renaming this to NotImplementedException since Japi recognizes that name in throws clauses and treats it specially? If you feel strongly about not changing the existing name, I can add NotYetImplementedException as an alternative hardcoded name in Japitools but that seems kinda redundant... What do you think? Stuart. -- http://sab39.dev.netreach.com/
Re: [Japi] [general] interesting discoveries with japitools - part 2
On 11/7/06, Stefano Mazzocchi [EMAIL PROTECTED] wrote: java.awt.peer: Missing method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in bea1.5 This one indicates that your set of packages is not correct: java.awt.peer is not a documented package. Unfortunately getting the right set of packages is hard on Windows - I just posted on japitools-list about improving that situation. If you do happen to be on a unix-like system this should work: japiextractpkgs docs/api/overview-frame.html jdk15.pkgs japize as jdk15 packages jre/lib/*.jar `cat jdk15.pkgs` where docs/api is a folder containing the JDK javadocs. The trouble is that the backquote quoting and the cat command aren't available on Windows and I'm not aware of an alternative. So the plan is to get Japize to accept @jdk15.pkgs as an alternative syntax. Any volunteers or anyone who knows where I could find code to do that, dealing with quoting and the like, under a GPL-compatible license, please speak up on japitools-list... java.util.concurrent: Abs.add method java.util.concurrent.Delayed.compareTo(java.lang.Object): new interface method in bea1.5 So, it appears that that Sun added a method that is not available in the javadocs (bad Sun, no donut for you!) and that BEA did not (correctly) implement. Also, BEA added the method compareTo to the java.util.concurrent.Delayed interface. This is not really a problem because Delayed extends Comparable, therefore all classes implementing Delayed will have to have the compareTo method anyway. Comparable is really fun in the presence of generics. Does Delayed implement Comparable or ComparableDelayed or Comparable? extends Delayed or what? If it implements ComparableDelayed then it *doesn't* technically have a compareTo(Object) method but a compareTo(Delayed) instead. If Sun added a compareTo(Object) method as well... well that'd have some rather weird effects. I'll need to take a while to get my head round that. Could you produce and send me Japi files of *just* the Delayed class in both implementations so I can look at the differences in detail? Stuart, do you think this is something that japitools should check? I would call this a false positive. I think it's an indicator of something, I'd say more investigation is needed before determining it's a Japitools bug. java.awt.peer: Missing method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in ibm1.5 Again peer should not be included. java.util.concurrent: Abs.add method java.util.concurrent.Delayed.compareTo(java.lang.Object): new interface method in ibm1.5 Same as above. javax.xml.datatype: Bad field javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS: constant [com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl] in sun1.5, but constant [org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl] in ibm1.5 This is an API bug on Sun's part; alternative implementers are screwed here either way. Constant fields are inlined so the value will be taken from the implementation the code was *compiled* against, not what it's running against. Japitools is correct to report this as an error, but the only *correct* fix is for Sun to un-constify that field. java.util.concurrent: Abs.add method java.util.concurrent.Delayed.compareTo(java.lang.Object): new interface method in sun1.5 Done. Hmmm, the compareTo is in both the direct and the reverse? smells like a japitool bug to me. Yes that is odd. Please do send me those two Japi files. java.lang: Missing method java.lang.StringBuilder.append(java.lang.StringBuilder): missing in sun1.5 Weird. 2) package org.w3c.dom.xpath: missing in sun1.5 This again is a not getting the right set of packages issue. Adding extra packages isn't illegal (at least not in Japitools's view of the world); the comparisons should be done based on which packages are *documented* as present. The results show clearly that japitools did indeed improve a lot over the last released version. Great :) NOTE: the results were taken with the following package passed to the japize tool: +java +javax +org -org.apache -org.ietf Yup, that's your trouble ;) Stuart. -- http://sab39.dev.netreach.com/
Re: Japi diffs for harmony
I tried sending this previously, but Stefano seems to have not received it (at least I got no response or followup) and (as I suspected) the list definitely didn't because I wasn't subscribed. I subscribed to the digest version now so that I'm not so excluded from japitools-related discussion on harmony-dev. My response to Stefano's questions is below. I've seen further discussion on japitools in the harmony-dev archives and I'll send separate mail addressing the japi-related bits of that. Stuart. -- Forwarded message -- From: Stuart Ballard [EMAIL PROTECTED] Date: Nov 3, 2006 12:29 PM Subject: Re: Japi diffs for harmony To: Stefano Mazzocchi [EMAIL PROTECTED] Cc: harmony-dev@incubator.apache.org (this will probably bounce from harmony-dev, I'm not subscribed; feel free to forward it) On 11/3/06, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Stuart, I'm a *huge* fan of your Japi diffs (I admit that I have a sort of obsessive compulsion about it, getting happy with every small percentage increase and sad when it decreases). *grin* I do the same thing for Classpath. To be honest I find the Harmony results confusing myself; sometimes they seem to bounce up and down with the same errors getting added and removed over and over again. I'm dependent on an unofficial source for Japi files of Harmony, though, because the project doesn't provide official nightly builds as far as I know - and my suspicion is that perhaps different variations are getting built and I'm getting which ever happens to be the last that was built. I haven't gotten around to asking, though, sorry about that. If I could grab an actual tarball of the very latest build at any given time, I'd like that better. See http://builder.classpath.org/dist/ for what they do which is perfect for me. That said, I have a few questions to ask, see below. Great, I'm always happy to clarify this stuff :) It tells me there are 10 packages and 52 classes missing. Great. Then it gives me a percentage. Who is that percentage calculated? Is it by class coverage? method coverage? package coverage? a weighted sum of all the above? The percentages are admittedly difficult to define in a way that's truly meaningful, but the idea of *having* a percentage was too compelling for me not to try to come up with a definition. So here's how Japi calculates it: First of all, anything whatsoever that's neither public nor protected is discarded. Each class or interface (or enum or annotation) counts as one item. Each field, method or constructor within a class counts as one item. *Including* inherited fields and methods, regardless of whether they get overridden in the class itself. Each of these items gets classified as good, bad, minor or missing. If an entire class is missing, *all* its members are classified as missing. Likewise if an entire package is classified as missing, all the classes within it and all their members are counted as missing. If there is more than one error on the same item (eg a class is incorrectly abstract, doesn't implement the right interface *and* has the wrong serialVersionUID) it still only counts as bad once (the serialVersionUID is a minor error but the bad errors take precedence). The percentages are then calculated based on the total count in the left-hand API. In other words if a particular package in the RI had only one single interface with four methods, of which Harmony implemented two correctly and one incorrectly, the percentages for that package would be: 60% good (the interface itself + 2 methods) 20% bad (one method) 20% missing (one method) If Harmony also incorrectly added an extra method to the interface, it would be 60% good, 20% bad, 20% missing, 20% abs. add. (Because while adding members in general is legal, because it's backwards compatible, adding methods to interfaces or abstract classes that have public or protected constructors is not). And yes, that's a total of 120%, because it's a percentage of the left-hand API, and an abs-add error indicates something outside that API. Incidentally the inclusion of inherited members for calculating the percentage causes some strange effects; - because of inherited methods from Object, simply declaring a class has a disproportionate effect, even if none of the declared members of that class itself are present. And because an enum, for example, inherits so many members from Object and Enum, merely declaring an enum has a hugely disproportionate effect compared to the tiny amount of code it takes. But I couldn't come up with another way of defining the percentages that would make sense and be self-consistent. The reasons why are a little complicated and this email is already long so I won't go into them, though. How is it possible that jdk15 vs harmony is 94.66% and harmony vs jdk15 is 90.88% Wow, I'm impressed that harmony is 94.66 against 1.5. That's incredibly good progress - especially if all of that is actual functional implementations
Re: Interesting discoveries playing around with japitools
I've been following this thread as best I can from the archives. I suspect the results you're getting were from the last release of Japitools. I can't blame you for this - I ought to have made a new one long ago - but the last release has a bunch of known bugs compared to the current code. In particular the last release should definitely not be used for anything where 1.5 language features are present. The latest CVS code should be vastly improved; if you try this and you're still seeing unexplained discrepancies, please let me know. I'm planning to bundle up the current code into a new release in the next few days, and I'm also revamping the website with the intention to make it clear that the CVS code exists and is generally recommended. (The very-much-work-in-progress new site can be seen at http://sab39.netreach.com/japi). One particular issue of note, because it concerns an issue that I just (re)discovered on the Classpath results also: QName appears to trigger an ecj bug in certain versions which produces an invalid class file by incorrectly inheriting a generic parameter into a *static* inner class. Apparently the latest ecj fixes this. I'm not 100% sure that this is the issue that's causing it to be incorrectly reported missing - but it seems awfully coincidental that the very same class with that issue is the one that you're seeing problems on. I'd really love if some Harmony developers would join the japitools mailing list if you're interested in the Japi results and how to make best use of them. I plan to announce both the lists and the new website more prominently when I have a new release to announce as well, but seeing as there was active discussion going on right now, I didn't want to wait. (Yes, the japitools list is on an FSF server. I really really hope that this isn't going to be a political problem for you guys. I selected Savannah for hosting japitools before Harmony even existed, because it made most sense at the time when Classpath developers were the main users. Please don't let that hinder our ability to communicate on something that makes sense for all projects concerned) Stuart. -- http://sab39.dev.netreach.com/
Re: Update on build status
Mark Hindess mark.hindess at googlemail.com writes: Our local builds now complete a two stage build. First with a certified JDK and then with the eclipse compiler running on the VME and deploy directory from the first stage build. They then run the tests. This seems a good point to jump in and say that I'm now generating nightly Japi reports based on the latest CVS too. I'm also producing nightly diff emails (whenever something changes) that are being sent in the general direction of this list, but presumably being refused because the address they're being sent from ([EMAIL PROTECTED]) isn't a subscriber (in fact, I don't even receive mail there so I couldn't subscribe it if I wanted to). If someone could unblock it, that'd be great. Sometimes the results change as a result of bugfixes in Japi itself (I'm looking into two suspicious lines in the Classpath output right now that might need Japi changes), but for the most part you'll only get emails based on changes to Harmony. Thanks, Stuart.
Re: Understanding JAPI tools (was: Re: [jira] Created: (HARMONY-163) Three types in java.util.jar are not implemented in Harmony)
Tim Ellison t.p.ellison at gmail.com writes: Stuart: is there some way to avoid JAPI taking inherited API signatures into account when doing the diff? kinda like the javadoc tool. This is something of a Japi FAQ (I should probably put together a Japi FAQ page somewhere now that it's no longer the case that pretty much everyone using Japi is on the Classpath list ;) ). The answer is no, it doesn't do this, and I'm not going to implement it. The reason is that whether a method is overridden or not is *not* part of the public API. Javadoc documents it, sure, but that's not really sufficient to say whether it's part of the API or not - it's quite likely it was simply easier to write Javadoc that way (so it didn't have to go and find the doc comments in the superclass's source file, etc). The rules of binary compatibility say that moving a method up or down the class hierarchy is a completely compatible change. A method may be overridden, or not, purely for performance reasons and the behavior could be completely identical. For example, LinkedList.subList is not documented as being overridden, but if it's not, that guarantees that the iterator() method will always be at least O(N) where N is the startIndex that the sublist was created with. An overridden LinkedList.subList method could hang on to the start and end nodes of the list and provide an O(1) implementation of iterator(). As long as some effort was taken to ensure that serialization stayed compatible, there's no reason why a Free runtime shouldn't do that optimization even if Sun doesn't. I've also heard of cases where Sun documents a method as being overridden even though as far as any testing can determine, all it does is call super. There should be no obligation for any Free runtime to duplicate this inefficiency. It's also possible to implement a method that needs changed behavior in a subclass by making the superclass delegate some parts of its behavior to non-public methods, so the superclass method is unchanged but the subclass just overrides the non-public methods (obviously, this only works if the subclass is in the same package, but that's pretty common). Finally, it's possible (albeit unlikely) that even if there *was* an apparent need to override a method in a subclass because it has different behavior, there might be some weird optimization-related reason why somebody might want to actually write it as if (this instanceof Whatever) in the superclass. I can't see why that would happen, but if someone did that and got all the behavior right, they shouldn't be penalized for it in Japi. Basically, Japi's business is to test the coverage of the API, and it's a fundamental design decision that Japi will *not* be testing implementation details. I've done quite a lot of work fixing bugs where implementation details inadvertently get exposed in the Japi results and if I find any more I'll fix them too. I think this is *extremely* important because, among other things, it's the *only* reason I feel legally secure in distributing Japi files for the JDK. As long as they only contain functional information necessary for interoperability, they're uncopyrightable. If they start exposing copyrightable implementation details, they become derived works of the JDK, and illegal to distribute (or, technically, to even create in the first place). And potentially so do the results of the comparisons. And if you then use those comparisons to make decisions on what to implement in Harmony, it jeopardizes Harmony's cleanroom status too. (IANAL; the people who actually decide whether legal risks are acceptable might think this isn't actually a problem for Harmony, but *I* don't want to be responsible for it ;) ) The right way to ensure that you've overridden all the right methods is to test the *behavior* of those methods. Obviously this is a lot more work than a simple automated run via Japi or equivalent, but it's the only way to get meaningful results. Obviously since Japi is Free Software I can't prevent others from making a version that does this, but I hope I've shown why I think it would be a bad idea. Stuart.
Re: [jira] Created: (HARMONY-146) doxygen build is broken
Mark Hindess mark.hindess at googlemail.com writes: Since these are generated files they probably shouldn't be in svn in the first place. Though I can see why it is handy to have them there. Perhaps we need a snapshot on the web site? Was it something the automated build process have informed us about ? The build is currently only doing cd make; ant. I can add the doc build but at the moment the ant tasks are configured to ignore failures so the build wouldn't actually break. I thought the results of the builds were already in http://cvs.apache.org/dist/incubator/harmony/snapshots/ That's what I've been using for Japi results. I did notice that the last run was from Feb 17th, but I thought that was just because no automated build was running. If there *is* an automated build running, could its output be made available somewhere so the Japi results can be based on the latest CVS rather than two weeks old? Thanks, Stuart.
Re: classlib build status emails?
Stuart Ballard stuart.a.ballard at gmail.com writes: If you can give me an url that will always point to the latest jar file(s), I can set up nightly japi results and mail diffs to this list. Geir gave me a pointer to the latest snapshots, so the japi results are now online: http://www.kaffe.org/~stuart/japi/htmlout/h-jdk10-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk11-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk12-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk13-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-harmony-jdk15 The last report triggers a recently-discovered bug in japitools that causes some StringBuffer methods to be incorrectly reported as missing in jdk15 (which would mean that they are extra methods in harmony). I suggest ignoring the last report for now, or at least verifying anything it claims against Sun's documentation before acting on it. Other than that the reports should give correct information about Harmony's coverage of the API defined in each JDK version. Whenever these results change for better or worse, (unless I've screwed something up), an email will be sent to this list with the differences. Stuart.
Re: classlib build status emails?
Mark Hindess mark.hindess at googlemail.com writes: Is there any interest in having build status emails sent to this list? I'm building classlib trunk with continuum and it would be simple for me to have messages like the following sent to the list whenever the status of our builds change. Currently I'm building only on linux but I plan to get windows builds running in the next few days. Are the resulting rt.jar (and/or jce.jar and/or jsse.jar, or equivalent) files available anywhere? If so (as discussed previously on this list) I'd be interested in producing japi comparisons to show API coverage and errors against the various JDK versions. If you can give me an url that will always point to the latest jar file(s), I can set up nightly japi results and mail diffs to this list. (please keep me CC'd on responses, I can't keep up with the harmony list and only check the archives intermittently) Stuart.
Re: newbie to project-where to start from
Geir Magnusson Jr geir at pobox.com writes: I think we should certainly be using Muave for testing. However, that doesn't remove the need for our own unit tests to be testing implementation internals. Completely agree. Tests of implementation internals don't belong in Mauve of course. I guess the question is whether, when a Harmony contributor wants to write a test for documented, public, specified API functionality, should that test go in Mauve instead of Harmony's own test framework? Obviously I'd argue that it should, as then it benefits all implementations, not just Harmony. Plus if Harmony contributors are running Mauve regularly, they're getting the benefits of Mauve tests contributed by developers of other implementations too. (I've watched people go down this road before: I was following several projects with independent class library implementations years before there was any prospect of them merging into Classpath as they've now done. Even when there was no cooperation on the library code, everybody seemed to agree it was in their best interests to collaborate on the test suite...) If it *is* recommended for Harmony contributors to put such tests into Mauve, that recommendation probably ought to be mentioned in answer to questions like the one that I replied to; the original poster didn't say whether their tests were going to be of implementation internals or not... Would you like to help us get it working in our build/test framework? I'm afraid you're asking the wrong person: I can't get Mauve working at all... Stuart.
Re: build fails - what next?
Geir Magnusson Jr geir at pobox.com writes: That's the problem. As far as I know, GCJ isn't quite complete yet... [javac] (at line 63) [javac] encodedParams = (byte []) s.readUnshared(); [javac] [javac] The method readUnshared() is undefined for the type ObjectInputStream http://www.kaffe.org/~stuart/japi/htmlout/cvs/h-jdk14-classpath#err_missing_java_io Congratulations! You managed to hit one of the only two missing methods in Classpath's implementation of java.io. Might want to report what this breaks on the Classpath list - they're usually quick to fix holes like this if they break a real app, especially if it's a Free one. Of course, getting it fixed is an entirely different issue from getting it into gcj in a released version of your distro... Stuart.
API coverage results for Harmony?
(please keep me cc'd as I'm not subscribed to this list) First off, I'd like to admit up front that I haven't been following the Harmony project very closely and so I'm pretty ignorant about the state of your progress, so please forgive any stupid misconceptions I may have. I maintain a set of programs called japitools (http://www.kaffe.org/~stuart/japi/ - not part of the kaffe project as such, they just generously offered to host the homepage) which can be used to produce (among other things) reports of how well a particular J2SE implementation covers the API defined by Sun's reference implementation. In collaboration with the Classpath developers I've been producing nightly results of Classpath's coverage of each JDK release, as seen for example here (and others linked from the homepage): http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-classpath-generics I also send out emails to the classpath-testresults mailing list with reports on the differences, if any, between each night's results, which is a handy way to catch any API coverage regressions that might be introduced, as well as a nice concrete way to see progress being made. My understanding is that the Harmony project has made pretty significant progress on its own class library implementation and I thought you might be interested in producing similar nightly reports for Harmony. If you are interested, there are a couple of ways we could go about it. My machine doesn't have the resources to build a J2SE implementation itself so for each project I report on I rely on their own nightly build infrastructure. (I don't know if Harmony has such a thing set up already; alternatively a developer could set up nightly build scripts on their own machine). Ideally (and to match what other projects do) the script would also check out the latest japitools source code, build it, and run the Japize tool to produce a harmony.japi.gz file, and then make that file available for download somewhere. I'd then configure my scripts to download that file and produce the comparisons you see (I can also provide those scripts and the JDK japi files so if you want to run them yourselves you can - there's nothing secret about them ;) ). If running Japize yourselves is a problem for any reason, if you instead made your equivalent(s) of rt.jar (and jce.jar and jsse.jar if you have them) available for download, I could do the Japize as part of my script too. Is there any interest in something like this? If you want nightly difference reports sent to some mailing list, please also let me know which list :) Thanks, Stuart.
