11 Jul 2011 (updated 11 Jul 2011 at 14:45 UTC)
»
Found Pekka blog on a web. I was thinking myself a lot if anything positive can happen with GNU Classpath in the future.
You cannot just attract random people to contribute in free time to a project like this. After all, they employer needs to sign agreement that is unlikely to be easily signed unless GNU Classpath is important for the company itself, not just as a personal way or recreation for a programmer. Important and necessary as it is, this document is a heavy requirement.
Classpath has been developed mostly by people from companies and research institutions (Red Hat, Aicas, Trifork, Intel, Object Refinery, CACAO group, Kaffe group and others), because they all had projects requiring THIS library and Sun's implementation was not a good or even possible replacement for them. It had its own obvious niche: it was Free Software when Sun's implementation was not. With Sun opensourcing Java, this niche has been lost and we need to find another.
I think the only way to get people back is to give Classpath something that OpenJDK does not have. Possible ways of "being better and different" potentially could be:
* The remaining tiny difference in the licensing: OpenJDK is locked to GPL v 2, Classpath contains the clause "any later version".
* It still can be easier ported to the new platforms so seems showing more life in ARM-based embedded devices and similar.
* As new features cannot be added, one of my past strategies was to try implement specifications more strictly and completely, passing independent (not invented by us) tests that original Sun's implementation does not pass. We do have such cases, but the proposals to wipe automatically everything that fails on todays Sun's library are also not new, has been heard many times.
* Classpath was also competing on performance by supporting the true compiler and not just a jitter. This however also seems not that easy area to compete now.
Maybe somebody could list something more in addition but I really do not think that migrating to the new SCM will help. As TCK is still not free, Mauve can actually be more valuable than Classpath itself and may make more sense to work on it instead. I think that tests should be grouped by importance and severity, allowing to disable easily that is out of scope of the current project. It could also be more friendly to use, I remember once somebody told on discussions that "Mauve is a beast".
However the value of Mauve is in tests and not in the framework that consists of just several unsophisticated classes on the top of Ant. The tests, at least majority of them, must be ported to preserve the value of the project. This looks much less attractive than just putting a new empty testing framework.