... indistinguishable from magic
effing the ineffable since 1977


Recent Posts


So Japi Together


(Thanks to Steven for today's pun)

For a long time it seemed that my work, and Jeroen's, on the 1.5 support in Japitools was taking forever and nothing was actually being achieved. We had file formats specced out, sure, and later on we had data structures built to represent 1.5 features, and that kind of thing. But it was all under the hood, and most of the time Japize wouldn't even run, and even if it did japicompat couldn't make heads or tails of its output. This state went on for weeks - months, actually, the file format spec was originally written a long time ago, although for most of that time no work was being done.

So it's quite surprising and very rewarding that within a week of the first successful japicompat results being produced we suddenly appear to have almost feature-complete 1.5 capability. Annotations are missing - they'll be worked on next - and there are a few loose ends to tie up. I also want to compare the results line-by-line to the released version on all pre-1.5 versions and make sure every difference is accounted for before I start suggesting that people primarily use this version. But wow.

It's nice to have progress of my own to report instead of just watching in awe as the Classpath hackers churn through the percentages, but they've certainly not been standing still. It was September 5th that I first was amazed to see Classpath creep past the 90% mark against 1.4 for the first time; now it looks like 95% will most likely be achieved sometime this weekend. You guys have halved the gap in less than a month!

The remaining 1.2 bugs are rapidly biting the dust too. Roman implemented ActivationGroup_Stub and - YES! - the loadClass method that was the last remaining 1.1 error. Tom fixed the two BeanContextServices svuids and nipped an incorrect ActivationGroup_Stub svuid in the bud. Thomas sorted out the incorrectly-abstract method in java.awt.print. The upshot of all this is that there are now only 6 errors outside of swing against 1.2. You might think there are only 5, but I'm afraid the CVS Japi knows how to look for fields declared in the wrong place and it found another one in java.awt.image. Oh, and only a single missing field in javax.naming on top of these would limit 1.3 errors to only javax.rmi.CORBA, javax.sound.sampled, and swing...


Don't worry. Be Japi.


(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...


Shiny Japi people holding hands

The two FontMetrics issues got fixed (thank you Sven); the BeanContextServices one turned out to be a Japi bug (fixed now but I won't be able to put the fixed version into place for another couple of days - thanks Tom for investigating). So that's 9 remaining genuine errors against 1.2 outside of Swing...

The insane rate of progress continues: 93.98% against 1.4, 93.03% against 1.3 and 95.47% against 1.2. I'm beginning to worry that Classpath will hit 100% of 1.4 before Japitools is ready to give meaningful results against 1.5... ;) Still, progress is being made on that front too.


If you're Japi and you know it clap your hands

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 [] in classpath
  • method java.rmi.server.RMIClassLoader.loadClass(, 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) {;}
Sub x = new Sub();

(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...?


My compiler is psychic...

C:\projects\japitools\src>jikes -d .. net\wuffies\japi\*.java

Found 1 syntax error in "C:/projects/japitools/src/net/wuffies/japi/":

955. if (i != index && excps[i] is ClassType &&

*** Syntax: instanceof expected instead of this token


Talk about friendly error messages! How did it know? Does jikes encounter confused C# programmers often?

Next Page