Symphonious

I've noticed something I've been doing with some consistency lately - when I come across a product that I have some interest in, but can't or don't want to start using straight away, I try to add the product page to my RSS feeds. With the proliferation of RSS support in browsers these days it seems to me that every product page should include a link tag pointing to the product updates feed. Ephox doesn't currently do this, but its something that we should fix pretty quickly to help people find the Releases Blog and stay up to date with all the latest features and fixes.

With a trip to the US coming up, I needed to set up a way to access my work email from my OS X laptop. Last time I went I just used Mail.app to access the Exchange server via IMAP and it worked ok, but obviously had no calendaring ability. This time round I really need the calendar to work as well so I fired up Entourage.

Going through the set up was a bit tedious and I thought it pretty dodgy that it wanted the Outlook Web Access (OWA) URL - obviously it goes via that instead of the normal exchange protocols. As it turns out though, that's the way that the Exchange server hosting company recommends you access your email. In fact, the instructions for setting up Outlook on Windows include a series of complex maneuvers to get it to use OWA too. Indeed, Entourage seems just as capable a client as Outlook at least form early impressions. The only thing I miss is the SpamBayes integration and that's not really a feature of Outlook.

Playing with Linux today, I fired up Evolution and it too supports going through OWA. Within moments it was pulling down my work email too. In fact, Evolution had by far the simplest process to set it up.

In all, I think the Exchange-Windows lock-in days are well and truly over.

Back in the days prior to OS X, I used to run Linux on the desktop (dual booting with OS 9) and used Window Maker. Since then I've used Linux a fair bit but only on servers - I have all the UNIXy goodness I need in OS X. I've just looked into setting up another Linux desktop system to see how viable it is and found that Window Maker still hasn't made it to a 1.0 release - in fact, it hasn't seen an update since 2005.

It's a bit of a shame, I guess Window Maker wasn't exactly a shining example of innovation considering it was a copy of the NeXt UI, but at least its aim in life wasn't to look like Windows. Looking at it now I don't expect that I'd actually want to use it (though running in VMWare really doesn't help perceptions) but I just don't see the point of running Gnome or KDE - they're like Windows but not as well done.

I mentioned the other day that I was having trouble with OutOfMemoryErrors being thrown when there shouldn't have been any references left around. We've done a fair bit more investigation into the cause of this and have wound up reporting a bug to Sun (still awaiting review so it's not in the public bug database yet). It turns out that you can cause OutOfMemoryErrors with an applet as simple as the one below if you just refresh the page a few times - but apparently only if you're using a dual-cpu or dual-core system.

import javax.swing.*;
public class TinyApplet extends JApplet {
    private byte[] data = new byte[Integer.MAX_VALUE / 100];
}

If however, you extends from Applet instead of JApplet, the OutOfMemoryErrors suddenly disappear. Tipped off by a comment in the source code for JApplet:

       /* Workaround for bug 4155072. The shared double buffer image
       * may hang on to a reference to this applet; unfortunately
       * Image.getGraphics() will continue to call JApplet.getForeground()
       * and getBackground() even after this applet has been destroyed.
       * So we ensure that these properties are non-null here.
       */

Bug 4155072 in turn explains that when using Component.createImage a reference to the Component is held so that the image can get the foreground and background colors. Sadly, Component.createImage is used to support double buffering in swing and so JApplets aren't correctly garbage collected. The bug seems to be a lot worse in Java 1.6 but bug 4155072 dates back to Java 1.2 and we've seen problems with Applet rention back to at least Java 1.3 but previously we'd believed it was the Sun plugin or the browser holding onto the applet.

Fortunately there's a simple work around, you just need to get the RepaintManager to discard the offscreen buffer. RepaintManager.setDoubleBufferingEnabled(false) doesn't actually let go of any existing buffers, but the code below does, while still preserving double buffering support in the applet so you don't see refresh flickering.

RepaintManager manager = RepaintManager.currentManager(theApplet);
Rectangle maxDoubleBufferSize = manager.getDoubleBufferMaximumSize();
manager.setDoubleBufferMaximumSize(new Dimension(-1, -1));
manager.setDoubleBufferMaximumSize(maxDoubleBufferSize);

By setting the maximum size to -1, every buffer in the RepaintManager is too big and gets flushed out, later we set the size back so that double buffering is still enabled. No more memory leak. Actually, still a memory leak. Not sure what's going on there - if you disable double buffering all together it goes away but for some reason setting the maximum double buffer size isn't clearing things out like it should.

UPDATE 2: Setting the maximum double buffer size doesn't work, but setting the current repaint manager to null seems to. I won't proclaim it as a fix quite so confidently this time until we've finished testing but it seems to solve the problem.

The most annoying part of this is that back in Java 1.2 Sun applied a work around for bug 4155072 and left the memory leak in there instead of actually fixing the underlying problem. On the plus side, I'll have the chance to hunt down the culprit in a couple of weeks at JavaOne.

It seems every time I do some work integrating EditLive! I find a new technique that makes it easier, simpler and more future proof. It's not so much inventing new patterns as finding creative ways to apply them.

For instance, tonight I wanted to get the upload manager in WordPress working with my EditLive! WordPress plugin. There's a whole bunch of logic and implementation detail in the JavaScript that WordPress outputs and it expects the editor to be TinyMCE. Fortunately, earlier on the plugin had drugged TinyMCE, taken it out back and shot it1, so it wasn't available. Fortunately, it's pretty straight forward to create an adapter for the TinyMCE runtime api that works with EditLive! and drop it in by assigning it to window.tinyMCE. Simple stuff and very similar to techniques I've used in other situations, but extremely powerful and easy to not think of. In fact, I'd tied into the autosave by manipulating JavaScript classes and all that became redundant now that I have the TinyMCE adapter.

This kind of thing has to be my favorite feature of dynamic languages - they make it so easy to mess with stuff and subvert the authors original intent.

1 - that's a surprisingly accurate description of the lengths you have to go to if you want to change the editor in WordPress and still have the "Use Visual Editor" preference work as users would expect.↩