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
OpenJDK on Ubuntu: Java Headless exception is caused by the incomplete Java installation.
Recent Ubuntu releases (10.04 LTS) show quite a nasty behavior when trying to start Java application: the application crashes on startup with Headless exception.
This is cause by the by default incomplete installation of OpenJDK. It is kind of present but missing some packages that are available on Ubuntu repository. On the discussions on the web I found people suggest to switch immediately to Oracle's proprietary java or even into Windows.
Unfortunately I had no time to copy stack trance and the exact name of the missing package - needed to fix the problem quickly and now is too late. But this is no any rocket since; the missing package is something like "java jre" - could be assumed to be the full installation rather than somehow stripped one that comes by default.
Check packages in the repository if you have this problem. Hope you fill fish out this message with Google. Good luck!
Today I have registered Ultrastudio.org on Project Kenai. This portal provides forum, mailing lists and Bugzilla, and we plan to use all this - it would be a lot of work to set up and run on our own server, even if it is technically possible and I in general know how. There is also some hope that with the dedicated forum backend we will get more feedback - not all people like to use Wiki engine for discussions. So far the most valuable feedback seems coming from the server logs - where do the people go on the site. The number of applets is currently approaching 80 and could easily be more but we decided to pause temporary the active collection and work for some time on a cleanup and supplementary material.
It is surprisingly simple to undock the applet: the code that does this simply removes it from some mysterious container where it is attached on a browser and then is free to place it into trivial JFrame. It is even possible to reattach the applet to its browser container when the user closes this JFrame (inside the window listener).
It is more difficult to implement support, how to signal that we want to undock the applet. Oracle talks something about dragging out with ALT key pressed but with my IceTea seems not working very well - I can register mouse listener on applet but majority of mouse exit events do not get delivered. Adding a button into JLayeredPane seems more promising: inside this pane, the button is nicely over the rest of the applet, exactly in location I can set with setBounds(...) and reacts to mouse click, calling my action listener. The new problem is that the button is covering part of the applet interface; thinking that to do now. Maybe the button can be auto-hidded after several seconds of run.
Be with it, with this Mac and these foggy talks about Java deprecation on that platform! Mac OS makes 5.0 % of all visitors on Ultrastudio.org when Linux makes 9.9 %, graph here. Seen who has "failed on desktop". Also, maybe Roman with Mario will get IceTea as a better replacement of the proprietary Apple Java virtual machine.
First Google-Oracle discussions and now this. Likely it was the most unlucky time throughout the history of Universe to launch the Java applet portal.
Today is near one month as our Ultrastudio.org, encyclopedia with Java applets (code reviews, service side build and approval workflow) is online. During this time, the site has grown from the initial 14 applet "seed set" about 50 applets at the moment, each of them having explaining article next to it. Some articles reuse Wikipedia material, but many are differently written, aiming for short, clear introduction rather than full of coverage. The numbers are not that big, and actually only tiny fraction of even very promising topics is covered, but the site already gets in average about 154 page views per day (excluding spiders and all Switzerland). Many applets have been launched. Ultrastudio.org is currently heading the "top 5 %" rating list at Jars.com. This seems enough for the project of our age and profile.
Great to have IceTea plugin that makes such projects possible.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!