First, download and unzip the Ecipse + J2EE package from http://www.eclipse.org/downloads/. You do not need to ‘install’ Eclipse as such, just put the uncompressed directory somewhere logical (/Applications on a Mac, for example).

1. Launch Eclipse
2. Select: Help -> Software Update -> Final and Install.
3. Select Search for new features to install
4. Check the Europa Discovery Service
5. Select Add Remote Site

1. Type in name: Aptana (For javascript support)
2. Type in url: http://update.aptana.com/install/3.2/
3. Select OK

Phew, so after all that, you should have an Eclipse IDE set up to support PHP, Ruby, Rails, Javascript, Java, Hibernate and Subversion. You can, of course, select many other tools from the Europa discovery site for other development tools, graphical editing and the like.

It would be nice to have a small js library that allowed you to dynamically instantiate and destroy embedded, hidden applets.

Basically, you can annotate your classes with url’s describing the RDF namespace of the class or property. You can then use SPARQL to query/retrieve the beans, and serialize them to/from XML. Serialization can be acheived through the Sesame framework.

Elmo User Guide

Additionally, there is another project, JRDF, that builds upon Sesame and Jena. I have yet to use it, but sounds like in encompasses the best of all worlds.

Using this, we created an applet with no UI, that sits in a 0×0 pixel container, and a javascript support library which communicates and wraps the functionality provided by robonobo. All the UI can now be rendered using html, css and javascript, in a very ajaxian fashion.

There are a couple of gotchas though:

• You cannot return primitive types such as int, float, etc. Instead you must use the object equivilents Integer, Float, etc.
• Calling from javascript comes from an unprivileged thread, so despite your applet’s policy, it may well be denied permissions. You can simply wrap such requests on the java-side with an AccessController.doPrivileged()
• Large applets can lock up the browser because the JVM and the jar are being loaded concurrently. This can be aleviated by splitting your applet into a smaller jar containing just the applet and interfaces, and the main jar containing the implementation. This way, the jvm and applet initialize quickly, and then do not block the browser when the second jar is downloaded.

This is a bit of a hack, but its probably the simplest way of passing structured data. What would be nice is a bit of code that would automagically serialize a bean to JSON notation… I’m sure there are many out there (This apache struts class looks promising)

These pages are rather helpful: Mozilla’s guide to using proxies and XulPlanet’s description of the nsIProxyObjectManager

This interface defines a proxy manager. An instance of this manager is used to create a proxy for a particular object on which you wish to invoke a method. If you are calling from any other thread that which you initialized xpcom on, you will need to do this, and as far as I am aware, there is no trivial way of doing otherwise.

Anyway, the code to open a new window would be as follows. Note, this method assumes that there is already a constructed object called windowWatcher, which is an instanceof nsIWindowWatcher, see previous post for details.

 public void openWindow(String chromeUri, String name) {
nsIEventQueueService eventQueueServive =
(nsIEventQueueService)serviceManager.getServiceByContractID(
"@mozilla.org/event-queue-service;1",
nsIEventQueueService.NS_IEVENTQUEUESERVICE_IID);

nsIEventQueue eventQueue = eventQueueServive.getSpecialEventQueue(
nsIEventQueueService.UI_THREAD_EVENT_QUEUE);

nsIProxyObjectManager proxy =
(nsIProxyObjectManager)componentManager.createInstanceByContractID(
"@mozilla.org/xpcomproxy;1",
null,
nsIProxyObjectManager.NS_IPROXYOBJECTMANAGER_IID);

nsIWindowWatcher windowProxy =
(nsIWindowWatcher)proxy.getProxyForObject(
eventQueue,
windowWatcher.NS_IWINDOWWATCHER_IID,
windowWatcher,
nsIProxyObjectManager.INVOKE_SYNC );

windowProxy.openWindow(null, chromeUri, name, "centerscreen", null);
} 

The code here uses the service manager to get an instance of the event queue manager, which is subsequently used to retreive the main UI event queue. This is then passed to the proxy manager’s getProxyForObject method, along with the IID of the nsIWindowWatcher interface, the actual instance, and flag representing the type of proxy operation (async, sync, etc, see the xulplanet page for more info).

This method returns an instance of nsIWindowWatcher, which is actually a proxy which will inject events onto the UI thread for you. Then, just use the object as normal, sweet!

We decided a while back to adopt an XML based protocol wherever possible, and moreover, RDF where appropriate. When communicating with a central server, this would use HTTP, so it seemed logical to use the same on the localhost. So, XUL uses AJAX, basically, to do asynchronous calls over HTTP to localhost, and retreives XML which is then passed into objects representing the returned resources. This way, we dont need to heavily integrate Java and XUL using XPCOM, and we allow other applications to be able to place nicely with the API over a well-known protocol and format. Anyway, this means that the only work JavaXPCOM needs to do is:

• Start XPCOM using a XULRunner installation
• Start an XUL window and pass control over to it
• Be able to call javascript/xul events from java (to open windows, etc)

So to start with, we need to find an XULRunner install. As it stands, we will distribute a version with the installer, but JavaXPCOM contains code to easily find installed versions as well (this is actually documented on the JavaXPCOM site).

1. Set the path the XULRunner directory, here we are doing it explicitly: File grePath = new File(new File(".").getAbsolutePath(), "platform/win32/xulrunner");
2. Next create an instance of the LocationProvider LocationProvider locProvider = new LocationProvider(grePath);
3. Initialize JavaXPCOM embedding: Mozilla.getInstance().initEmbedding(grePath, grePath, locProvider);
4. Now we need to start an XUL application, so we get an instance of the XPCOM service manager nsIServiceManager serviceManager = moz.getServiceManager();
5. Now we need to get the @mozilla.org/toolkit/app-startup;1 service: nsIAppStartup appStartup = (nsIAppStartup)serviceManager.getServiceByContractID("@mozilla.org/toolkit/app-startup;1", nsIAppStartup.NS_IAPPSTARTUP_IID);
6. Get the nsIWindowWatcher interface to the above nsIWindowCreator windowCreator = (nsIWindowCreator)appStartup.queryInterface(nsIWindowCreator.NS_IWINDOWCREATOR_IID);
7. Get the window watcher service nsIWindowWatcher windowWatcher = (nsIWindowWatcher)serviceManager.getServiceByContractID("@mozilla.org/embedcomp/window-watcher;1", nsIWindowWatcher.NS_IWINDOWWATCHER_IID);
8. Set the window creator (from step 6) windowWatcher.setWindowCreator(windowCreator);
9. Create the root XUL window: nsIDOMWindow win = windowWatcher.openWindow(null, "chrome://your-app/content/window.xul", "mywindow", "chrome,resizable,centerscreen", null);
10. Set this as the active window windowWatcher.setActiveWindow(win);
11. Hand over the application to xpcom/xul, this will block: appStartup.run();

Now, the LocationProvider is responsible for providing path(s) and file(s) that XPCOM needs. I have implemented a version that when the ‘ChromeML’ location is asked for returns an array of File’s, the first of which points to my own applications chrome folder, and the second of which is the xulrunner’s own chrome folder. This seems to work, but there are several issues:

1. I do not seem to be able to open XUL windows (or in anyway interact with xpcom/xul) from another thread. Since this run() method on nsIAppStartup blocks, this is a bit annoying. I presume there is a way to run this loop manually, or hook into it so we can queue up requests from other threads to be invoked on the xpcom thread.

Ok, thats only one major issue for now, but I’m sure I will think of others. If anyone has any ideas how these problems can be solved, or how one may circumvent them, I’m all ears. Also, I know that this area is so bleeding edge it hurts, so it would be nice to talk to some other people doing the same things!

I find that its great for high level stuff, but the common critisism is that performance can suck. I guess this is true since the language encourages you to not worry about the lower level implementation, but with a bit of careful tinkering, you can get java to process live video at 640x480x32 at about 30fps, and throw thousands of meta circles around at the same time for good measure. Although, that is, if you do not use Graphics2D, which is horrendously slow.

A good article on the different methods for rendering graphics, and the basis of pixel buffer rendering is [woops, lost this bookmark!] and here is another. I used the VXP package (broken, try the google cache) that wraps the QuickTime VDIG and JMF and presents a common PixelSource interface. Nice.

Given that, its just a matter of plugging it together to get per-pixel access to a live video stream (or indeed any video source supported by JMF or QT).

Unfortunately, I have been dragged kicking and screaming back to the world of “real” work and studying, so no more playing for me for a while.