Hudson CI game - again

Despite the impressively fast fix to the Hudson CI game issue with awarding points for breaking a build, I hadn't got around to installing the update before I broke the build yesterday and was awarded 12,800 points for doing so ;-)

We've fixed the build and upgraded to the fixed version. I'm keeping the points though, they're mine!

Using Java 6 Update 10 features in AltioLive

I've just posted an item on the Altio developer's blog about using the new features of Java 6 Update 10 in AltioLive applications. You can read the whole thing here:

http://tinyurl.com/42ntx2

The only issue at the moment is the fact that Altio dynamically constructs the APPLET tag, so we need to use a JSP page to generate a JNLP file dynamically. You can simply update the Altio JavaScript file and add in the new JNLP generator to start using cool new features in your AltioLive applications such as bigger heap sizes and separate JVMs per applet.

One thing that I didn't mention on the Altio blog is I that played around with accessing other domains directly from the applet, which I blogged about here.

I implemented this in Altio by allowing Image controls to fetch images from Flickr directly, rather then needing a Service Function to act as a proxy, and this worked well. It is probably a feature more useful in consumer internet applications rather than enterprise applications, but not being able to reference images from other websites directly has always been slightly frustrating, so it was a good thing to get working.

Cross-domain unsigned applets

Wow, I completely missed this in the Java 6 Update 10 release notes: it is now possible for unsigned Java applets to connect to servers other than the one it was served from, which means you can easily implement client-side mashups with an applet without having to sign it.

http://weblogs.java.net/blog/joshy/archive/2008/05/java_doodle_cro.html

The great thing about this is that it doesn't really break the sandbox security model, which still protects the user's local machine from any damage from malicious applet code, but it makes applets a whole lot more useful in the Web 2.0 world.

Rebranding

I've had the marketing people in, and they have assessed the synergy of the blog with a view to maximising my ability to incentivize visionary channels. Therefore, out goes 'disagreeable surprises' (which was a pain in the arse to keep typing) and in comes Peaky Blinder.

For those interested, it's the name of a gang that were infamous in Birmingham in the early 20th century. The story is that a lot of my Dad's side of the family were members, and they had a reputation as being pretty nasty. Officially the name comes from them wearing caps low over their eyes, but according to family stories it's actually related to the fact that they kept razor blades in the peaks of their caps, so when a fight kicked off they used their caps as weapons to try and slash their opponents' eyes. Yow!

So, that's my new brand ;-)

Hudson CI game - FAIL

We lost our CVS server for a while today, so Hudson jobs started failing because they couldn't check out the source. Fair enough. However, my attention was drawn to the line 'This build was worth 12730.0 points" line for the failed build, so when I looked at the details I saw this:

So, a failed build awards thousands of points for removing all of our checkstyle and findbug errors, and subtracts 10 points for breaking the build? Not exactly the behaviour I was expecting, and some people I know might see that as an incentive to check in and break the build :-) And what happens when you fix the build - does it subtract thousands of points for suddenly adding a load of errors?

Downsizing

One of our raffle prizes at JavaOne was a 4GB Asus Eee pc/umpc/laptop thing. We had a play around with it before we reluctantly gave it away, and it is quite a cool little toy - very small and light, but with a half-decent keyboard and wi-fi. The only bad points were the screen (very small) and the need to boot the thing into 'advanced mode' and perform some black-hat magic to get a Java plugin installed for Firefox. It really wasn't trivial, and was certainly beyond the scope of the couple of hours we had to play around with it.

So, obviously when I was back in the UK and discovered there was a new Asus Eee out with more storage and a bigger screen, then I had to go and have a look, and when I played with one in the shop and discovered that it had a Java plugin installed and ran the Altio website demos without any problems then I was sold.


The screenshot above is the AltioLive applet running in Firefox on the Asus.

Now, I bought the Linux version of the Asus Eee PC900, but I'm going to have to crap all over my geek credentials by admitting that I installed XP on it after a couple of days. The version of Linux on the Eee seemed fine, but a bit noddy and didn't support multi-user logins easily, so I decided to switch to XP.

There followed a long, long, long time playing around with nLite, which slipstreams Windows installations by allowing you to decide what components to keep and what to remove. After a lot of trial and error, messing about with booting off USB drives (which was made easier by helpful pages such as http://www.eeeguides.com/2007/11/installing-windows-xp-from-usb-thumb.html), and finally giving up and buying an external USB CD drive, I finally got it installed.

As long as you are fairly brutal with what is installed in XP, and keep an eye on the services and startup programs you have, it runs really well on the Eee, even with its wheezy processor. With XP, I get to use the new Java 6 Update 10 plugin on the Eee too, so I may even see if I can use it for development, although I think trying to run Eclipse on it might be stretching a point too far.

Applet to applet comunication

Of course, after a talk demonstrating Applet to JavaScriipt and Applet to Flash communication the first question I had after my JavaOne session completely stumped me: how can 2 Applets on the same page communicate with each other?

Here's the solution - use the getAppletContext() method on your Applet (or JApplet) to get the context (page) of your applet and then find all the other Applets on the same page:

Enumeration e = this.getAppletContext().getApplets();
while (e.hasMoreElements()) {
  Applet a = (Applet)e.nextElement();
  String name = a.getName();
  System.out.println("Found applet " + name);
}

Once you have a reference to an Applet instance then you can call any public method on it that you need to.

However, one of the new features in Java 6 Update 10 is to be able to specify that your Applet gets its own instance of the JVM. You can either do this explicitly with the following Applet parameter:

<param name="separate_jvm" value="true">

or your applet will get one by default if it asks for a non-standard heap size, or JNLP support.

If your applet gets its own JVM, then it will not see other Applets on the same page because they are not in its context any more - there is no longer a single global JVM context for the page, which is correct from a technical point of view, but will mean that there doesn't seem to be a reliable way to enable Applet to Applet communication without using something like JavaScript as a communication bridge between them.