sab39

... indistinguishable from magic
effing the ineffable since 1977

Categories

Show All

Recent Posts

Archives

To Do Lists and Free Java

12/14/2004

When faced with a large problem to solve, the only way I am ever able to successfully tackle it is to break it down into a list of smaller tasks, and work my way through that list. When the list is really long, even that seems intractable, and I need to find ways to break it down further, by identifying a subset of the list to tackle first, get all of that done, and then work on the rest.

Even though I'm not actively working on the GNU Classpath project any more (I barely ever did, to be honest - I contributed a few classes but I think they all got replaced with brand new, better versions) I figured that it's possible that some of the people who are working on it might tackle problems the same way I do, and if I could automate the creation of the list of tasks, it might help them in the same way it helps me. That's the chain of thought that led to the creation of japitools.

I've watched and cheered from the sidelines as Classpath, Kaffe and company have come from nowhere to the astonishingly high japi scores they show today. It doesn't seem so long ago that even compatibility with Java 1.1 was miles away, and completing 1.2 barely conceivable. But now the Free libraries are consistently reaching 70% of 1.4 compatibility, which is unbelievable. They're so close that it's possible to list the "big holes" (against 1.4 at least) and still have fingers left over on one hand.

1. Swing (only swing.text and swing.plaf though)
2. CORBA (the org.omg packages)
3. Imageio (Mostly done, but missing a few bits)
4. Kerberos (one single package missing from javax.security)

Literally every other package in 1.4 now has at least 80% API coverage in some form of Free implementation. The last two are small, and work on filling the remaining holes in Swing is proceeding at an unbelievable rate.

Japi results with JacORB included have been produced which at first led me to believe that good coverage of the CORBA packages was within easy reach too. After all, those results have a lot of green on them. But despite JacORB's claim to be under the LGPL, people kept mentioning license problems so I decided to investigate, and the results were somewhat depressing. A little perl script I wrote to identify the license of files in JacORB led to this result:

LGPL pkgacc: 76
LGPL public class: 603
LGPL public interface: 79
Unlicensed (org.jacorb) public class: 147
Unlicensed (org.jacorb) public interface: 6
OMG public class: 199
OMG public interface: 144
Unlicensed (OMG) pkgacc: 1
Unlicensed (OMG) public class: 90
Unlicensed (OMG) public interface: 8
Unlicensed (HTTPClient) pkgacc: 23
Unlicensed (HTTPClient) public class: 23
Unlicensed (HTTPClient) public interface: 7
Unlicensed (demo) pkgacc: 7
Unlicensed (demo) public class: 102
Unlicensed (demo) public interface: 1

The "Unlicensed" files are files that the script couldn't identify an explicit license in, but the ones marked "(OMG)" seem likely to be under the OMG license based on other files in the same directories. The OMG license grants unlimited use and distribution, but does not allow modification, which renders it non-free and unacceptable for Classpath and Kaffe. So at least 290 classes and 152 interfaces are under this unacceptable license, which is small compared to the thousand or so that are or appear to be under the LGPL, but still pretty large in absolute terms.

(As an aside, I can make a strong argument that the interfaces aren't actually a problem because it's legal to generate them from japi files, since japi files don't contain any copyrightable information. The same might be true of some of the classes if they were purely abstract, but I tested for this - the vast majority aren't abstract at all.)

Things got even worse when I correlated these results against a japi file of the JDK, to get an indication of how many of the problematic files were part of the public API:

InJapi OMG public class: 168
InJapi OMG public interface: 85
InJapi Unlicensed (OMG) public class: 77
InJapi Unlicensed (OMG) public interface: 5

In other words, every single class in the public API is under an unacceptable license. Every single bit of green in the CORBA packages in those oh-so-encouraging Japi results is worthless. JacORB may still be very useful to back up the CORBA packages with some actual implementation, but as far as API coverage is concerned, it seems we're on our own.


 
RSS