Another reflection bug; compatibility results

[Stuart Ballard]

"Edouard G. Parmelan" wrote:
> 
> Stuart Ballard wrote:
> 
> > Well, I've made some changes to the class since I "announced" it here a
> > while back and put up a homepage at http://stuart.wuffies.net/japi/ .
> > The reason I mention this is (1) I'd like feedback, and (2) I have the
> > results of running japicompat between jdk11 and kaffe, and there are 425
> > reported errors, although most of them are duplicated several times
> > because they are errors in java.awt.Component or java.awt.event.AWTEvent
> > and they get reported for every subclass (I'd like to eliminate these
> > duplicates but I can't think of an easy way to do it).
> 
> I think you can use c.getDeclaredXXX() in place of c.getXXX() to get
> ride of inherited fields/methods.

Right, but it's legal for an implementation to move a method up to a
superclass, so I need to include superclasses' methods in the output
listing or you could get bogus errors. The removal of duplicates would
have to happen in japicompat.pl. I know how to do this but it's not
trivial; basically I need to sort the input so that every class is
processed before its subclasses, and then test each error to see whether
the same error occurred on the superclass. It's on my todo list (and
even on the webpage as of a few minutes ago...)

I do want to get what I have commented better before I start adding
features like that though; it would take a fairly large rewrite.

> Raw idea:  Did you think it's possible to use a ClassLoader to load
> jdk1.1 classes and an other to load Kaffe (or GNU Classpath) classes ?

Yes, but URLClassLoader is 1.2 only and I'm using 1.1 primarily. I could
write a ClassLoader from scratch, but that sounds hard! Also, I'm not
sure that I want to know what would happen if I tried to load
java.lang.Object from a classloader, and there are issues with native
code; I can only imagine what would happen if I tried to load Kaffe's
java.lang.Object onto the JDK with its native code intact...

> If so, you could have a one pass comparison framework.

Originally it bothered me that I couldn't provide that, but now I'm
beginning to think that this way is better. After all, I can distribute
a ~1Mb jdk11.japi file and save all my users downloading the full ~8Mb
of JDK1.1 (the gains for 1.2 and 1.3 are presumably bigger still); it
also makes it possible to run testing on a machine containing only free
software, so long as you have a copy of the japi file generated by
JDK1.1.

> An other solution could be to use a classes manipulations packages as
> at.dms.classfile or gnu.bytecode.  Both use GPL Licences.

That's another approach, but Japize works pretty well at this point -
most of the work I want to do is on japicompat. The last 3 or 4 major
changes I've added to Japize have been Zip support, command line
changes, filesystem support, and so on... the actual API outputting has
been pretty stable for a whole 3 days of heavy hacking on the rest of
it. I'd need a pretty convincing reason to drop Japize and use something
else. If you're interested in pursuing one of the other approaches, by
all means go for it; if it works within the same framework as Japize and
japicompat then I'd certainly be happy to integrate the code. I do have
a slight twinge of regret that as things stand now I can't ever produce
a jdk10.japi...

Thanks for the input :)
Stuart.