Re: gij: unrecognized option -- `-o'
I'm FAR from an expert on any of this but looking at the line at issue: > gij -classpath antlr.Tool -o > ../tools/generated/gnu/classpath/tools/gjdoc/expr/ \ > ../../classpath-0.98/tools/gnu/classpath/tools/gjdoc/expr/java-expression.g > gij: unrecognized option -- `-o' I think I see two spaces after -classpath which makes me think there's a missing argument in there. Also, antlr.Tool looks like a classname not a classpath. So I'm guessing that this should be: gij -classpath "something" antlr.Tool -o ... Then -o is an argument to antlr.Tool, not to gij. Where you go from there, how you get a correct value into the missing classpath parameter, I'm not sure... Stuart. -- http://sab39.netreach.com/
Re: Classpath 0.96 Imminent
On 10/8/07, Andrew John Hughes <[EMAIL PROTECTED]> wrote: > That does seem appropriate :D After I posted that I realized that I could have made a Firefly reference and suggested "Too pretty to die"... I don't know if any Classpath hackers are browncoats though. > How are the JAPI runs made at the moment? It would be nice if there were > IcedTea ones. I'd also like a run against JikesRVM, if only a one off; there > are some mismatches in the VM classes at present. I'm afraid I've been unforgivably lax in the Japi department lately; the runs have been broken for a few weeks (since I blogged about it) and I've never gotten around to figuring out why or fixing it. I apologize. I don't want to make a commitment to fixing them within a particular timeframe that I can't keep, though. I'll try to get to it this week sometime, but I can't promise. Are there nightly builds of IcedTea somewhere downloadable in binary form? If so I'd be thrilled to be able to include those in the Japi runs. Stuart. -- http://sab39.netreach.com/
Re: Classpath 0.96 Imminent
On 10/8/07, Andrew John Hughes <[EMAIL PROTECTED]> wrote: > Anyone want to suggest a suitable name? ;) "Staying Alive"? Stuart. -- http://sab39.netreach.com/
Re: legal/policy questions (Was: [cp-patches] RFC: AWT Peers update)
On 6/22/07, Mark Wielaard <[EMAIL PROTECTED]> wrote: Thanks and indeed we should. So if anybody else has any scenarios and would like feedback then please ping me and I try to sneak them in the conversation I will have tomorrow. I don't know how much time I have and there is already a list of legal/policy issues to go through with respect to classpath/openjdk but I can always try. Do you have this list of issues in an easily-postable form? I think that if so seeing the list would be helpful to the discussion, both from the perspective of avoiding duplication, and because the items already on the list might inspire someone to think of a new one. Stuart. -- http://sab39.netreach.com/
Re: Experimental Build Repository at icedtea.classpath.org
On 6/9/07, Mark Wielaard <[EMAIL PROTECTED]> wrote: That would be cool! But we currently don't have the build setup (currently investigating how to get it all going on Debian 3.0/Etch, because people have till now only used Fedora 7 to bootstrap, but almost all our classpath infrastructure machines are Debian based) nor do we really have the capacity to do such a massive build, but maybe we can add it to builder.classpath.org later on. So you will have to do with compiling from source yourself for now. My machine is also Debianish (Ubuntu actually) and definitely doesn't have the resources for massive builds (I actually do the runs on my workstation at work; if something goes wrong and they're still running when I get into the office I definitely feel the effects). So I really can't do something like that right now. Let me know if and when such a builder does get set up, though, and I'll definitely add it to the matrix. Thanks, Stuart. -- http://sab39.netreach.com/
Re: Experimental Build Repository at icedtea.classpath.org
Are there builds of this similar to the -latest files that builder produces? I'm going to be doing some work updating the Japi runs for harmony this weekend and I thought it'd be interesting to see how IcedTea fares japiwise. I suppose that becomes less interesting if the stuff IcedTea is missing isn't reflected in the API itself, but still... Stuart. On 6/7/07, Andrew John Hughes <[EMAIL PROTECTED]> wrote: On Thursday 07 June 2007 19:01, Mark Wielaard wrote: > This announcement might be exciting news for some. > > IcedTea is basically a OpenJDK/GNU Classpath hybrid that can be used > to bootstrap OpenJDK using only Free Software. You will need the latest > gcj & ecj versions (Fedora 7 has them, but build instructions for other > GNU/Linux distros more than welcome of course) to play with it. > > We agreed to host it at http://icedtea.classpath.org/ because it is > such a valuable effort for the whole libre java community. But > IcedTea isn't an official GNU Classpath effort. Participants are > encouraged to push all their changes upstream into classpath > and openjdk. It is basically a staging area for people to play with > till all legal and technical issues of merging the code bases have > been worked out. > > Please join the openjdk distro-dev mailinglist to discuss this effort. > http://mail.openjdk.java.net/mailman/listinfo/distro-pkg-dev It's very exciting news, Mark... gonna have to play with this now! Cheers, -- Andrew :-) Help end the Java Trap! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net -- http://sab39.netreach.com/
Re: [cp-patches] FYI: Add Enum.finalize()
Bear in mind that Enum's empty final finalize() method is a security fix, preventing subclasses from creating illegal enum values. That security fix can easily apply to other classes too - any class which wants to control when subclasses can be instantiated by throwing exceptions from the constructor needs a final finalize(). I don't know whether this applies to Inflater but it does suggest that optimizing for empty finalize() is a good idea regardless, because people shouldn't have to choose between performance issues and security. (optimizing for a finalize() that simply calls super.finalize() might be worthwhile too?) Stuart. On 21 Dec 2006 09:16:07 -0700, Tom Tromey <[EMAIL PROTECTED]> wrote: > "Twisti" == Christian Thalinger <[EMAIL PROTECTED]> writes: Twisti> 87% precent of the heap allocations with a finalizer have an empty Twisti> finalizer. The class responsible for this is java/util/zip/Inflater. I think we can simply delete Inflater.finalize. Tom -- http://sab39.netreach.com/
Re: Japi diffs for classpath
On 11/24/06, Stuart Ballard <[EMAIL PROTECTED]> wrote: -Methods: 24 missing. +Methods: 21 missing. -method java.beans.beancontext.BeanContextServicesSupport.getChildBeanContextServicesListener(java.lang.Object): not implemented in classpath -method java.beans.beancontext.BeanContextSupport.deserialize(java.io.ObjectInputStream, java.util.Collection): not implemented in classpath -method java.beans.beancontext.BeanContextSupport.serialize(java.io.ObjectOutputStream, java.util.Collection): not implemented in classpath I didn't see any message on -patches that would account for these. Anyone want to take credit? Stuart. -- http://sab39.netreach.com/
Re: Proposal for a response to SUN's announcement
On 11/17/06, Nick Hill <[EMAIL PROTECTED]> wrote: "The reaction of many Classpath developers can be seen on planet.classpath.org." On IRC the sentence we came up with - but possibly after you drafted your mail - was "The planet.classpath.org website carries the reactions of many individual Classpath developers." I think this version is an improvement, but I'm biased because it's my phrasing in the first place :) 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/
Anyone pondering HotSpot+Classpath?
It looks like it's *already* possible to download the GPL source code for Sun's HotSpot VM[1]. But of course that's of limited use until they also release their class libraries. But funnily enough there just happens to be a Free set of class libraries lying around ;) I know that I can't possibly be the only person thinking it. But I do know I'm not even close to having the expertise or the time to research what it would actually take to implement the Classpath VM interface on top of HotSpot. I'm just curious as to whether anyone who *does* have the expertise and time is planning to take a serious look at this... Stuart. [1] Can I just take a moment to add "WOW" at this point? -- http://sab39.netreach.com/
Re: glibj-generics-latest.zip on builder old?
They seem to as of last night's run. I'm not aware of any remaining problems, although that doesn't mean there aren't any subtle ones of course :) Stuart. On 11/7/06, Mark Wielaard <[EMAIL PROTECTED]> wrote: Hi Stuart, On Tue, 2006-11-07 at 08:38 -0500, Stuart Ballard wrote: > On 11/7/06, Mark Wielaard <[EMAIL PROTECTED]> wrote: > > > Things still seem to be broken on builder. I'm guessing 3.1.2 is too > > > old, as problems > > > with the java.util.concurrent stuff seems to have been reintroduced > > > > I upgraded the ecj on builder to v_677_R32x, 3.2.1 > > (ecj-bootstrap-gcj_3.2.1-3_i386.deb) > > Part of the issue is Japitools aborting entirely part way through > Japizing when certain kinds of corrupt class files are encountered. > > Work on fixing this is in progress. Ah, that would explain why whole packages were disappearing from the comparison. Thanks for working on Japitools. I wish more projects would use it when they do new releases to get a good overview of compatibility between releases. Do the zip files as published at http://builder.classpath.org/dist/ work correct for Japitools now? Cheers, Mark -- http://sab39.dev.netreach.com/
Re: glibj-generics-latest.zip on builder old?
On 11/7/06, Mark Wielaard <[EMAIL PROTECTED]> wrote: > Things still seem to be broken on builder. I'm guessing 3.1.2 is too > old, as problems > with the java.util.concurrent stuff seems to have been reintroduced I upgraded the ecj on builder to v_677_R32x, 3.2.1 (ecj-bootstrap-gcj_3.2.1-3_i386.deb) Part of the issue is Japitools aborting entirely part way through Japizing when certain kinds of corrupt class files are encountered. Work on fixing this is in progress. Stuart. -- http://sab39.dev.netreach.com/
Re: glibj-generics-latest.zip on builder old?
On 11/1/06, Mark Wielaard <[EMAIL PROTECTED]> wrote: Looking through the log it is: 1729. ERROR in ../../classpath/java/util/EnumSet.java (at line 252) return copyOf((EnumSet) other); ^^ The method copyOf(EnumSet) is ambiguous for the type EnumSet So do we reckon this is a Classpath bug or an ecj issue? Andrew, presumably -generics builds for you - how does your ecj version compare to the one on builder? Stuart. PS I know, I'm being a pain in the neck, I'm just impatient to see the Japi results with that latest merge in ;) Sorry -- http://sab39.dev.netreach.com/
glibj-generics-latest.zip on builder old?
On http://builder.classpath.org/dist/, glibj-generics-latest.zip is dated Oct 18th as opposed to all the other files including classpath-generics-latest.tar.gz and glibj-latest.zip which are dated Oct 31st as expected. Is something up with the generics build causing it to fail to produce an updated zip? This is why Andrew's hard work with the generics merge the other day didn't result in a wonderfully huge Japi diff email... Thanks, Stuart. [DIR] Parent Directory 30-May-2006 21:17 - [ ] README 22-Feb-2006 19:55 1k [ ] classpath-future-release-latest.tar.gz 28-Aug-2006 19:27 8.6M [ ] classpath-generics-latest.tar.gz 31-Oct-2006 22:03 9.1M [ ] classpath-latest.tar.gz31-Oct-2006 21:31 8.8M [ ] glibj-future-release.zip 28-Aug-2006 19:39 8.1M [ ] glibj-generics-latest.zip 18-Oct-2006 08:15 8.6M [ ] glibj-last-release.zip 20-May-2006 12:20 7.7M [ ] glibj-latest.zip 31-Oct-2006 21:46 8.3M -- http://sab39.dev.netreach.com/
Re: Free implementations of [un]pack200?
Thanks for the hint :) A little googling found his blog which has this gem dated Oct 14th: "Following on from my last success, I'm pleased to report that I've managed not only to decompress the data, but also reassemble it into a suitable archive and write it out. It handles any non-class file, and currently, .class files that are entirely empty interfaces. So, if you've got any oversized archives of types like java.io.Serializable, this could save you literally a hundred bytes or so ..." Sounds like he's making good progress but has quite a ways to go. I'll have to go with the "JDK from a trusted source" approach I think :) Thanks again, Stuart. -- http://sab39.dev.netreach.com/
Free implementations of [un]pack200?
I'm trying to figure out if it's possible to manually extract the ".bin" files provided of JDK6 betas so that japi can be run on it on a nightly basis (without having to actually execute the code, since I can't guarantee I can trust the source). Turns out after a few false starts I should have done what my instinct was in the first place and just run "unzip" on it, because it is a valid zip file. However there isn't an rt.jar file inside the zip, but an "rt.pack" file instead, which apparently can be extracted using an "unpack200" program that as far as I can tell has been bundled with the JDK since 1.5 (this was news to me ;) ). Running the unpack200 binary from inside the zip is of course just as bad as running the bin file in the first place, but I *could* of course install JDK 1.5 from a trusted source and use unpack200 from that. Before I resort to using non-free software in the japi runs, though, I figured it was worth asking if anyone knows of a Free implementation of this unpack200 thingumy. Stuart. -- http://sab39.dev.netreach.com/
Re: glibj-generics-latest.zip corrupt?
On 8/11/06, Mark Wielaard <[EMAIL PROTECTED]> wrote: Oops. We were cleaning up temporary build dirs to safe some space on builder. We shouldn't clean before copying the glibj.zip, so people can actually download it. Fixed. Now it's a valid zip :) I'm running a "nightly" japi run now, it'll take several hours and we'll get a very big diff for generics if everything works :) I also, hopefully, fixed the issue with AccessibleHTML so its inner classes should no longer show up. Stuart. -- http://sab39.dev.netreach.com/
glibj-generics-latest.zip corrupt?
I finally got around to investigating why the Japi generics comparisons aren't happening, and it appears to be because glibj-generics-latest.zip is not a valid zipfile and hasn't been for some time (it's been a long time since we had a successful -generics comparison run). Anyone have any ideas why this should be or how to fix it? [EMAIL PROTECTED]:~/defunct/japigenerics$ wget http://builder.classpath.org/dist/glibj-generics-latest.zip --10:53:23-- http://builder.classpath.org/dist/glibj-generics-latest.zip => `glibj-generics-latest.zip' Resolving builder.classpath.org... 208.99.205.123 Connecting to builder.classpath.org|208.99.205.123|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 786,432 (768K) [application/zip] 100%[>] 786,432 356.16K/s 10:53:26 (355.16 KB/s) - `glibj-generics-latest.zip' saved [786432/786432] [EMAIL PROTECTED]:~/defunct/japigenerics$ unzip glibj-generics-latest.zip Archive: glibj-generics-latest.zip End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. unzip: cannot find zipfile directory in one of glibj-generics-latest.zip or glibj-generics-latest.zip.zip, and cannot find glibj-generics-latest.zip.ZIP, period. [EMAIL PROTECTED]:~/defunct/japigenerics$ Thanks, Stuart. -- http://sab39.dev.netreach.com/
Re: javax.swing.text.html.AccessibleHTML: Should we write this?
Looks like according to Japi, AccessibleHTML is non-public but it has inner classes that are protected. Since these classes would be entirely inaccessible through the Java language, they should not be considered part of the public API, and I'll make a change to Japi to skip such classes. Unfortunately I'm having issues with my wrists and fingers right now and need to keep my spare time hacking to a minimum so it might take me a while before I can get to this. But the right thing to do for Classpath is definitely to NOT try to implement these, and Japi will get fixed in due course. Thanks for finding this bug! Stuart. -- http://sab39.dev.netreach.com/
Re: New japize option
On 4/23/06, Arnaud Vandyck <[EMAIL PROTECTED]> wrote: > Is there a way to ignore the default factory classes? > > I don't think this is an error: > http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-classpath.html#err_bad_javax_xml_datatype > > The default DataTypeFactory in Sun's implementation and in GNU Classpath > implementation will maybe never be the same. This is an API bug on Sun's part and can't be avoided by japitools; not only that, I believe it actually needs to be fixed. Suppose somebody compiles code like this against the JDK: DataTypeFactory dft = (DataTypeFactory) Class.forName(DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS); Because DATATYPEFACTORY_IMPLEMENTATION_CLASS is a constant, the actual string value will be substituted at compiletime. If this code then gets run against Classpath, it doesn't matter that Classpath's value of DATATYPEFACTORY_IMPLEMENTATION_CLASS is different. It's going to try to load Sun's version. The same problem happens in reverse if code is compiled against Classpath and run against the JDK. I don't know *how* this problem should be solved. Clearly my opinion is that Sun screwed up bigtime by putting this into a constant field. But I'm not going to make Japitools hide it. It is a real problem and should be fixed somehow. > This problem can show eatch time there is a factory pattern with a > default value hardcoded as a constant... but I did not find another > example ;-) Maybe I'm wrong. There was another problem in rmi.server, I believe, a while back. A field called something like packagePrefix. If you're interested it was one of the very few patches I've submitted personally so looking for my name in the changelog should take you to it. The same argument was made about the "correct" answer being different, but it was decided to match Sun's value for the same reason I gave above. Stuart. -- http://sab39.dev.netreach.com/
Automatic testing of error handling
(tried sending this earlier but I think I got bit by the DNS issue) Mark Hindess of the Harmony project has written an interesting little test tool that I thought you guys might be interested in. I haven't time to look at it very closely myself, but the concept seems sound. As I understand it what he does is take a japi file and generate tests which call constructors and static methods with various combinations of probably-invalid arguments, such as empty strings and nulls. For each one it then records the exception thrown if any by the implementation for comparison with other implementations. It seems like a good way to catch corner-case differences which are unlikely to be caught any other way - until some application gets an exception different than the one it was expecting and falls over. His script is available here: http://issues.apache.org/jira/browse/HARMONY-325 Thoughts? Feelings? Stuart. -- http://sab39.dev.netreach.com/
Re: Some GdkGraphics2D problems disappear with G_SLICE=always-malloc
Just to summarize / save anyone else from digging through all those links, it seems the issue is that objects allocated with one API were being freed by another (I didn't see what the allocation API was, but the "free"s in question were g_free (incorrect) and g_object_unref (correct). g_free() is a wrapper around free() which means that it happens to work if the allocation API ends up being a wrapper around malloc() (which is why always-malloc works around the problem). When the new, more efficient allocator is used instead (which AIUI grabs some large chunks of memory and manages them itself so there are lots of objects per single malloc()ed chunk), free() fails, and so g_free() does too. If classpath is hitting this in the same way everyone else is, it's not a glib bug, it's definitely a Classpath bug. Stuart. On 4/2/06, Wolfgang Baer <[EMAIL PROTECTED]> wrote: > Roman Kennke wrote: > > Hi Mark, > > > >> Since there was so much talk again about our GdkGraphics2D > >> implementation I tried playing again with it some more. And I noticed it > >> is stabler when running it with: > >> export G_SLICE=always-malloc > >> Otherwise I often would get a > >> *** glibc detected *** free(): invalid pointer: 0x086cdb18 *** > >> This is probably some bug in our code that needs a specific glib > >> allocation strategy to work. But I haven't been able to find any details > >> yet. > > > > According to Dalibor this is probably even a bug in glib. > > This is filed as bug 26803 [0] already. Maybe the debian thread there > might help to find the problem. > > Wolfgang > > [0] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26803 > > > -- http://sab39.dev.netreach.com/
Re: New japize option
On 4/1/06, Mark Wielaard <[EMAIL PROTECTED]> wrote: > Maybe a better solution in that case is to invent a "magic" > serialVersionUID number that means "not-really-serializable" and tag all > classes that are not guaranteed to serialize between different > implementations/versions this way? It will be a bit more work then just > excluding whole packages of course. But at least it is more accurate and > can be used also in other situations. There are a couple of downsides to this idea. 1) With the current setup, the rule that "this class probably can't be serialized across versions" is actually somewhat enforced, in that (to a first approximation) whenever a change happens that could potentially cause incompatibility, the automatically-calculated svuid changes and deserialization fails. If the svuid were hardcoded to a constant, the deserialization behavior would be more unpredictable and more likely to do the wrong thing without actually failing. 2) The magic value would have to be in Classpath because we're not going to get Sun to change the svuids on all their Swing classes. This means providing a way to suppress a Japi error that's entirely in the hands of the people who have a motivation to lower the number of Japi errors. Not that I think any Classpath would abuse it, but not everyone has such careful code review to prevent a zero-svuid going in by mistake. Putting it in the invocation of Japize has the advantage that the knowledge of what's not serializable gets encoded in the *JDK* japi, not the classpath one. I'll see if I can come up with a procedure by which we can check exactly which classes the warning applies to. By the way, this technique *can* be applied to other situations too. The syntax is "-pkg.name,ClassName:serial" where the ",ClassName" is optional. The named class, and all its subclasses, will be treated as not serializable. This gives a lot of flexibility - for example, if it were discovered that the warning only shows up on JComponent and its subclasses, "-javax.swing,JComponent:serial" would do exactly what we want. And if you're comparing something other than the standard API, you can make use of it there too. Stuart. -- http://sab39.dev.netreach.com/
Re: New japize option
On 3/31/06, Andrew John Hughes <[EMAIL PROTECTED]> wrote: > I believe it's on the individual Javadoc pages for each Swing class e.g. > on JComponent: > > 'Warning: Serialized objects of this class will not be compatible with > future Swing releases. The current serialization support is appropriate > for short term storage or RMI between applications running the same > version of Swing.' Yuck, so there's no easy way to verify that it actually does apply to *every* class in swing? Stuart. -- http://sab39.dev.netreach.com/
New japize option
I added a new option to Japize to allow excluding svuid information for a particular set of packages or classes. I'm using it on my scripts but I'm mentioning it here because you might want to use it for the runs on Builder too. japize as xxx packages +whatever -whatever -javax.swing:serial That will cause all classes in javax.swing to be emitted without svuids, as if they weren't serializable (although the fact that they implement java.io.Serializable will still be recorded and checked). (I also arranged for enums to get that treatment automatically). Also, any class that *inherits* from a class that's emitted this way will also be emitted without a svuid, because if the superclass isn't serialization-compatible, the subclass pretty much can't be either. Anyone have any particular strong feelings on whether I ought to be specifying the whole javax.swing package or just, eg, subclasses of JComponent? And whether there are any particular bits that should *not* be excluded? (I don't know where to find the Sun documentation that says serialization of Swing isn't supported so I'm not sure exactly what it applies to...) Stuart. -- http://sab39.dev.netreach.com/
Re: SerialVersionUID missmatches
On 24 Mar 2006 12:45:27 -0700, Tom Tromey <[EMAIL PROTECTED]> wrote: > I don't really know what we should do long term. Maybe fixing these > to be compatible is best. However it isn't sufficient to add the > serialVersionUID, you need to also make sure that the serialized > forms are the same. Usually this involves renaming fields and > marking some transient. Perhaps in the same spirit as the "throws NotImplementedException" hack, we could add a "NotReallySerializable" interface that classes whose svuids should be ignored could implement... I'm not overly fond of that idea, though. It's one thing to allow implementations to voluntarily list *extra* problems, it's another to give them the ability to arbitrarily *suppress* problems. Thoughts? Stuart. -- http://sab39.dev.netreach.com/
Re: [cp-patches] Patch: FYI: implement NumericShaper
On 3/23/06, Andrew John Hughes <[EMAIL PROTECTED]> wrote:
> I'm pleasantly surprised; the score (for 1.4 at least) doesn't seem to have
> gone
> down too far (or, at least, not as far as your comments led me to expect).
> However,
> after a period of such JAPI growth, it will be interesting to see the
> dramatic decline...
I'm a little surprised that in the entire history of Japi nobody's
ever asked me how the percentages are actually calculated...
Basically, since Japi considers all members including inherited ones,
you effectively get one point for a class plus one point for each
field, constructor, or method - *including* inherited ones.
What this means is that as soon as you add *any* class, the mere
existence of that class gains you (if I'm counting right) six points:
The class, equals, hashCode, wait, notify, notifyAll. A class which is
supposed to have six methods of its own would be listed as 50%
complete just by typing "class Foo {}".
This is a little unfortunate - another side effect is that AWT and
Swing classes weigh disproportionately highly in the Japi scores
because they have ridiculously many inherited members from
(J)Component - but hard to avoid given that Japi makes no distinction
between members that are inherited or not.
So I'm not surprised that the percentage score didn't go down too
badly by just modifying the flags on methods.
I think we're getting close enough to completeness that the *count* of
errors is more interesting than the percentage anyway. And the error
count against 1.2 just went from 2 to 246 :)
Stuart.
--
http://sab39.dev.netreach.com/
Re: partial stub
On 22 Mar 2006 11:27:53 -0700, Tom Tromey <[EMAIL PROTECTED]> wrote: > I'm not sure what to do here. I'm inclined to mark it as a stub. > But maybe it isn't that different from any other 'FIXME'... comments? I'd say as long as it's searchable (ie, FIXME) it's not a terribly big deal. (Suggestion: Put the results of "rgrep -i FIXME classpath/" in a text file linked from builder's homepage...). Japi can't cover everything anyway - what about if imageio is completely implemented but doesn't support any file formats? What about if crypto is completely implemented but no algorithms exist? The danger of stubs is really methods that aren't marked in any way, just sitting there, failing to work... If you want a way to mark such things, though, I can add another magic exception marker to Japi for them (PartialException? FixmeException? TodoException?) that would flag as "bad" rather than "missing". I guess another danger is that if we use the same FIXME keyword for actual missing or broken functionality as we do for things like "it would be nice to rearchitect this so the code was cleaner", the real problems become hard to search for that way too. Maybe we should standardize on particular strings to put in comments to indicate different levels of unfinishedness? Stuart. -- http://sab39.dev.netreach.com/
Re: [cp-patches] Patch: FYI: implement NumericShaper
On 22 Mar 2006 09:57:16 -0700, Tom Tromey <[EMAIL PROTECTED]> wrote: > I didn't check it in yet...? Or do you mean that your own test case > for this didn't work? No, I had missed the fact that it wasn't checked in. D'oh! > BTW, I may have found a japi bug. Yesterday I checked in > java.text.Bidi. There are now no errors or anything for java.text, > but this package is still 92.04% good: > > http://builder.classpath.org/japi/jdk14-classpath.html >From that page: "Differences between jdk14 and jdk15 have been ignored. Since these are not counted as good OR bad, they may cause percentages not to add up to 100%" I made it red and stuck it right at the top of the results... Specifically, in this case, it appears that Sun dropped three classes from java.text in 1.5. http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-jdk15#err_missing_java_text My new motto: never attribute to a Japi bug what can be adequately explained by Sun's stupidity ;) Stuart. -- http://sab39.dev.netreach.com/
Re: [cp-patches] Patch: FYI: implement NumericShaper
Hmm, and it didn't actually work in Japi for some reason anyway. I'll investigate. Stuart. -- http://sab39.dev.netreach.com/
Re: [cp-patches] Patch: FYI: implement NumericShaper
On 20 Mar 2006 11:45:27 -0700, Tom Tromey <[EMAIL PROTECTED]> wrote: > Having a list of stubs would be a good start. The ones I fixed this > weekend I ran across by chance; I had no idea we had stubs in AWT at > all. > > I like David's idea of a STUB comment. Does anyone know if eclipse allows plugging in custom rules to produce warnings, and where (if anywhere) there's documentation on how to produce such rules? I'd be interested in working on a "stub detector" but I don't really feel like writing an entire Java language parser for the purpose. If anyone can point me to a framework which made it fairly simple to write rules that define criteria based on the structure/semantics of the source code, I'll have a stab at this. FindBugs also sounds like the kind of thing I'm looking for (although I'd rather have something that could work on the source than on the bytecode, because I'm thinking it should be possible to ignore methods if they have a comment like "nothing to do here"), except that (last I heard) it wasn't runnable on a Free runtime. Is this still true? Stuart. -- http://sab39.dev.netreach.com/
Re: Flagging stubs -- was FYI: implement NumericShaper
On 3/20/06, Andrew John Hughes <[EMAIL PROTECTED]> wrote: > It sounds like a bad hack on the JAPI side, but it's up to you if you're > maintaining this. True enough, but I think the problem of stub-inflated japi reports is important enough to try to find some way of tackling it. Obviously an annotation would be nicer and I'll probably migrate to that once it becomes practical, but I'd rather have a hacky solution today than no solution at all for months. > I can't currently find NotImplementedException in > Classpath outside the new jdwp code, but I may be missing something. > If we have a gnu.classpath.NotImplementedException, then we could catch > this specifically in JAPI, and also output a nice message. I must have misremembered I guess. Japi actually scans for *anything* called "NotImplementedException" in any package (because I was writing this code while offline and besides I want it to work for other projects too who might not be happy with "gnu.classpath." (coughharmonycough). > The immediate problem I see (and why we don't generally use an exception) is > that the problem can still continue with an exception, whereas it can't with > an error. I could easily change it to "NotImplementedError", or accept either. The important thing from Japi's perspective isn't whether the exception *actually* gets thrown - it could be, or the class could silently do nothing as it currently does, which in some cases may still be preferable if the functionality is noncritical. All Japi cares about is whether it shows up in the throws clause. > The main problem I can foresee is actually finding all the code and putting > this in... Yep. Hence the question about automated scanning to find a list of candidates... :) I'd rather have a process that gives lots of false positives than a process that misses lots... Stuart. -- http://sab39.dev.netreach.com/
Re: [cp-patches] Patch: FYI: implement NumericShaper
On 3/19/06, Stuart Ballard <[EMAIL PROTECTED]> wrote: > As far as I can figure out, an annotation is pretty much the only way > to get these kinds of methods to get flagged by Japi. Actually, I figured out (and implemented in Japi) a place where we can carry a flag on any method without requiring 1.5 at all. Adding an unchecked exception to the throws clause has absolutely no semantic effect (and Japi knows this and ignores them), but Japi can be (and has been) modified to pick up a particular exception and report based on it. I believe Classpath already has an unchecked NotImplementedException so that's what I used. Any method marked as "throws NotImplementedException" will be reported by Japi as "not implemented in Classpath", in the same category as "missing" errors. Any feedback on this approach is welcome, I'm certainly willing to modify it if people have any suggested improvements. Note that I'm not suggesting we just leave all stub methods around indiscriminately and use this trick on them; stub methods that aren't inherited from a superclass and can be removed without breaking compilation should just be removed. But for the ones we can't remove, we can now flag them. Obviously, the throws clause technique only works on methods and constructors, not fields or classes, but I don't think this is a big problem. There's not really any such thing as a "stub field" (it's either there or not) and any classes made up entirely of stubs should surely be removed anyway. If this approach is acceptable to everyone, the next question is how do we identify the stub methods to flag them? Obviously there's no reliable programmatic way but it seems like a program ought to be able to report possible candidates for a human to look through. I think any stub method would fall into one of these categories: A) Void method that does nothing at all or nothing but return; B) Method that unconditionally throws; C) Method that unconditionally calls superclass implementation of the same method with the same args; or D) Method that unconditionally returns a hardcoded constant, including null. Obviously detecting these things would give a lot of false positives, especially D, but I think it should catch all the stubs. Anyone know of a good tool that could produce a list of methods meeting these criteria? Stuart. -- http://sab39.dev.netreach.com/
Re: [cp-patches] Patch: FYI: implement NumericShaper
On 3/19/06, Andrew John Hughes <[EMAIL PROTECTED]> wrote: > I'm only thinking about this for interfaces, where e.g. part of the > interface is implemented, the rest is stubbed. You remove the stubs, > and declare the rest abstract so it will at least compile (and be > comparable). Yes, it will break functionality, but that's an incentive > to fix the rest of it... Presumably, japi would pick that up as a > concrete/abstract difference and for each of the missing methods. > For anything else, they should be removed. I'm thinking of things like swing.text.html. My understanding is that currently several of the html View subclasses contain a number of stub methods where the actual HTMLy behavior still needs to be implemented to make the HTML render correctly styled, but if you were to declare the classes as entirely abstract, the HTML couldn't render at all (and applications which currently "run but look ugly" would stop running entirely). Of course I'm not a Swing hacker... anyone who's actually familiar with this code want to weigh in? > We could do this on generics. I already find 1.5 comparisons pretty > useless for HEAD, because it will never be able to implement all the > language features (and will have differences). Yeah, but isn't that just another set of divergences from the trunk to maintain? (then again, you're the person who'd have to *do* said maintaining, so I guess you've thought of that) Stuart. -- http://sab39.dev.netreach.com/
Re: [cp-patches] Patch: FYI: implement NumericShaper
On 3/19/06, Andrew John Hughes <[EMAIL PROTECTED]> wrote: > I think the interface problem you mention is the most obvious, but I > think this should be solvable by declaring the class abstract (which > shows up in JAPI too). It's a shame that we can't use annotations on the trunk; it wouldn't be hard to have Japi pick up an annotation which marked stub methods and flag any such methods as errors. What's the status on the whole ecj-as-gcc-frontend thing? Since gcj and ecj are pretty much the only maintained Free java compilers at this point, seems to me that's the only blocker to making the generics branch the primary development trunk and adopting the new language features wholesale... I also remember hearing about some stub methods in Swing which are currently defined as calling super.whatever(), which will eventually need to be overridden but currently other features in the class do work. Declaring the class as abstract would break working functionality; deleting the stub wouldn't have any effect on the japi results because the inherited method would be picked up. As far as I can figure out, an annotation is pretty much the only way to get these kinds of methods to get flagged by Japi. Stuart. -- http://sab39.dev.netreach.com/
Re: [cp-testresults] Re: Japi diffs for classpath
On 3/17/06, Stuart Ballard <[EMAIL PROTECTED]> wrote: > > Japi's supposed to consider replacing a nongeneric type with something > > that erases to that type as okay. > > Still looking into this one. Keep 'em coming! Found it - japicompat wasn't correctly calculating the erasure of "X&Y" style types. Fix for this one checked in too. Stuart. -- http://sab39.dev.netreach.com/
Re: [cp-testresults] Re: Japi diffs for classpath
On 3/15/06, Stuart Ballard <[EMAIL PROTECTED]> wrote:
> Or Javadoc is treating deprecation as if it inherits from the class to
> its constructor. More research needed...
A test run of Sun's javadoc confirms that it treats all members of a
deprecated class as deprecated; I've made this change to my local
japitools and I'll try to get it committed in time for tonight's run.
Could someone confirm that gjdoc correctly emulates this approach?
Interestingly, Sun's javadoc gets a little schizophrenic with inner
classes of deprecated classes: if you have code like this:
/**
* @deprecated
*/
public class Outer {
public class Inner {
}
}
the javadoc for Outer will list Inner as a *deprecated* inner class,
but the javadoc for Inner will state that it's not deprecated at all.
This suggests that we might want an Eclipse warning when a deprecated
class has a non-deprecated inner class, because it leads to
inconsistent documentation.
Not sure what gjdoc should do in this case, but I definitely think it
should issue some kind of warning too :)
For japitools, I've punted on this problem and said that inner classes
of deprecated classes aren't deprecated unless explicitly marked as
such.
> Japi's supposed to consider replacing a nongeneric type with something
> that erases to that type as okay.
Still looking into this one. Keep 'em coming!
Stuart.
--
http://sab39.dev.netreach.com/
Re: [cp-testresults] Re: Japi diffs for classpath
(oops, forgot to reply to all last time. Trying again...) On 15 Mar 2006 18:00:37 -0700, Tom Tromey <[EMAIL PROTECTED]> wrote: > >>>>> "Stuart" == Stuart Ballard <[EMAIL PROTECTED]> writes: > > constructor javax.accessibility.AccessibleResourceBundle(): deprecated > in classpath, but not deprecated in jdk15 > > This actually is deprecated according to the javadoc. > Perhaps they changed to using an annotation? Or Javadoc is treating deprecation as if it inherits from the class to its constructor. More research needed... > method java.util.Collections.max(java.util.Collection): type > java.lang.Object in classpath, but type T in jdk15 > > The mention of 'T' here is odd. It is, especially since it looks like they took pains to ensure that the T in question erases to Object and not Comparable as it otherwise would (). Japi's supposed to consider replacing a nongeneric type with something that erases to that type as okay. Both of these are good catches; I'll look into them further. Stuart. -- http://sab39.dev.netreach.com/
Re: Japi diffs for classpath
Cool, this one had the intended effect first time. This change eliminated the "1.4 mode switch" (-4) to japicompat in favor of a modified algorithm which should work well for comparing APIs regardless of whether they use generics or not. This means that Japi is now able to spot that those compareTo(Object) methods are provided by bridge methods in jdk1.5 even though they're not part of the public API as such since the real methods are compareTo(T). That's the last known bug I'm aware of in the results (if you know of any left, please speak up!). I'm planning on making a new release next week to get all the new enhancements and generics support and things into a released version, and then start making a concerted effort to get annotations working. Thanks, Stuart. -- http://sab39.dev.netreach.com/
Re: Japi diffs for classpath-generics
So anyone subscribed to the testresults list may be thinking "huh?" right now...
As usual, fixing one bug I introduced another. I added code to make
Japi aware of covariance so that StringBuffer didn't get screwed up,
but my fix had a typo which caused the wrong method to be used in some
cases. I've fixed it, I think, but rather than spam everyone again,
I'll just let the next nightly run pick them up.
Note to self: In regexes, {1-2} is *not* a synonym for {1,2}
Stuart.
On 3/10/06, Stuart Ballard <[EMAIL PROTECTED]> wrote:
> Japi diff jdk10 vs classpath-generics:
> Full results:
> http://www.kaffe.org/~stuart/japi/htmlout/h-jdk10-classpath-generics.html
>
> Changes since last run:
>
> -Comparison run at Fri Mar 10 11:20:54 2006 GMT
> -jdk10 API scanned at 2006/03/10 05:32:52 EST
> -classpath-generics API scanned at 2006/03/10 06:14:34 EST
> +Comparison run at Fri Mar 10 19:05:57 2006 GMT
> +jdk10 API scanned at 2006/03/10 01:07:52 EST
> +classpath-generics API scanned at 2006/03/10 01:55:36 EST
> -java.lang: 99.33% good
> +java.lang: 99.4% good
> -Total: 91.25% good
> +Total: 91.26% good
>
>
> Japi diff jdk11 vs classpath-generics:
> Full results:
> http://www.kaffe.org/~stuart/japi/htmlout/h-jdk11-classpath-generics.html
>
> Changes since last run:
>
> -Comparison run at Fri Mar 10 11:21:27 2006 GMT
> -jdk11 API scanned at 2006/03/10 05:32:19 EST
> -classpath-generics API scanned at 2006/03/10 06:14:34 EST
> +Comparison run at Fri Mar 10 19:06:33 2006 GMT
> +jdk11 API scanned at 2006/03/10 01:07:13 EST
> +classpath-generics API scanned at 2006/03/10 01:55:36 EST
> -java.lang: 99.82% good
> +java.lang: 99.88% good
>
>
> Japi diff jdk12 vs classpath-generics:
> Full results:
> http://www.kaffe.org/~stuart/japi/htmlout/h-jdk12-classpath-generics.html
>
> Changes since last run:
>
> -Comparison run at Fri Mar 10 11:23:46 2006 GMT
> -jdk12 API scanned at 2006/03/10 05:28:45 EST
> -classpath-generics API scanned at 2006/03/10 06:14:34 EST
> +Comparison run at Fri Mar 10 19:08:34 2006 GMT
> +jdk12 API scanned at 2006/03/10 01:00:51 EST
> +classpath-generics API scanned at 2006/03/10 01:55:36 EST
> -java.lang: 99.89% good
> +java.lang: 99.94% good
>
>
> Japi diff jdk13 vs classpath-generics:
> Full results:
> http://www.kaffe.org/~stuart/japi/htmlout/h-jdk13-classpath-generics.html
>
> Changes since last run:
>
> -Comparison run at Fri Mar 10 11:26:18 2006 GMT
> -jdk13 API scanned at 2006/03/10 05:24:22 EST
> -classpath-generics API scanned at 2006/03/10 06:14:34 EST
> +Comparison run at Fri Mar 10 19:10:58 2006 GMT
> +jdk13 API scanned at 2006/03/10 12:52:06 EST
> +classpath-generics API scanned at 2006/03/10 01:55:36 EST
> -java.lang: 99.89% good
> +java.lang: 99.94% good
>
>
> Japi diff jdk14 vs classpath-generics:
> Full results:
> http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath-generics.html
>
> Changes since last run:
>
> -Comparison run at Fri Mar 10 11:29:19 2006 GMT
> -jdk14 API scanned at 2006/03/10 05:17:50 EST
> -classpath-generics API scanned at 2006/03/10 06:14:34 EST
> +Comparison run at Fri Mar 10 19:15:10 2006 GMT
> +jdk14 API scanned at 2006/03/10 12:41:57 EST
> +classpath-generics API scanned at 2006/03/10 01:55:36 EST
> -java.lang: 99.91% good
> +java.lang: 99.95% good
>
>
> Japi diff jdk15 vs classpath-generics:
> Full results:
> http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-classpath-generics.html
>
> Changes since last run:
>
> -Comparison run at Fri Mar 10 11:32:34 2006 GMT
> -jdk15 API scanned at 2006/03/10 05:10:11 EST
> -classpath-generics API scanned at 2006/03/10 06:14:34 EST
> +Comparison run at Fri Mar 10 19:19:11 2006 GMT
> +jdk15 API scanned at 2006/03/10 12:28:39 EST
> +classpath-generics API scanned at 2006/03/10 01:55:36 EST
> -java.lang: 99.21% good, 0.78% missing
> +java.lang: 99.02% good, 0.21% bad, 0.76% missing
> -java.io: 99.74% good, 0.05% bad, 0.2% missing
> -java.math: 96.68% good, 0.47% minor, 2.84% missing
> -java.net: 89.6% good, 0.06% minor, 10.33% missing
> -java.nio: 100% good
> +java.io: 98.55% good, 1.24% bad, 0.19% missing
> +java.math: 96.74% good, 0.46% minor, 2.79% missing
> +java.net: 89.5% good, 0.06% minor, 10.42% missing
> +java.nio: 99.49% good, 0.5% bad
> -java.security: 82.43% good, 17.56% missing
> +java.security: 82.33% good, 17.66% missing
> -java.util: 95.84% good, 0.04% minor, 0.12% bad, 3.99% missing
> +java.util: 95.66% good, 0.04% minor, 0.24% bad, 4.05% missing
> -javax.net.ssl: 78.34% good, 0.12% bad, 21.52% missing
> +javax.net.ssl: 77.95% good, 0.12% bad, 21.91% missing
> -javax.swing: 98.97% good, 0.25% minor, 0.01% bad, 0.75% missing
> +javax.swing: 9
Re: Building and Running MegaMek under Classpath + Cacao CVS HEAD
On 3/2/06, Thomas Fitzsimmons <[EMAIL PROTECTED]> wrote: > On Thu, 2006-03-02 at 00:06 -0500, James Damour wrote: > > > I also looked into the compatability between MegaMek clients and servers > > running on proprietary and free VMs. There was an initial hiccup where > > I was getting incompatable serialVersionUID, but I quickly realized that > > the problem was caused by my compiling MegaMek twice, once with Sun > > tools, and once with Free tools. When I gave both VMs the same set of > > classes (or JAR file), they could connect without difficulty. > > Isn't this the point of serialVersionUID though? If someone builds and > runs MegaMek with Sun's tools and another person builds and runs MegaMek > with free tools, the two MegaMek instances should be able to serialize > and unserialize each other's data. Where this isn't the case don't we > need to update our serialVersionUID fields? I read that as svuids of MegaMek-specific classes... in fact I think it *must* have meant MegaMek-specific classes, because you *can't* build Classpath itself with Sun's tools. So the issue reduces to the known one of "the svuid algorithm is only well-specified for a given *compiled* class, not for a given java source file" (which is why some compilers warn about Serializable classes without explicit svuids). The right solution is to add svuids to the classes within MegaMek. Stuart. -- http://sab39.dev.netreach.com/
Re: GJDoc
(oops, sorry, hit "reply" instead of "reply to all", trying again) On 3/1/06, Julian Scheid <[EMAIL PROTECTED]> wrote: > What I'd really like to do is completely replace the parser with a new > one written from scratch (preferrably, a generated one.) In addition, > the parsing and type resolution steps should be cleanly separated - they > are somewhat intermingled at the time. What are the odds of replacing it by calls into ecj's parsing engine, since that's already pretty mature and implemented in pure Java? The licensing problems that may exist at this time seem to be resolvable, as evidenced by the plan to use ecj as gcc's Java frontend in the future... Stuart. -- http://sab39.dev.netreach.com/ -- http://sab39.dev.netreach.com/
Re: Question about the Generics branch.
On 3/1/06, theUser BL <[EMAIL PROTECTED]> wrote: > At > http://builder.classpath.org/dist/ > are two versions: > - GNU Classpath with generics > and > - GNU Classpath without generics First of all, that url isn't the place for getting a supported version of Classpath ;) That just produces nightly builds for testing purposes. Released versions are linked from the project homepage, or you can check out of CVS. > At first I thoughted, that the generics-branch have more files and would be > bigger then the normal version. > > But thats not true. classpath-latest.tar.gz is bigger then > classpath-generics-latest.tar.gz and glibj-latest.zip is bigger then > glibj-generics-latest.zip Basically it works like this: Most work is done on the trunk (the non-generics branch). Work that requires the new compiler features in 1.5 is done directly on the generics branch. Every so often (usually right before a release is to be made) Andrew takes the work done on the trunk and merges it over over to the generics branch. Since a LOT of work has been done since the last release and the merge for the next release hasn't happened yet, the trunk is quite a bit bigger. Once the merge happens, the generics branch will shoot up in size and become slightly bigger than trunk for a little while. > And looking inside the current Changelog of the both *.tar.gz files shows, > that there existing some changes, which are in classpath-latest.tar.gz, but > not in classpath-generics-latest.tar.gz and the other way around. > > So, it shows me, that classpath-latest.tar.gz is NOT a subset of > classpath-generics-latest.tar.gz When a release is made, the trunk tarball is pretty much a strict subset of the generics tarball. That's not the case for the nightly snapshots. > What me more wonder is, that in the cvs at > http://cvs.savannah.gnu.org/viewcvs/?cvsroot=classpath there is no clue > about the two branches. It seems, that there existing only the one there. http://cvs.savannah.gnu.org/viewcvs/classpath/?root=classpath shows the generics branch in the "Select Branch" dropdown at the bottom. > And I don't know, why classpath-latest.tar.gz AND > classpath-generics-latest.tar.gz exists. > Why isn't it possible to have only one package. And that there existing > configure options like > ./configure --with-generics > and > ./configure --without-generis Others have already answered this question but I'd also point out that the snapshots on builder have *already* been built, so even if this were possible, the snapshots on builder would have to have been built with one option or the other, so you'd still need separate tarballs. Stuart. -- http://sab39.dev.netreach.com/
ecj and -warn:unused
I figured out the reason why at least one of the compilers on my system was failing to build classpath. The version of ecj I have (from Ubuntu Breezy) doesn't appear to understand the "unused" parameter to the "-warn" flag, which lib/Makefile passes to it. My autotools knowledge is nonexistent so I just modified Makefile directly to get the build to work (I do get an awful lot of "unused" warnings but the build is proceeding). It would be nice if configure could somehow detect whether ecj accepts that option and skip it if not, though. FWIW, here's some output of various ecj version-related commands: [EMAIL PROTECTED]:~$ ecj -version Eclipse Java Compiler 0.536, pre-3.1.0 milestone-5, Copyright IBM Corp 2000, 2005. All rights reserved. [EMAIL PROTECTED]:~$ dpkg -l | grep ecj ii ecj-bootstrap 3.0.1-4ubuntu6 bootstrap version of the Eclipse Java compil ii eclipse-ecj 3.1.1-1ubuntu3 Eclipse Java compiler and Ant plug-in Thanks, Stuart. -- http://sab39.dev.netreach.com/
Re: ecj and -warn:unused
On 2/28/06, Stuart Ballard <[EMAIL PROTECTED]> wrote: > (I do get an awful lot of "unused" > warnings but the build is proceeding) ... and it died with an internal compiler error, so perhaps it's not worth detecting the "unused" warning issue after all. Should this version be able to compile Classpath? How about jikes 1.22 or gcj 4.02? Stuart. -- http://sab39.dev.netreach.com/
Re: Next release
On 2/27/06, Brian Jones <[EMAIL PROTECTED]> wrote: > Suggest making next release 0.90 and incrementing towards 1.0. The 1.0 > release should be 1.4.0 (or 1.40 if you were going to be consistent, but > I digress). Anyway my $0.02. 0.90 has problems if there turn out to be more than 9 more releases before 1.(4.)0 is reached. Hard to say whether that's likely or not, but I think it would be better if our decision of when to hit 1.x was based purely on technical grounds and not affected by limits on the version-number space. On the other hand, well spotted (I think?) that 0.9.x might be considered a lower version that 0.21 by packaging tools. dpkg --compare-versions appears to think so, if I'm understanding how to use it right. This may be moot though as the debian classpath package already has an epoch on it; I don't know how rpm handles this kind of issue. Stuart. -- http://sab39.dev.netreach.com/
Re: Next release
On 2/27/06, Mark Wielaard <[EMAIL PROTECTED]> wrote: > Everybody seems to agree 0.x really doesn't do justice to the maturity > we have reached over the years. And it is really hard to define when > we hit "1.0". So the proposal is to keep using a "sequence version > number". Either just drop the "0." and make the next release-number > classpath-21, or adopt a year.month style version number and make the > next version number classpath-6.3 for the March 2006 release. > In either case we will just use a code name for a release that has > some special feature set that we are proud of, but we will always > just increase the release snapshot number. Suggestions or Opinions? I agree with the difficulty of picking a point to hit 1.0, but I'm a little worried about running into the opposite problem of overselling the level of maturity. A version 21 product sounds like it should be... well, emacs. A version 6.x also seems like it should be an extremely mature product, and 6 also happens to be the next pending version of Sun's JSE which might confuse people. If we're going to go with one of these approaches, my preference would be for the year-based one but I'd suggest making it more obvious that it's year-based. Either version 2006.3 or, if that's too much, version 06.3 - "06" looks more like a year than just "6" does. My own personal feeling, though, is that even though it's hard to pick a point to go to 1.x, it's not *impossible*. I'd suggest that the right point to go 1.x is when people can be reasonably confident that a randomly-chosen app that runs on Java 1.4 will run on Classpath (I also think it might be worth calling that version 1.4.0 rather than 1.0). This means basically getting to full 1.4 API coverage with no stubs, and a fair degree of real-world testing, all of which seem eminently likely to happen, at the current rate of improvement, within months rather than years. The numbering game is all about psychology really anyway; version 0.21 suggests "21% of the way to maturity". If we stuck a 9 in there and made the next version either 0.9.21 or 0.9.1, it'd give a much more accurate representation of the real level of maturity without needing to go to a more unconventional system. Just my opinion, for whatever it's worth. Stuart. -- http://sab39.dev.netreach.com/
Re: Builder and snapshots
FYI, starting last night I've been using this glibj.zip for the "classpath" nightly japi comparisons. I'm also tweaking the japize line I use to make sure that packages that aren't documented as being part of the JDK aren't included, so that we don't show any entire packages as "missing in jdk15" in the reverse comparison. Since generics is still failing to build on builder I'm still using Andrew's japi files for that. Once a glibj-generics-latest.zip shows up ion builder/dist/ I'll start using that too :) Stuart. On 2/22/06, Stuart Ballard <[EMAIL PROTECTED]> wrote: > Thanks! I'll have a go tomorrow at tweaking my scripts to use those :) > > Stuart. > > On 2/22/06, Mark Wielaard <[EMAIL PROTECTED]> wrote: > > Hi Stuart, > > > > On Wed, 2006-02-22 at 11:26 -0500, Stuart Ballard wrote: > > > I see at http://builder.classpath.org/dist/ that there's a snapshot > > > available, but fetching it is hard to script because the filename will > > > change with each release. If there were a "classpath-latest.tar.gz" > > > symlink it would be helpful. > > > > > > There also doesn't seem to be a snapshot for the generics branch? > > > > There you go: http://builder.classpath.org/dist/ > > Seems this is also handy for people wanting to bootstrap things. > > Except that there is currently a problem using the gcj compiled ecj on > > builder to generate a glibj-generic-latest.zip. Currently busy packing > > for Fosdem, so I haven't looked into why yet. See the testresults lists > > for failure messages: > > http://lists.gnu.org/archive/html/classpath-testresults/2006-02/index.html > > > > Cheers, > > > > Mark > > > > > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.4.2 (GNU/Linux) > > > > iD8DBQBD/NiFxVhZCJWr9QwRAhDTAJ9IwGkf4fU5y2Measjqjxx4CuMbIACfbwKx > > o86x9Y5SghGt1O/7jVJ4dlc= > > =2Rt9 > > -END PGP SIGNATURE- > > > > > > > > > -- > http://sab39.dev.netreach.com/ > -- http://sab39.dev.netreach.com/
Re: Builder and snapshots
Thanks! I'll have a go tomorrow at tweaking my scripts to use those :) Stuart. On 2/22/06, Mark Wielaard <[EMAIL PROTECTED]> wrote: > Hi Stuart, > > On Wed, 2006-02-22 at 11:26 -0500, Stuart Ballard wrote: > > I see at http://builder.classpath.org/dist/ that there's a snapshot > > available, but fetching it is hard to script because the filename will > > change with each release. If there were a "classpath-latest.tar.gz" > > symlink it would be helpful. > > > > There also doesn't seem to be a snapshot for the generics branch? > > There you go: http://builder.classpath.org/dist/ > Seems this is also handy for people wanting to bootstrap things. > Except that there is currently a problem using the gcj compiled ecj on > builder to generate a glibj-generic-latest.zip. Currently busy packing > for Fosdem, so I haven't looked into why yet. See the testresults lists > for failure messages: > http://lists.gnu.org/archive/html/classpath-testresults/2006-02/index.html > > Cheers, > > Mark > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.2 (GNU/Linux) > > iD8DBQBD/NiFxVhZCJWr9QwRAhDTAJ9IwGkf4fU5y2Measjqjxx4CuMbIACfbwKx > o86x9Y5SghGt1O/7jVJ4dlc= > =2Rt9 > -END PGP SIGNATURE- > > > -- http://sab39.dev.netreach.com/
Builder and snapshots
Would it be possible to configure builder to drop the built snapshots into a predictable location, for the trunk and branch? I realized while setting Japi up for Harmony that the bit my machine struggles with is the build process; if I can download a tarball that contains glibj.zip then there's no need for japize to be run by builder (unless it wants to of course :) ) I see at http://builder.classpath.org/dist/ that there's a snapshot available, but fetching it is hard to script because the filename will change with each release. If there were a "classpath-latest.tar.gz" symlink it would be helpful. There also doesn't seem to be a snapshot for the generics branch? On a semi-related note, are you guys interested in the script I use for the nightly Japi runs, for use on builder? That way you could get a full set of comparisons instead of just vs 1.4, and if you wanted to, send diff emails every time a build completes (if there are changes) rather than only nightly. Thanks, Stuart. -- http://sab39.dev.netreach.com/
Re: Mauve license
(this is going to show up in the wrong place in the thread - for some reason I can see mails showing up in the archives but I'm not receiving them myself till much later, so I don't have this one myself to respond to yet) Andrew Haley wrote: > > but costing us contributors. > > This part is the mystery. If, as you say, there's no practical reason > why anyone would *want* to take Mauve proprietary, why does it matter > that Mauve is GPL? There are quite a few reasons, some logical, some not, why people won't contribute to GPL projects. Some corporations have policies prohibiting employees from looking at GPL code. I don't believe there's any *good* reason for an organization to have such a policy, but some do. It appears there's at least one contributor on the Harmony list who is unable to look at Classpath code for this reason. Some corporations may have weaker policies that would still prohibit employees from actually writing GPL code on company time. Some people see the GPL as an endorsement of a political position they don't agree with and won't work on software licensed under it for that reason. Some people philosophically oppose the idea of copyleft and don't want their work under such a license. The Apache organization has policies against distributing GPL code and I believe also against requiring it as a dependency. (Even if everyone at Apache could be persuaded that changing this was a good idea, their procedures for doing so seem to take a while). A test suite isn't strictly a dependency but I think they'd at least have strong reservations against making it official policy that if you're writing tests for Harmony that test public APIs they should go in this GPL project. Another reason I feel test suites shouldn't be copyleft is similar to RMS's reasoning about Ogg: the greatest benefit to Free Software is obtained by having all implementations be compatible and compatible with the existing proprietary solution to help people escape the trap. The best way to achieve that is by getting good tests as widely disseminated and used as possible (analagous to getting Ogg support as widely used as possible to help people escape the mp3 trap). (another email I'm seeing in the archives but haven't received myself - Andrius's point about the OMG tests. I believe it should be possible to convert the license back to LGPL if we have permission from the copyright holders of all the code that was changed since, which would then mean that as long as the OMG tests are self-contained, they could be linked happily with a non-copyleft Mauve even if they themselves are still copyleft). Stuart. -- http://sab39.dev.netreach.com/
Re: Mauve license
On 2/16/06, Archie Cobbs <[EMAIL PROTECTED]> wrote: > This can make sense if the Harmony tests are Harmony-specific. Some are, some aren't. They plan to have a separation between the two though. So Classpath will be able to use the non-specific part of Harmony's testsuite. > Otherwise I don't see what the point is. The point is that, for whatever reasons (rational or irrational), some people simply won't contribute to a GPL-licensed project. Some of those people are Harmony contributors. If those people want to contribute to a Java testsuite, which they do, it won't be Mauve as long as Mauve is GPL. > There may be no real reason it should be GPL, but in any case it is... > so.. what's the problem with that? I mean, from a practical standpoint. >From a practical standpoint it's deterring a fairly large body of potential contributors... > But you seem also to be asking the religious question "why GPL"? Not at all. I like the GPL. I think the GPL-with-exception license of Classpath is the perfect license for what Classpath does. I use the GPL on almost all my own code (although I prefer the LGPL for things that are designed to be used as libraries). Even RMS points out that using non-copyleft licenses can be beneficial when it's a net gain for Free Software as a whole (eg Ogg). And in this case I think there is such a gain, because the GPL is buying us nothing (since there's no practical reason why anyone would *want* to take Mauve proprietary) but costing us contributors. I seem to be in a minority though, so I'll drop the issue I guess. Stuart. -- http://sab39.dev.netreach.com/
Re: Mauve license
On 2/16/06, Archie Cobbs <[EMAIL PROTECTED]> wrote: > This Apache/Harmony thing vs. Claspath/GPL debate is just so tempting.. :-) Heh. > But let's talk practicalities.. here's a simple thing I don't understand. > > What exactly prevents Harmony from using Mauve as a test suite? Nothing, and in fact I think they plan to do just that. But as I understand it their current plan is to use Mauve *in addition to* (and secondary to) their own test suite and only develop their own tests in their own repository. So we end up with two test suites being developed by two disjoint groups, both of whom are free to (and likely to) *run* the other group's suite against their own implementation, but still no actual cooperation. > So then if Apache only wants to run Mauve tests, what impact does Mauve > being GPL have? Why can Apache folks just download Mauve and run it, > the same way Classpath hackers do? Mauve is its own self-contained project. They can, but the Classpath hackers don't just run it, they write it too. Basically, I just don't see why Mauve *should* be GPL. There's absolutely no benefit in claiming copyleft on it and a considerable benefit from not doing so. Other than the issue of finding copyright holders, why *shouldn't* it be X11 or modified-BSD licensed so that anyone can use it as they see fit? I'm a GPL supporter in general but using it on a testsuite seems really wrong to me. > As to the issue of converting Mauve to JUnit, that's surely a lot of work > any way you slice it, and in any case that seems like an orthogonal issue. Yes, at this moment I'm only concerned with political issues. Technical issues are so much easier that they can be deferred for now ;) Stuart. -- http://sab39.dev.netreach.com/
Re: Mauve license
On 2/16/06, David Gilbert <[EMAIL PROTECTED]> wrote: > Free to use, free to redistribute, and since you'll never want to > combine Mauve with anything else, I can't see why the GPL is considered > a showstopper. Politics don't have to make sense ;) The logical conclusion of your statements, though, is that the GPL isn't actually making any practical difference. And if that's the case, what's the point of using it? > I think a more significant "problem" is practical: Mauve, which > predates JUnit, uses its own test harness and Harmony is using JUnit. > Integrating the two is a pile of work that you're not going to find > anyone willing to spend time on. I think we should just accept that > there are going to be two separate test suites, that will overlap in > some places. It's not that big a deal in the scheme of things. AIUI currently you couldn't integrate the two if you wanted to because JUnit is under a non-GPL-compatible license. Another reason why a Mauve license change would be a benefit. >From a practical point of view, if the license issues disappeared, it would presumably be easy enough to create a "junit" directory in mauve, have the mauve launcher scripts run both junit *and* the existing harness, pull the harmony tests into the new folder, everybody write new tests as junit tests, and gradually convert the old tests one-at-a-time over time. It wouldn't have to be a once-off "convert the world" operation. > We have those tests now, just in separate places. True. The current situation isn't a disaster. It would just be nice to get some cooperation in a place where, IMO, it clearly *does* make sense and the showstoppers seem to be entirely unnecessary. Stuart. -- http://sab39.dev.netreach.com/
Mauve license
(including the Classpath list as well as Mauve list here as I don't know how many people actually read the mauve list) Recently on the Harmony list there's been some discussion of how tests should be written and where they should be put. I chimed in pointing out what I thought would be a no-brainer - tests for public APIs should be in Mauve of course. I only just made that post and I haven't seen the responses yet, but it occurred to me to look and see what Mauve's license is just to make sure that wouldn't be a showstopper, and, well, as I'm sure many of you know, it's GPL. This is slightly strange to me. We (the Free Software community) are forced to make our own test suite because Sun won't release theirs under terms we can use, but when we do write our own, we put it under a license that prevents even other Free Software projects from working with it. Our test suite is under a stronger copyleft than Classpath itself is! I understand why we want Classpath itself to be copyleft. But what on earth benefit are we getting from preventing people from "proprietarizing" our testsuite? My understanding is that a license change could be difficult to effect at this point because I don't think a copyright assignment has been required for Mauve contributions and therefore there are probably a lot of copyright holders, some of whom may be difficult to track down. But if it *could* be managed (and if the Harmony hackers could be persuaded to put their tests there), I think it would be a major win for everybody. Mauve gets a bunch of new contributors (Harmony certainly seems to have a fair bit of momentum at this point) and code (I believe some of Harmony's big contributions came with test suites that could be integrated). Classpath and Harmony both get a bunch of new tests. Harmony hackers get to see that Classpath hackers aren't inflexible GPL-zealots, and both groups of hackers get used to working together on a project that benefits both. I don't think it's a coincidence that all the projects that originally collaborated on Mauve ended up combining their class libraries, either. Once people get used to working together, the level of collaboration can only go up from there... Stuart. PS I didn't include the Harmony list on this post mainly because my understanding is it's of absolutely no interest to them unless there *is* some way for Mauve to make this change. "GPL software is a nonstarter for us" is a quote I saw on the Harmony mailing list a couple of days ago... -- http://sab39.dev.netreach.com/
Re: Japi diffs for classpath
On 2/15/06, Stuart Ballard <[EMAIL PROTECTED]> wrote: > 2) The problem that I was actually trying to target with this change > doesn't seem to be solved yet: > http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-jdk15.html#err_missing_java_lang > Still shows a whole bunch of methods missing from 1.5 that should be > present. Why that's happening requires further investigation. Figured it out - it's a japi bug that's rather hard to fix. Seems that in JDK1.5 there's a package-private class AbstractStringBuilder> and StringBuffer is a subclass of AbstractStringBuilder. The methods in question are defined in AbstractStringBuilder as returning T. So they're present in StringBuffer two ways: as bridge methods, returning AbstractStringBuilder, and as real methods returning StringBuffer. Unfortunately japi is having some trouble with the fact that these methods differ only in their return type, and ends up only seeing the bridge method. And since that returns a nonpublic type, it skips it. The code in Japize that needs to be changed to fix this is complicated and the change needed isn't trivial. However, it's a different bug than the one that was just fixed, so the current results are correct as far as they go. Stuart. -- http://sab39.dev.netreach.com/
Re: Japi diffs for classpath
On 2/15/06, Stuart Ballard <[EMAIL PROTECTED]> wrote: ... > +Total: 98.7% good, 1.06% missing > +Fields: 160 missing. Well, that's an interesting result I suppose. Still having problems in this department; sorry for the spam. While that change certainly made a difference there are still at least two problems: 1) The classpath japis were created with a japitools version that didn't have this change. D'oh. The changes are checked into japitools CVS so they should be picked up by tonight's run. Until then the results should be treated as suspect; sorry. Didn't think of that until too late. 2) The problem that I was actually trying to target with this change doesn't seem to be solved yet: http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-jdk15.html#err_missing_java_lang Still shows a whole bunch of methods missing from 1.5 that should be present. Why that's happening requires further investigation. Stuart. -- http://sab39.dev.netreach.com/
Re: Another minor japi change
False alarm (temporarily), this change doesn't seem to have actually
worked. I'll look into it later when I have more time.
Stuart.
On 2/15/06, Stuart Ballard <[EMAIL PROTECTED]> wrote:
> I just found and partially fixed a longstanding bug in japi - it was
> ignoring members declared in non-public superclasses. Apparently these
> members *are* accessible. I noticed this because the comparison
> between jdk14 and jdk15 was reporting a bunch of methods in
> StringBuffer as missing, because in jdk15 these were moved to a
> non-public superclass shared between StringBuffer and StringBuilder.
>
> I'm rerunning now with this bug fixed; if it causes any changes to the
> results for Classpath, there'll be a diff email shortly.
>
> There is one remaining problem that isn't quite so trivial to fix: a
> field that's declared in a non-public superclass should be treated as
> if it were declared in the first public subclass of that class (in the
> cases where the declaring class matters). Theoretically, this could
> produce erroneous results. If the new runs introduce any errors
> claiming that fields ought to be declared in non-public classes,
> please ignore those errors until I can fix the japi bug, at which
> point they'll either go away or give a correct location where the
> fields should be declared.
>
> There's actually a really really obscure corner case where the fact
> that it's declared in a non-public superclass might actually matter:
>
> class Super {
> public static int value;
> }
> public class Sub1 extends Super {
> }
> public class Sub2 extends Super {
> }
>
> public void test() {
> Sub1.value = 1;
> System.out.println(Sub2.value);
> }
>
> However, since Super isn't part of the public API at all, I can't
> think of any way for Japi to represent the fact that Sub1.value and
> Sub2.value are actually the same field without ever mentioning (or
> knowing about) the nonpublic class. Especially since it's only
> actually an issue if more than one public subclass exists. Any
> suggestions?
>
> Stuart.
> --
> http://sab39.dev.netreach.com/
>
--
http://sab39.dev.netreach.com/
Another minor japi change
I just found and partially fixed a longstanding bug in japi - it was
ignoring members declared in non-public superclasses. Apparently these
members *are* accessible. I noticed this because the comparison
between jdk14 and jdk15 was reporting a bunch of methods in
StringBuffer as missing, because in jdk15 these were moved to a
non-public superclass shared between StringBuffer and StringBuilder.
I'm rerunning now with this bug fixed; if it causes any changes to the
results for Classpath, there'll be a diff email shortly.
There is one remaining problem that isn't quite so trivial to fix: a
field that's declared in a non-public superclass should be treated as
if it were declared in the first public subclass of that class (in the
cases where the declaring class matters). Theoretically, this could
produce erroneous results. If the new runs introduce any errors
claiming that fields ought to be declared in non-public classes,
please ignore those errors until I can fix the japi bug, at which
point they'll either go away or give a correct location where the
fields should be declared.
There's actually a really really obscure corner case where the fact
that it's declared in a non-public superclass might actually matter:
class Super {
public static int value;
}
public class Sub1 extends Super {
}
public class Sub2 extends Super {
}
public void test() {
Sub1.value = 1;
System.out.println(Sub2.value);
}
However, since Super isn't part of the public API at all, I can't
think of any way for Japi to represent the fact that Sub1.value and
Sub2.value are actually the same field without ever mentioning (or
knowing about) the nonpublic class. Especially since it's only
actually an issue if more than one public subclass exists. Any
suggestions?
Stuart.
--
http://sab39.dev.netreach.com/
Re: Ldap support in classpath
It can't and it shouldn't, it's a deliberate design decision of japi.
There's absolutely no possible conceivable way for japi to know that a
particular method *needs* to be overridden, because overriding a
method or not is purely an implementation decision.
For example, at first glance it's "obvious" that String needs to
override the equals method of Object. However, it could be that for
some bizarre optimization reason a particular implementation of the
Java API might want to do something like this:
public class Object {
...
public boolean equals(Object o) {
if (this instanceof String) {
// something special
} else {
return o == this;
}
}
}
in which case String wouldn't need an override at all. This is a silly
example because nobody would ever do it that way, but there are a lot
of methods in the API which might or might not need to be overridden.
Sometimes the behavior is identical so overriding isn't strictly
necessary but the subclass can provide a faster implementation.
Sometimes instead of an override the implementation might merely defer
some *parts* of the body of that method to internal virtual methods.
Japi's business is to check the API and not make any assumptions about
the implementation. Otherwise we get into tricky legal territory as to
whether we're actually creating a clean-room implementation or a
derived work of Sun's copyrighted one.
In this case, obviously we do need to override to get the behavior
right, but japi isn't about testing behavior. Instead, we should add a
Mauve test that confirms that LdapInitialContext actually does what
it's supposed to do.
Stuart.
PS In case you can't tell, I write variations this email often ;)
On 2/15/06, Erwin Rol <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-02-15 at 09:36 +0100, Robert Schuster wrote:
> > Hi.
> >
> > Erwin Rol wrote:
> > > Hey all,
> > >
> > > I am trying to get Open Xchange working with gcj, and so far things are
> > > going OK. Now i ran into a problem with LDAP. OX uses
> > > InitialLdapContext(...) to create a initial context. Later it uses
> > > javax.naming.InitialContext.getNameInNamespace(...) and that always seem
> > > to throw a javax.naming.OperationNotSupportedException. After looking
> > > into the classpath source code it seems most methodes in .naming.* just
> > > throw a not supported error.
> > Ouch. You found what we call a silent stub. A method that will not show up
> > in
> > the JAPI scores.
> >
>
> It seems the getNameInNamespace() correctly throws and
> OperationNotSupportedException because the javax.nameing.InitialContext
> does not know how about things to preform the action. The
> LdapInitialContext is the one that knows this, but LdapInitialContext
> does not have a getNameInNamespace() method, so the one of the base
> class is used.
>
> How could it be made that those methods that LdapInitialContext should
> overload show up as "missing" in the JAPI scores ?
>
> - Erwin
>
>
>
>
--
http://sab39.dev.netreach.com/
JDK japis regenerated
I just got around to doing something I've wanted to do for a while - regenerate the JDK japi files against fresh downloads of the latest JDK point releases directly from Sun. I got the latest 1.2-1.5 for Linux and 1.1 for Windows (since no official Sun Linux release of 1.1 was ever made). It appears to be impossible to get 1.0 from Sun for love or money, so I just kept the file I have of that one (honestly, I have no idea where I got it, but we've been at zero errors against it forever, so it's not that important). I suspected (correctly, as it turns out) that there might have been subtle differences due to the fact that I'd just been using JDKs that I'd had installed on various machines at various points, some of which were from Blackdown, for example. Seems to be primarily serialVerisonUID differences plus one that I'll address in a separate mail. There'll be a "japi diffs" email shortly (when the script finishes digesting the new info) going to the testresults list with the outcomes. This is just a heads up as to where those differences are coming from. The email probably won't reflect the latest Classpath checkins (I believe the classpath japis are only created nightly) so those will be picked up by tonight's normal run. Stuart. -- http://sab39.dev.netreach.com/
Re: Japi reverse comparisons (eg finalness and SimpleDoc)
On 1/26/06, Mark Wielaard <[EMAIL PROTECTED]> wrote: > Which doesn't compile with either gcj, jikes or ecj because they think > the b = a in GrandChild refers to Child.a which is private. This is > surprising and non-intuitive. I would expect a warning that there is a > private field a in Child. But not an error because there is an > accessible field a (in Parent). It is just an implementation detail that > there is a similarly named private field in Child. > > Is this actually specified in the JLS? Yep. http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.3 "If the class declares a field with a certain name, then the declaration of that field is said to hide any and all accessible declarations of fields with the same name in superclasses, and superinterfaces of the class." Note that it doesn't say "if the class declares an *accessible* field..." Stuart. -- http://sab39.dev.netreach.com/
Re: Japi reverse comparisons (eg finalness and SimpleDoc)
On 1/26/06, Roman Kennke <[EMAIL PROTECTED]> wrote: > Hmm, when it compiles fine against JDK1.5 and fails with Classpath, it > seems to me that this field should show up in the forward JAPI instead? This is a good point. The problem is that as a point of principle I try *very* hard to avoid putting any information into japi files that could be considered an implementation detail. I think this is very important because it's the main basis on which I can state with confidence that the JDK japi files are freely distributable, as opposed to being "derived works" of the JDKs that they represent. As long as they contain only functional information necessary for interoperability, that information is un-copyrightable and hence so is the japi file. If we put in any implementation details, that opens us up to the claim that the japi file contains copyrighted information and we're not allowed to distribute it. In *almost* every case, the existence of a private field is an implementation detail, so japi provides no way to represent them. I suppose we could add a specific representation to say that a private (or package-private) field shadows a public inherited field, and store absolutely no information about the private field except for its name. That would make it possible to detect this situation in the forward japi file. Otherwise, this situation is indistinguishable from an extra field being added in classpath, which is totally legal in the forward comparison. > OTOH, if the Sun javac produces broken code, and the ECJ probably > doesn't compile correctly (should refer to node.accessibleParent, no?), > then this is maybe not super important anyway. Right :) The extra complexity in the japi file to detect and represent private shadowing fields is probably not worth the effort, especially if we are going to try to get the reverse comparison down to zero errors too :) Stuart. -- http://sab39.dev.netreach.com/
Re: Japi reverse comparisons (eg finalness and SimpleDoc)
All the results are generated daily (except that there's a build failure on Andrew's machine right now that's preventing them from being updated); we're planning to move the generation to builder as soon as builder is capable of building the generics branch. Stuart. On 1/26/06, Wolfgang Baer <[EMAIL PROTECTED]> wrote: > Hi all, > > Stuart Ballard wrote: > > The specific question was about whether japi ought to have reported > > that javax.print.SimpleDoc wasn't final when it should have been. > > > > The answer is, it *does* report that, but not in the place you might expect. > > Thanks for your explanations. I think I have now a better understanding > about whats going on with Japi. > > [...] > > > > But for perfect compatibility, we should be aiming to get the > > classpath-jdk15 report down to zero errors too. Most of these errors > > are much easier to fix than the corresponding error in the other > > direction would be, too :) > > I would vote to generate these "reverse" reports and add them to > builder.classpath.org. Would this be possible ? > > Wolfgang > > -- http://sab39.dev.netreach.com/
Re: Japi reverse comparisons (eg finalness and SimpleDoc)
On 1/26/06, Roman Kennke <[EMAIL PROTECTED]> wrote:
> A little update on that one: the field accessibleParent is obviously a
> field that is inherited from AccessibleContext. Is it possible that in
> Sun's API this field is shadowed by a private field in
> AccessibleJTreeNode?
That's the usual reason why a public or protected inherited field
might not show up in the subclass, yes...
Easy to verify in a black box way by writing a test class like this
and trying to compile it against the JDK, and watching what error
message you get:
public class AccessibleParentFieldTest extends
javax.swing.JTree.AccessibleJTree.AccessibleJTreeNode {
public static void main(String[] args) {
System.out.println(super.accessibleParent);
}
}
If the "shadowed by a private field" theory is right, this should be a
compile error saying that super.accessibleParent isn't accessible.
Stuart.
--
http://sab39.dev.netreach.com/
Japi reverse comparisons (eg finalness and SimpleDoc)
Looking over the new patches archive (thanks Mark!) I saw a thread between Wolfgang and Tom which betrayed a general incomplete understanding about Japi that I thought I'd address here since it's something of a Japi FAQ. The specific question was about whether japi ought to have reported that javax.print.SimpleDoc wasn't final when it should have been. The answer is, it *does* report that, but not in the place you might expect. The normal japi results pages, h-jdk1x-classpath.html, consist only of problems that cause programs written against that jdk version to fail against classpath. That is to say, things that break binary *backward* compatibility with that jdk version. A detailed list is at http://www.kaffe.org/~stuart/japi/jcompat.txt (This list hasn't been updated with what's considered legal or illegal for the new 1.5 language features but it's a useful starting point at least, and you can probably use it as a basis for an educated guess as to what decision japi would make on any 1.5 features too) Note in particular that for classes, "final->nonfinal" is considered legal. Short of using reflection to inspect the class and *deliberately* failing, there's no code that could be written against a final class that would fail if that class became nonfinal. So the error doesn't show up in this report. But there's also another report: http://www.kaffe.org/~stuart/japi/htmlout/h-classpath-jdk15.html This report shows things that break compatibility in the *opposite* direction, and if you look at http://www.kaffe.org/~stuart/japi/htmlout/h-classpath-jdk15.html#err_bad_javax_print you'll see that SimpleDoc being inappropriately nonfinal *does* show up there (along with all its methods, since the methods of a final class are final by implication). This report indicates cases where code written against Classpath might break against the JDK. I think it's entirely appropriate that the majority of our effort goes into fixing japi problems in the jdk1x-classpath reports, because they're the ones that actually might break compatibility for applications that are out there (let's face it, it's unlikely that any application today is written against Classpath and never tested against any JDK, and if there *are* any apps like that, they probably explicitly don't care about running on a JDK). But for perfect compatibility, we should be aiming to get the classpath-jdk15 report down to zero errors too. Most of these errors are much easier to fix than the corresponding error in the other direction would be, too :) Hope this clarifies things for future reference. Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://developer.classpath.org/mailman/listinfo/classpath
Patches list and Gmane
Just curious... Has there really been no traffic on the patches list in two days or did the recent mailing list changes break gmane? http://blog.gmane.org/gmane.comp.java.classpath.patches Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://developer.classpath.org/mailman/listinfo/classpath
Re: serialVersionUID problem
Serializable is an interface, anyway, not a class. Interfaces can never be serializable and so it makes absolutely no difference what serialver returns for them. I'd actually suggest it would be nice if serialver gave a warning or an error in that case! Yes, I know that Sun sometimes put serialVersionUID fields on interfaces. This is an example of Sun not understanding how their own API works and shouldn't be taken as meaning that those serialVersionUIDs are doing anything useful. If you look at the japi results you'll see that there are some classes, especially quite a lot in Swing, that have incorrect serialVersionUIDs, but the vast majority are correct. Japi doesn't compare serialVersionUIDs on interfaces because they're completely irrelevant. Stuart. On 1/19/06, Andrew Haley <[EMAIL PROTECTED]> wrote: > hultul writes: > > Hi, all~ > > > > I did some tests of java.io.Serializable's serialVersionUID using cp-tools. > > All the VM's used in tests were from Debian testing release. > > > > As a result, kaffe, jamvm, sablevm, and gij showed different results from > > Sun's java, where gij in GCC-3.4.3 not in Debian testing release showed > same > > one with Sun's. > > > > I guess that there is a problem in java.io.ObjectStreamClass.getClassUID() > > or its calling methods in GNU Classpath. > > > > What do you think about this? > > We use the correct algorithm, but serialVersionUIDs aren't guaranteed > to be the same between libraries, and cannot be. If you want the > serialVersionUID of a class of your own to be fixed, you must declare > the field explicitly. Some Java compilers (e.g. ecj) emit a warning > if you fail to do so. > > Andrew. > > > > ___ > Classpath mailing list > Classpath@gnu.org > http://lists.gnu.org/mailman/listinfo/classpath > -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: please test: XMLEncoder patch - version 2
In a 1.5 world you could define an annotation to put on classes that
have persistence delegates so that you only have to handle them when
an object of that type is encountered, and the central code doesn't
have to be aware of them at all.
I'm not directly familiar with the Java syntax for such things, only
the .NET equivalent, as I haven't done any Java 1.5 coding yet, but I
think it would look something like this:
@interface PersistenceDelegateClass {
Class delegateClass();
}
...
@PersistenceDelegateClass(delegateClass=JButtonDelegate.class)
class JButton extends ... {
...
}
Then you have some code in the XMLEncoder that looks for the
annotation on the class of each object it tries to persist and finds
the encoder that way.
Stuart.
On 1/9/06, Robert Schuster <[EMAIL PROTECTED]> wrote:
> Hi Roman,
> the PDs have to be registered to make out-of-the-box encoders (new
> XMLEncoder(...)) be able to process instances of those classes. However: If
> you
> want to split Swing out of the class library there is no point in trying to
> register a PD for them since the class isnt there anyway.
>
> I prepare a patch that will resolve this issue by using Class.forName() which
> is
> allowed to fail for such classes.
>
> Btw: Currently the encoder relies on the StAX implementation. If someone
> decides
> to rip that out one has to provide an alternative
> gnu.java.beans.encoder.Writer
> implementation.
>
> cya
> Robert
>
> Roman Kennke wrote:
> > Hi Robert,
> >
> > Is it really necessary to directly reference all those classes in
> > java.beans.Encoder.setupDefaultPersistenceDelegates()? Can you explain
> > what this method does and why the encoder won't work without these
> > persistent delegates? I am asking, because we had discussions about
> > breaking down the class library in the past, and pulling in e.g. Swing
> > by dependencies in java.beans looks ugly to me. Can the same effect be
> > achieved without directly refererring to those classes?
> >
> > Cheers,
> > /Roman
>
>
> ___
> Classpath mailing list
> Classpath@gnu.org
> http://lists.gnu.org/mailman/listinfo/classpath
>
>
>
>
--
http://sab39.dev.netreach.com/
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: Japi diffs for classpath
FYI, I introduced a bug while trying to combine all the results for each branch into a single email. The bug is now fixed but in this email all but the last set of diffs were ignored. There may have been (probably were) diffs in jdk1x vs classpath that never showed up in this email. Stuart. On 11/25/05, Stuart Ballard <[EMAIL PROTECTED]> wrote: > Japi diff classpath vs jdk15: > Full results: > http://www.kaffe.org/~stuart/japi/htmlout/h-classpath-jdk15.html > > Changes since last run: > > - Comparison run at Thu Nov 24 10:46:07 2005 GMT > - classpath API scanned at 2005/11/24 05:26:00 GMT > - jdk15 API scanned at 2005/11/24 05:07:14 EST > + Comparison run at Fri Nov 25 10:45:43 2005 GMT > + classpath API scanned at 2005/11/25 05:28:33 GMT > + jdk15 API scanned at 2005/11/25 05:07:11 EST > - javax.print.attribute.standard: 97.05% good, 2.81% bad, 0.13% missing > + javax.print.attribute.standard: 96.99% good, 0.12% minor, 2.46% bad, 0.42% > missing > - javax.swing.plaf.metal: 99.4% good, 0.53% minor, 0.05% missing > + javax.swing.plaf.metal: 99.06% good, 0.53% minor, 0.39% missing > - javax.swing.text: 98.8% good, 0.1% minor, 0.96% bad, 0.12% missing > + javax.swing.text: 98.79% good, 0.12% minor, 0.96% bad, 0.12% missing > - Classes: 210 minor, 131 bad, 17 missing. > + Classes: 213 minor, 131 bad, 18 missing. > - Constructors: 3 minor, 17 bad, 31 missing. > + Constructors: 3 minor, 17 bad, 36 missing. > + Minor > + class javax.print.attribute.standard.MediaName: > SerialVersionUID=1263835760863279463 in classpath, but > SerialVersionUID=4653117714524155448 in jdk15 > + class javax.print.attribute.standard.MediaTray: > SerialVersionUID=8262417813828896561 in classpath, but > SerialVersionUID=-982503611095214703 in jdk15 > + constructor javax.print.attribute.standard.MediaSize.Engineering(): missing > in jdk15 > + constructor javax.print.attribute.standard.MediaSize.ISO(): missing in jdk15 > + constructor javax.print.attribute.standard.MediaSize.JIS(): missing in jdk15 > + constructor javax.print.attribute.standard.MediaSize.NA(): missing in jdk15 > + constructor javax.print.attribute.standard.MediaSize.Other(): missing in > jdk15 > + class javax.swing.plaf.metal.MetalSplitPaneDivider.DividerLayout: missing > in jdk15 > + class javax.swing.text.NumberFormatter: > SerialVersionUID=-8441521719536144373 in classpath, but > SerialVersionUID=7072183780912339615 in jdk15 > > > -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
japi diffs
I've set up my nightly japi runs to create diffs from the last night's run, with the thought that I'd send them to the new -testresults mailing list. Unfortunately I currently don't have a mailserver that's willing to relay from the box in question. (Gmail provides an smtp server but it requires SSL and user/password authentication, and I don't know how to tell /usr/bin/mail to speak those things). Anyone have any suggestions as to alternative ways I could get the contents of these diff files sent to the list? Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Infinite loop
Seems like we could remove VMClass.getClassLoader altogether then since it's public and static in VMStackWalker? On the other hand, should it be public in VMStackWalker? Is that ok from a security standpoint? Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Japi vs JEditorPaneAccessibleHypertextSupport
On 08 Nov 2005 19:23:14 -0700, Tom Tromey <[EMAIL PROTECTED]> wrote: > I love the description of this constructor in the online javadoc. Lol, classic. > The rule is, a default constructor inherits the access of its class. > I.E., 'protected' is correct here. Doesn't that mean that a class that inherits from JEditorPane can see the class but not the constructor? And isn't that a little weird? (Not disputing your JLS expertise, mind you :) ) > Perhaps you can do it by noticing if the class has a synthetic > 'this$0' field. This is the usual name for an 'outer this' > reference, meaning that the class is not static. Does every nonstatic inner class get its outer this prepended to every constructor? (It's easy enough to detect that the class isn't static, we already flag a japi error if the staticness is wrong) What about a doubly-nested inner class, does it get two or just the innermost? Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Japi vs JEditorPaneAccessibleHypertextSupport
The current japi results show that the only non-minor error in the top-level javax.swing package against 1.2 is that the constructor of JEditorPaneAccessibleHypertextSupport (which I'm going to call JEPAHS from now on because I can't be bothered to type all that) is protected in classpath but public in the JDK. I thought that would be a nice easy bit of green to add, but when I went to create a patch I realized the problem: there *is* no constructor of JEPAHS. Basically, JEPAHS is a protected non-static inner class of JEditorPane so the compiler translates the usual default no-argument constructor into a constructor that takes a JEditorPane argument[1]. However, it looks like javac makes that constructor public where gcj(?) is making it protected. What I'm wondering is whether this is a compiler bug or whether it's simply undefined behavior that japi should account for and ignore. My guess is that the compiler is wrong. It seems to me that a subclass of JEditorPane (that's not in the same package) wouldn't be able to access the constructor if it were protected, because protected would mean accessible to subclasses of JEPAHS, not of JEditorPane. Anyone have any ideas whether I'm right or wrong about this? If I'm right, I suspect we could work around the compiler bug by explicitly declaring a no-argument public constructor in the class, but it would probably be better to fix the compiler. On the other hand, that would mean a japi error we can't eliminate until the next gcc release... Thoughts? Stuart. [1] Which raises another japi question: Should Japi automatically remove these implicit arguments from nonstatic inner class constructors so that its output matches what you'd actually put in Java source? My gut feeling is yes, but I'm not sure exactly how to detect them... -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: A question about DOM Levels and JAPI
Got it. Would you believe this bug was introduced back in November 2004 and nobody noticed? :( It appears I also checked it in without the slightest comment about what I was doing. I cunningly decided that actually adding new abstract methods is okay on a class that has no public or protected constructors, because all subclasses must be provided within the package and therefore are likely to be updated with the new method at the same time as the original class is. I figured this would account for classes that are intended to be returned from factory methods and never implemented externally. What I forgot to account for was the fact that interfaces never have constructors... I'm checking in a fix now and I'll rerun today's (CVS) comparison... Stuart. On 11/7/05, Stuart Ballard <[EMAIL PROTECTED]> wrote: > According to japi these methods are present in 1.5 (well, I only > checked a couple) so that explains why they aren't showing up in the > classpath-vs-jdk14 error report. > > What it doesn't explain is why they aren't showing up in the > jdk14-vs-jdk15 error report. I don't have an explanation for that just > yet but I'll keep investigating... > > Stuart. > -- > http://sab39.dev.netreach.com/ > -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: A question about DOM Levels and JAPI
According to japi these methods are present in 1.5 (well, I only checked a couple) so that explains why they aren't showing up in the classpath-vs-jdk14 error report. What it doesn't explain is why they aren't showing up in the jdk14-vs-jdk15 error report. I don't have an explanation for that just yet but I'll keep investigating... Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: A question about DOM Levels and JAPI
On 11/6/05, Anthony Green <[EMAIL PROTECTED]> wrote: > >From what I can tell the 1.4 JDK includes DOM Level 2 support and GNU > Classpath implements DOM Level 3. DOM3 introduces many new abstract > methods on existing classes. Why does this not show up in the nightly > JAPI test results? Good question. I'll look into this; can you give some specific examples of the methods that should be being flagged? My first guess was that these were being skipped because JDK1.5 had DOM3 but I produced an HTMLized version of the ignored errors between 1.4 and 1.5 and it only shows three xml-related "abs.add" errors. http://www.kaffe.org/~stuart/japi/htmlout/cvs/h-jdk14-jdk15.html#err_abs_add_javax_xml_parsers Thanks for the report :) Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: ANN: GNU Classpath "95% and counting" 0.19 released
I read it as ">= 95% of several interesting things". 96% of the 1.4 API (http://www.kaffe.org/~stuart/japi/htmlout/cvs/h-jdk14-classpath.html), and 95% of the Jonas testsuite... I don't know if that's what Mark intended but it made sense to me. Incidentally the generics branch appears to be at almost 88.5% of 1.5 (http://www.kaffe.org/~stuart/japi/htmlout/cvs/h-jdk15-classpath-generics.html - last night's run didn't take for some reason, I'm redoing it now to see whether 88.5 was reached for the release). That's astounding because it was only two months ago that 90% of 1.4 was reached, and now we're closing on that same milestone for 1.5... Also I note that at the current rate of messages on the -patches list there will be more messages in the first three days of November than in the entirety of July 2004, the first month gmane has info for. Silly pointless statistics but still cool imho :) Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
0.19 generics branch release? was Re: 0.19 "release meeting"
On 10/24/05, Stuart Ballard <[EMAIL PROTECTED]> wrote: [...] > any discussion of the idea of making a 0.19 release of the > generics branch as well as HEAD? So I'll, um, take that as a no shall I? ;) Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: 0.19 "release meeting" - Wed Oct 19 21:00 UTC
On 10/18/05, Mark Wielaard <[EMAIL PROTECTED]> wrote: > We wanted to have a release the first week of November. So I thought it > would be a good idea to send a reminder that people should see what the > want to get in before that, and what they want to see tested so they > feel confident that 0.19 will be a great developer snapshot worthy of > incorporation into gcc and kaffe as soon as it is released early > November. I wasn't able to make it to the meeting but I was wondering if there has been any discussion of the idea of making a 0.19 release of the generics branch as well as HEAD? I get the impression that the generics branch is mature enough that this isn't unreasonable, and I know there's demand for it because Jeroen has said that he'd base future IKVM releases on the generics branch if Classpath starts making releases of it. Obviously the ideal situation would be for the 0.19 generics branch release to be synced up to exactly the same point on HEAD as the main 0.19 release, but I think a release might be valuable even if this weren't possible. Thoughts? Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: japi and public references to non-public types
On 07 Oct 2005 12:38:03 -0600, Tom Tromey <[EMAIL PROTECTED]> wrote: > Spell-check identifiers. There's at least one bug like this in java. > Just today I was looking at code with "primative" all over... How do you do that though in a way that catches "primative" but doesn't catch "Impl" or "Spi" or "Tls" (just found in a quick scan through jdk-vs-classpath japi errors)? Hardcode those as exceptions to the rule? Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: japi and public references to non-public types
On 10/5/05, Jeroen Frijters <[EMAIL PROTECTED]> wrote: > What about the NameImpl issue? Definitely "detectable and ignorable". Check out http://www.kaffe.org/~stuart/japi/htmlout/cvs/h-jdk13-classpath.html It's already being detected and ignored. The code needs a little refinement but the basic structure is there. A separate report of "broken things in the API" is an excellent idea (I'm trying to avoid volunteering to write "japilint", especially as I can't believe the Java world doesn't already have an FxCop equivalent, but I have a funny feeling I'm going to write it anyway ;) ). APIs that are fundamentally broken and unimplementable are outside the scope of japicompat, though, I think. If we do find a situation where we need to differ from the JDK but there's absolutely no way to distinguish that situation to make it ignorable in japicompat then annotations are probably the way to go, but I think it's a last resort... Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: japi and public references to non-public types
On 10/5/05, Jeroen Frijters <[EMAIL PROTECTED]> wrote: > Possibly. Maybe we can use annotations (in the -- hopefully near -- > future) to mark code that differs from Sun for a valid reason? Perhaps I have too little faith in my fellow developers, but this idea scares me ;) So far I haven't seen any situations where we need to differ from Sun that aren't detectable and ignorable by japi without needing annotations... Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: japi and public references to non-public types
(oops, forgot to CC the list first try - thanks for catching that, Jeroen) On 10/5/05, Jeroen Frijters <[EMAIL PROTECTED]> wrote: > Mark Wielaard wrote: > > This looks like something the compiler should warn against > > "public/protected field/return with package/private type" > > (inner classes could be private). I absolutely agree it should be a compiler warning (and as Jeroen's said before, it really should never have been permitted by the language in the first place). Is there a Java equivalent to C#'s FxCop tool? > > I think japi should also warn against it not hide it, except when > > explicitly told to. I'm wondering exactly how to do this. You'd want to warn when this happens in Classpath, I think, but not when it happens in the JDK (unless you're actually testing the JDK for compatibility with something). (Currently I believe Classpath only does it for GridBagLayout, but the zip I was testing against was old). Actually, I think an "API lint" like this is kind of outside the scope of Japitools, or rather, outside the scope of japicompat. Perhaps "japilint" should be a separate tool sharing a lot of code with Japize... any volunteers to write it? :) Obvious things to catch: - This one: accessibility of class / method / field greater than accessibility of its type or arguments or thrown exceptions or type parameter bounds - Blank final serialVersionUID fields - serialVersionUID fields in non-serializable classes - serialVersionUID that's not static final - serialVersionUID in an interface - RCS keywords in public constants :) Anything else? > I agree. We're never going to get a 100% score on Japi anyway [1], so > hiding this stuff doesn't do any good in my opinion. > [1] One example I can think of is the non-constant serialVersionUID > fields in some classes (that compute their serialVersionUID based on > some runtime setting or such) Why would we get japi failures here? As long as we do the same thing the JDK does, japi won't report any errors. This is already the way it works (although I'm thinking about making the error message more accurate; right now it will say "serialVersionUID=0" which isn't quite true). Honestly, I don't see any reason why we shouldn't get to zero japi errors; having a bunch of false positive results just makes it harder to find what the real errors are that need to be fixed, especially once we get to the point where the false positives outnumber the real errors. I honestly believe that's part of why it took so long to get to zero errors against 1.1 - until relatively recently the very few remaining real errors were dwarfed by the false positives caused by later JDK versions being incompatible with 1.1 themselves. The japi report against 1.1 was all but useless until the false positives were removed. If you guys still feel differently then feel free to try to persuade me :) Stuart. -- http://sab39.dev.netreach.com/ -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: japi and protected field declaring classes
On 10/5/05, Mark Wielaard <[EMAIL PROTECTED]> wrote: > Changing things just because japi doesn't give a full green bar is wrong > to start with anyway. Japi can contain bugs. This statement works two ways. Blindly changing Classpath because japi doesn't give a full green bar is certainly a bad idea and understanding the why is very important indeed. That's why I didn't, for example, submit a patch which added the package-private NameImpl class just so we could get compatibility with the useless "impl" field in the JDK, but opened up a debate about what japi should do instead. On the other hand I do think it should be possible to get full green for everything in Classpath; in places where that's not currently possible without doing stupid stuff, or requires matching Sun on something that truly is an implementation detail and not part of the public API, I consider that a japi bug, and I'm committed to fixing any such japi bugs that are found. Hence the reason for starting this thread, and several others in the past, about what the right behavior for japitools in particular situations is. By the way, I noticed another situation japitools shouldn't care about declaring location of fields: if the field is final, it can't be modified by any outside code. I've implemented this in my local copy and it will be picked up by tonight's run. But I'd still really like feedback about whether I've missed any cases where it is, or isn't, important. Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: japi and protected field declaring classes
On 10/5/05, Wolfgang Baer <[EMAIL PROTECTED]> wrote: > Hi Mark, hi Stuart, > > Mark Wielaard wrote: > > I do hope someone packages japitools for Debian so that it can be used > > easily by the packagers. > > Got the message :-) I can have a look. Wow, cool :) > However which version should be packaged. The last available from > the website (0.9.5), or is there somewhere a newer one ? The only newer is CVS currently. I'd like to finish up the remaining issues in 1.5 compatibility (basically full annotation support) and hash out what's the right thing to do with the open issues that are being debated right now before I make another new version. At the current rate of progress that probably won't take long. But it's probably true that the CVS version gives much better results than the released version right now. I'm not sure what to propose, except be aware of the tradeoffs and make whichever decision you think is right for Debian... (btw, if there are changes that you'd like to see in japitools to make it easier to package let me know; I'm more than willing to give CVS access too) Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: japi and public references to non-public types
(hope you don't mind me ccing the list) On 10/4/05, David Holmes <[EMAIL PROTECTED]> wrote: > If a public or protected member utilises a type that it not public or > protected then that is a bug in the API. Unfortunately Sun has not responded > to these bugs - eg GridBagLayoutInfo - in the past six years. Sun unresponsive? Never! Say it ain't so! > Other than treat these inaccessible types as objects, no program could > effectively make any use of them. > > That doesn't really help with your predicament however. I think it does... it's a datapoint in favor of excluding them from the japi file which is the way I was leaning already. The one I'm most nervous about excluding (although I don't know if it ever actually comes up) is inaccessible thrown exceptions. You can always catch those by just catching them as Exception, so the method is usable. On the other hand it would guarantee an API error because the Free implementation would be completely unable to provide the same throws clause. Perhaps Japize should go and find the nearest public superclass of the inaccessible exception type and pretend that that was what appeared in the throws clause... Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: japi and public references to non-public types
On 10/4/05, Stuart Ballard <[EMAIL PROTECTED]> wrote: > I can't think of any reasons why any such field (or a method taking a > non-public type as a parameter or returning one) should ever matter in > practice for compatibility, but I'd like to see if other people feel > the same way before trying to implement skipping them. I've got an implementation of this in my local copy for testing. I had it spit out the list of items that would be skipped if we skipped all fields with a non-public type and methods with non-public parameter types, return types or thrown exception types. I'd also like to catch anything with a non-public type parameter bound, but my initial naive implementation stackoverflowed on (where else?) Enum>. The list that came out was: java.awt,GridBagLayout!#layoutInfo java.awt,GridBagLayout!GetLayoutInfo(Ljava/awt/Container;,I) java.awt,GridBagLayout!GetMinSize(Ljava/awt/Container;,Ljava/awt/GridBagLayoutInfo;) java.awt,GridBagLayout!getLayoutInfo(Ljava/awt/Container;,I) java.awt,GridBagLayout!getMinSize(Ljava/awt/Container;,Ljava/awt/GridBagLayoutInfo;) javax.management.loading,MLet!check(Ljava/lang/String;,Ljava/net/URL;,Ljava/lang/String;,Ljavax/management/loading/MLetContent;) javax.management.loading,PrivateMLet!check(Ljava/lang/String;,Ljava/net/URL;,Ljava/lang/String;,Ljavax/management/loading/MLetContent;) javax.management.timer,TimerAlarmClockNotification!(Ljavax/management/timer/TimerAlarmClock;) javax.naming,CompoundName!#impl javax.swing,JRootPane!#defaultPressAction javax.swing,JRootPane!#defaultReleaseAction javax.swing,JTree$EmptySelectionModel!notifyPathChange(Ljava/util/Vector;,Ljavax/swing/tree/TreePath;) javax.swing.plaf.metal,MetalBorders$ToolBarBorder!#bumps javax.swing.plaf.metal,MetalFileChooserUI!createDirectoryComboBoxRenderer(Ljavax/swing/JFileChooser;) javax.swing.plaf.metal,MetalScrollBarUI!#bumps javax.swing.plaf.metal,MetalSplitPaneDivider$MetalDividerLayout!(Ljavax/swing/plaf/metal/MetalSplitPaneDivider;) javax.swing.plaf.synth,SynthSliderUI$SynthTrackListener!(Ljavax/swing/plaf/synth/SynthSliderUI;) javax.swing.text,ParagraphView!adjustRow(Ljavax/swing/text/ParagraphView$Row;,I,I) javax.swing.text.html,AccessibleHTML$HTMLAccessibleContext!#elementInfo javax.swing.text.html,AccessibleHTML$HTMLAccessibleContext!(Ljavax/swing/text/html/AccessibleHTML;,Ljavax/swing/text/html/AccessibleHTML$ElementInfo;) javax.swing.text.html,AccessibleHTML$IconElementInfo$IconAccessibleContext!#elementInfo javax.swing.text.html,AccessibleHTML$IconElementInfo$IconAccessibleContext!(Ljavax/swing/text/html/AccessibleHTML$IconElementInfo;,Ljavax/swing/text/html/AccessibleHTML$ElementInfo;) javax.swing.text.html,AccessibleHTML$TableElementInfo$TableAccessibleContext!#elementInfo javax.swing.text.html,AccessibleHTML$TableElementInfo$TableAccessibleContext!(Ljavax/swing/text/html/AccessibleHTML$TableElementInfo;,Ljavax/swing/text/html/AccessibleHTML$ElementInfo;) javax.swing.text.html,AccessibleHTML$TableElementInfo$TableAccessibleContext!addRowHeader(Ljavax/swing/text/html/AccessibleHTML$TableElementInfo$TableCellElementInfo;,I) javax.swing.text.html,AccessibleHTML$TableElementInfo$TableAccessibleContext$AccessibleHeadersTable!addHeader(Ljavax/swing/text/html/AccessibleHTML$TableElementInfo$TableCellElementInfo;,I) javax.swing.text.html,AccessibleHTML$TextElementInfo$TextAccessibleContext!#elementInfo javax.swing.text.html,AccessibleHTML$TextElementInfo$TextAccessibleContext!(Ljavax/swing/text/html/AccessibleHTML$TextElementInfo;,Ljavax/swing/text/html/AccessibleHTML$ElementInfo;) javax.swing.text.html,ParagraphView!adjustRow(Ljavax/swing/text/ParagraphView$Row;,I,I) javax.swing.text.html,TableView$RowView!(Ljavax/swing/text/html/TableView;,Ljavax/swing/text/Element;) javax.swing.tree,DefaultTreeSelectionModel!notifyPathChange(Ljava/util/Vector;,Ljavax/swing/tree/TreePath;) Anyone who knows any of those areas of code have any strong feelings either way on whether those items shout be treated as part of the public API or not? Can any of them actually be used for anything useful despite the non-publicness of types associated with them? Stuart. PS I sent a mail to classpath-patches earlier today with some other trivial japi fixes but it's stuck in moderation since I'm not subscribed... -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
japi and public references to non-public types
I was looking into the javax.naming issue against 1.3 (field CompoundName.impl missing in classpath) and found that (unsurprisingly) the author of the class was completely aware of the "missing" impl field but there was no good solution, because the impl field is of type javax.naming.NameImpl which is a package-private class. It would of course be easy to "solve" the API problem by defining our own empty package-private NameImpl class, but I'm wondering if it would be better for Japitools to catch this kind of situation and treat the "impl" field as if it's package-private itself - that is, ignore it entirely since japi only deals with public and protected members. I can't think of any reasons why any such field (or a method taking a non-public type as a parameter or returning one) should ever matter in practice for compatibility, but I'd like to see if other people feel the same way before trying to implement skipping them. I'm already doubting the last decision I made in japitools without feedback (I'll post about that separately) so I'm being cautious :) The only problem with such an approach is that it would probably slow down japize and increase its resource usage somewhat (no idea yet exactly how much, could be minor but could easily be dramatic), because currently the types of fields, return types of methods and parameter types of methods and constructors are just referenced by name in japize - the corresponding classes are never actually loaded from the zip (or rather, they're only loaded when it's time to process *that* class, not when it's referenced from somewhere else). But loading them is necessary to determine what their modifers are to decide whether to skip them. Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
japi and protected field declaring classes
As I mentioned in my blog, I added support to japitools for checking
the declaring class of fields. The example of code I used to justify
this was:
Implementation 1:
public class Super {public int foo;}
public class Sub extends Super {}
Implementation 2:
public class Super {public int foo;}
public class Sub extends Super {public int foo;}
Client code:
void incFoo(Super sup) {sup.foo++;}
Sub x = new Sub();
incFoo(x);
System.out.println(x.foo);
I still think this is a valid concern and it's right for japitools to
catch it, but when I actually saw what happened as a result of this in
the nightly comparisons, I started to have my doubts over whether the
check I implemented is over-zealous.
It appears that Sun have a field numBands in java.awt.image that's
exactly like Implementation 2 above (declared in both
ComponentSampleModel and SampleModel), except that it's protected.
(someone fixed classpath to conform to this, gmane isn't helping me
find out who actually did it right now though).
The problem I'm seeing (and I feel bad for only realizing this after
someone did work based on japi's output) is that my example code to
support the claim that this difference is important to binary
compatibility only works if the field is public. If it's protected
there's no possible way to write the incFoo method to make it actually
modify the superclass's foo field.
So I'm beginning to think that the declaring class should only matter
for public fields and I should change japitools to not consider it for
protected fields. Can anyone think of a way to write code where the
declaring class *does* matter when the field is protected?
If it really doesn't matter, I'm sorry to the person who made the
awt.image fix based on this misinformation out of japi... :(
Stuart.
--
http://sab39.dev.netreach.com/
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: Wanted: SerialVersionUID experts ;)
Excellent, that fixed it :) I'd already added a bunch of conditional
debugging code that I'll leave in, but disabled, because it will be
useful if any other incorrect svuid issues come up.
FWIW, the other svuid error in the CVS version was equally easy:
- fields[i].getType().equals("J") &&
+ fields[i].getType() == PrimitiveType.LONG &&
Using .equals() to compare strings has something of a downside when
something that used to be a string suddenly isn't any more...
On Monday (when I have access to the relevant machine again) I'll
apply this fix in the nightly results.
Stuart.
--
http://sab39.dev.netreach.com/
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Wanted: SerialVersionUID experts ;)
Tom pointed out a little problem with Japitools' serialVersionUID calculation. In his words: On 23 Sep 2005 10:21:39 -0600, Tom Tromey <[EMAIL PROTECTED]> wrote: > I see this in the japi pages: > > * class >java.beans.beancontext.BeanContextServicesSupport.BCSSServiceProvider: >SerialVersionUID=7078212910685744490 in jdk14, but >SerialVersionUID=861278251667444782 in classpath > > ... but when I look by hand at the jdk I see something else: > > opsy. serialver > java.beans.beancontext.BeanContextServicesSupport.BCSSServiceProvider > java.beans.beancontext.BeanContextServicesSupport.BCSSServiceProvider: > static final long serialVersionUID = 861278251667444782L; I've confirmed both facts for myself: Japize, including the CVS version, comes up with 7078... for this class in the JDK, but serialver says it's 8612... Since svuid calculation is almost impossible to debug, I thought I'd post to the list and see if anyone here had worked on this for Classpath or gcj and whether they have any tricks to figure out why the value from Japize isn't matching what Sun says. The CVS version of Japize has some svuid-calculation bugs anyway, but I can debug those ones by adding printlns and comparing to the released version. But I don't have the faintest idea how to compare against Sun's version which I don't have the luxury of adding printlns to ;) In Japize, the svuid is calculated in ClassFile.java using code heavily based on ObjectStreamClass from classpath, but comparing the two didn't yield any enlightenment. All the differences seem to be due to the fact that ObjectStreamClass is working with reflected classes while ClassFile is working with its own objects. One interesting test that I'm not sure how to do would be to see what value Classpath's ObjectStreamClass would get for *Sun's* version of BCSSServiceProvider. If Classpath gets it right I could debug by adding printlns there too. If not... we've found a Classpath bug. Any suggestions? Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: changes in external/
Wouldn't it be better to push the patches upstream at the same time? Obviously making Classpath local changes is necessary if the upstream projects won't take them, but IMHO that should be a last resort and I can't see any reason why an upstream project *would* refuse them. If the patches are accepted upstream the changes could still be made locally until the next import from the upstream project, but then there's no need to mark them to be re-evaluated every time new versions are pulled down. Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: GNU Classpath and JVMs
On 9/15/05, Dalibor Topic <[EMAIL PROTECTED]> wrote: > Missing bits and pieces: > String (yay, same as gcj. May be really hard. ;) > java.lang.reflection (hard in a way, easy in a way. Hard since GNU > Classpath has almost no code for it, so it'll be easy to merge in > Kaffe's implementation. Volunteers!) > java.util.zip (easy to do by switching completely over, but then the > performance is going to suffer extremely on the interpreter on slower > CPUs. Otoh...less work for me, and more pressure on people to write/fix > jits. Hmm... ;) Makes me wonder, since the need to override certain files and/or packages in Classpath for a particular VM is such a common scenario, whether Classpath's build system shouldn't include native support for this. Obviously this doesn't jive with the eventual goal of a single glibj.zip shared between all runtimes, but until that point is reached, it might save Dalibor in particular lots of work ;) Wouldn't it be nice if there were a way to stick a kaffe.overrides file somewhere which contained something like: path ../whatever class java.lang.String package java.lang.reflect package java.util.zip Then you'd build classpath --with-overrides=path/to/kaffe.overrides and it produces a glibj-kaffe.zip taking most of the sources from the usual place but the String, reflect and zip sources from the ../whatever path instead. I think gcj already has something like this, because since the Big Merge they're actually using classpath in a subdirectory, but they still need to override some classes. But it seems like something that would be useful beyond gcj and kaffe and having each VM roll their own solution to the same problem seems silly. Unfortunately my build-system-fu is non-existant so I'd be completely incapable of implementing this myself. Perhaps everyone already thinks it's a good idea and the only reason it hasn't happened yet is nobody's volunteered, in which case this mail was kind of pointless ;) Thoughts? Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: rmi vs cajo
I've seen various blog posts and things that give the general advice that calling a virtual method from a constructor is pretty much always a bad idea. "Considered harmful", that kind of thing. That's difficult advice to follow in Java since almost everything's virtual and there's no definite cue as to whether it's *intended* to be overridden or not, but at the very least it's safe to say that hashCode is intended to be overridden, since that's the whole point of its existence. Even ignoring the fact that this seems to be required for Sun compatibility (which is sufficient by itself to make the decision), I think we ought to change this code. Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [japitools] more generic evilness - is this legal?
On 9/12/05, David Holmes <[EMAIL PROTECTED]> wrote: > Raw types make things very messy. I think your are confusing the nesting > aspects and the inheriting aspects of types. You're not kidding that they're messy ;) I don't think I was exactly confusing the nesting and inheriting aspects, just misunderstanding the "all or nothing" requirement. I thought it applied "globally" so you couldn't use a raw type inside a generic containing class because that would be partially qualified from a global point of view. >From japitools point of view it does make things a little complex to deal with because of the way japi files represent these things - it does lead to situations where japitools' representation will have to act as if some types are bound and some unbound. But I can see how from the Java language perspective this doesn't apply. > Hope this helps. It certainly does. Thanks! Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[japitools] more generic evilness - is this legal?
I hope people don't mind me using this list for japitools discussion -
I think it's relevant to Claspath as the primary consumer of the
results...
Anyway, I found another evil case that javac accepts and I'm wondering
if any of the experts on the JLS can tell me whether this is
*supposed* to be acceptable...
class Outer {
class Inner {
}
class InnerTester extends Inner {
}
public InnerTester getIt() { return new InnerTester(); }
}
public class Tester2 {
public static Outer.InnerTester getIt() {
return new Outer().getIt();
}
// Fails to compile because Inner is "half-bound"
// But for some reason InnerTester is okay even though it results in
// Inner being equally half-bound.
//public static Outer.Inner getIt2() {
// return new Outer().getIt();
//}
public static void main(String[] args) {
System.out.println(getIt());
}
}
The bit that fails to compile is obvious - you can't have
Outer.Inner because T is bound but U is not. However, I can't
understand why InnerTester is legal, because it's in exactly the same
boat - in fact, it's superclass *is* Outer.Inner.
The rules as I understood them were that you could have a raw type,
with all generic parameters omitted, or a fully-qualified type with
all the parameters specified, but specifying some but not all was
illegal. This appears to be an exception to that rule?
It gets worse...
class Inner {
class InnerInner {}
}
class InnerTester extends Inner {
InnerInner foo;
}
Now InnerInner has T bound, U unbound and V bound - there's a hole in
the *middle* of the list of parameters. Is this *really* supposed to
be legal?
Stuart.
--
http://sab39.dev.netreach.com/
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: Japitools 1.5 support tough design issue
On 9/10/05, Andrew John Hughes <[EMAIL PROTECTED]> wrote: > Forgive me if this is stating the obvious, but for anyone who doesn't > know, the third edition of the Java Language Spec. is now on-line > and includes some information on binary compatibility as regards the 1.5 > additions: > > http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html As I read this, it does mostly state the obvious in an awful lot of words ;) Basically, "as far as binary compatibility is concerned, ignore the type parameters altogether and treat uses of them as if they were the constraining type". > In terms of implementing Classpath, however, I think JAPI may need to go > beyond this, although I'm not altogether sure whether this is within its > scope of interest. Actually 1.5 is forcing japitools to re-evaluate its scope of interest. In 1.4 using the binary compatibility rules (with a few additions as noted somewhere on the japitools website) was a pretty good way to get a meaningful compatibility test. If you were binary compatible in both directions then in almost all cases you were source compatible too, even though source compatibility rules have never been written down, as far as I know, for Java. For 1.5 this is no longer true and clearly a pure binary-compatibility test is only of limited use (FWIW, that's effectively what we have now in the comparisons versus 1.5 since the 1.5 binary compat rules are in essence identical to the 1.4 rules that japi uses). I suspect that over time the precise rules that japitools uses to test for compatibility in the presence of 1.5 extensions will evolve as we learn more about what situations are really problematic or not. Once the japi results online start reflecting 1.5 features, I'll be requesting feedback on whether there's anything being reported as an error that shouldn't be, or vice versa. Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: HTTPURLConnection.connect() buffers its entire input.
On 9/9/05, Nic Ferrier <[EMAIL PROTECTED]> wrote: > Personally, I think Chris should add a lazy (streaming) interface on > top. But there is a thread cost. Is there no way to only call select() when calls are made to the API, in the thread that makes the call? getInputStream() could return a stream that calls select() (directly or indirectly) in its available() and read() methods, getHeader() (if we don't want to get all the headers up front) could call select() if the header in question is not yet known, etc. I'm not really familiar with the nio API (as you can probably tell) but it seems like this kind of thing should be possible. Wasn't the whole point of nio to *avoid* the need for "thread-per-connection" programming? Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
