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.