sab39

(I'm running out of puns for post titles - suggestions in the comments please! ;) )

I've put very preliminary CVS Japi results between Classpath's generics branch and JDK1.5 up. Thanks to Andrew, these will be regenerated every night using the very latest japitools.

There are an awful lot of known bugs and limitations right now. If you intend to use these results for anything, I strongly suggest being very careful to confirm by other means that there really is a problem before wasting any time trying to fix it.

If anyone's looking for an easy way to contribute to Japitools, one thing that would be extremely handy would be a regression test system. Given a .java file, compile it, Japize the result and confirm that it's equal to the expected result (apart from the timestamp etc). Or, given two .java files, compile them both, Japize them both, japicompat them, and confirm that the expected errors show up. As everyone knows, code without regression tests is just asking for things to break and nobody to notice.

Sven tackled the last 1.2 Font issue, but the BeanContext one turned out to be, quite literally, one step forward and two steps back. Fixing the Japi bug that had led to an incorrect SVUID revealed that two other classes in the same package had trusted the old Japi information, so now they're wrong instead. So still 9 errors total...

For any potential Classpath contributors looking for things to hack on: Japitools is currently listing only one error against 1.1, and outside of Swing, only eleven more errors against 1.2. Although I'm not directly familiar with the code, these generally seem like they should be nice bite-sized tasks for people with an interest in the areas in question:

• field java.awt.Font.pointSize: missing in classpath
• method java.awt.FontMetrics.getMaxCharBounds(java.awt.Graphics): missing in classpath
• method java.awt.FontMetrics.hasUniformLineMetrics(): missing in classpath
• method java.awt.print.PrinterJob.print(javax.print.attribute.PrintRequestAttributeSet): new abstract method in classpath
• method java.beans.Introspector.getBeanInfo(java.lang.Class, int): missing in classpath
• method java.beans.IndexedPropertyDescriptor.setIndexedReadMethod(java.lang.reflect.Method): missing in classpath
• method java.beans.IndexedPropertyDescriptor.setIndexedWriteMethod(java.lang.reflect.Method): missing in classpath
• class java.beans.beancontext.BeanContextServicesSupport.BCSSServiceProvider: SerialVersionUID=7078212910685744490 in jdk12, but SerialVersionUID=861278251667444782 in classpath
• class java.rmi.activation.ActivationGroup_Stub: missing in classpath
• field java.rmi.server.LoaderHandler.packagePrefix: constant [sun.rmi.server] in jdk12, but constant [] in classpath
• field java.rmi.server.RemoteRef.packagePrefix: constant [sun.rmi.server] in jdk12, but constant [gnu.java.rmi.server] in classpath
• method java.rmi.server.RMIClassLoader.loadClass(java.net.URL, java.lang.String): missing in classpath (1.1)
  

In other news, I'm wrestling with japitools corner cases. Like the eeville generics-related one that's causing CVS Japize to tell me that java.lang.Boolean has two compareTo(Boolean) methods and one of them is abstract. Utterly discouraging, because having finally got Japize to actually run successfully against JDK1.5 capturing generic information (thanks again Jeroen :) ), I now need to refactor the inheritance-handling code again to fix it. No wonder I'm writing a blog post instead. And this one: Are these two APIs compatible with each other?

public class Super {public int foo;}
public class Sub extends Super {}

public class Super {public int foo;}
public class Sub extends Super {public int foo;}

I'd argue that they're not.

void incFoo(Super sup) {sup.foo++;}
Sub x = new Sub();
incFoo(x);
System.out.println(x.foo);

(This isn't just an implementation detail - the fields are part of the public API and so the behavior of incFoo should be entirely predictable based on that API)

Japitools today, however, would say that they're compatible. In fact, since the japi file format specifically includes all inherited members, the japi files would be completely identical for those two APIs. It appears that while moving methods up and down the inheritance chain is entirely compatible, moving fields up and down is not. Now the question becomes, how to fix the japi file format to capture this information...?