Was today highly impressed with the user manual of my brand new automated vacuum cleaner LG Roboking. The device runs Linux kernel 2.6 and internally uses Bash, BusyBox, U-boot, glibc and OpenSSL! And, most important, the dedicated page in the manual gives clear directions where to apply of the source code.

Teach you child arithmetics with Ultrastudio.org server

Today I got tired of writing arithmetic training sheets by hand for my eight year old daughter and deployed instead a tiny servlet. It generates the ready to print sheets to practice multiplication, division, addition and subtraction. Enjoy free service for all hackers at School_tasks on Ultrastudio.org. Others also may have children of this age. Plain text output, no Java, no JavaScript, no Moonlight. Even lkcl can use!

After various attempts and trials to undock my applets at Ultrastudio.org I returned to the old conclusion that the best it to do this through Web Start. All these fancy "Undock buttons" seem cute from beginning but it is not that easy to add them to over hundred of applets we already have. JNLP actually has constructs that allow to launch the same unmodified applet .jar and the applet have nicely popped up in a separate frame over my nose under Fedora from the first attempt. Cool, we can share applications just by sharing JNLP files or even they download URLS, try one. All that was required is to write a JSP template for Tomcat, and now JNLP is generated on the fly all for our visualizations.

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.

Have just posted on Kenai a summary of common problems found in Ultrastudio.org java applets. There are some general tendentions that may give valuable hints on that went wrong in the past. While I myself simply placed "download the latest version" on my site, many applet developers really tried to keep they applets runnable under 1.1 or 1.0, even adding numerous classes of that looks like a rudimental implementations of they own Swing. Other shared problems, also covered in the review, are event handling, GUI designers, resource loading and animation threads.

The summary can be found in Kenai forum