|
|
If you're Japi and you know it clap your hands
|
|
| 9/21/2005 |
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...?
|
|
|