Symphonious

Living in a state of accord.

Apple-Scented Coffee Beans are Accurate

So Apple have announced that they will be contributing large swaths of code to the OpenJDK project and that from Java 7 onwards, Java will be a separate download from Oracle, much like Flash is now a separate download from Adobe. This really shouldn’t be unexpected for anyone who was paying attention to what was going on rather than just running around thinking the sky was falling.

This is fantastic news for Java developers of all types. Mac Java developers have been asking for Java to be separated from the OS for many, many years so that multiple versions of Java are more manageable and especially to decouple Java releases from the OS release timeline.

Since the main JVM for OS X will now be open source, intrepid developers can dive in and fix issues they run into or at least dig into the code to understand it better and find work-arounds they can use. Apple has historically been quite innovative with it’s JVM port as well, bringing some great stuff to the JVM on OS X first1. It should now be easier to share those innovations across platforms which is great for all Java users.

It’s also nice to know that Java 6 will continue to be bundled with the OS in OS X 10.7 Lion. That gives a nice ramp-up for Apple and developers to transition to an optionally installed JVM and ensure things work smoothly either by applications bundling a JVM with the app or the installer or through auto-install methods for applets and webstart etc.

Finally, this should mean that JDK7 development on Mac will be done in the open, giving developers earlier and far greater access to try it out and report any issues back.

Seems like a huge win all round to me.

1 – for example the ability to share the core classes between JVM instances, but also a lot of stuff in how swing works and integrates with the OS

On the DVD vs in Software Update

James Turner gives a week in review and mentions the deprecated Java on OS X issue1. One thing to correct:

Deprecation basically means that neither package will be delivered as part of the installation DVDs, and updates will not come via the Apple update mechanisms. It doesn't mean they won't be available anymore, it just means you'll have to download them directly from Oracle and Adobe.

Firstly, there’s nothing to suggest that Java won’t come from Apple but not be part of the standard OS X package.

Secondly, just because something isn’t on the OS X install DVD doesn’t mean it’s not updated via Software Update. Aperture for example is a separately purchased product but updates come through Apple Software Update automatically. On Lion, software update is likely to open up further since it’s the obvious conduit to deliver updates for apps on the Mac App Store.

Of course, if the JVM winds up coming from Oracle, I wouldn’t hold your breath for updates via Software Update.

1 – I’m not sure how deprecated Java counts as lost in the hubbub of Back to the Mac, from where I’m sitting it looks a lot like the other way around but anyway.

Reading the Apple-Scented Coffee Beans

It’s interesting to see how many people are jumping to conclusions around the very carefully worded deprecation notice for Java in OS X. Read it carefully and pay careful attention to what it actually says:

As of the release of Java for Mac OS X 10.6 Update 3, the Java runtime ported by Apple and that ships with Mac OS X is deprecated. Developers should not rely on the Apple-supplied Java runtime being present in future versions of Mac OS X.

Most notably the note only refers to the Apple ported JVM that ships with OS X. This leaves the door open for an Apple ported JVM that ships as a separate download and for a non-Apple JVM that ships with OS X.

If you can drown out all the screaming and gnashing of teeth and pay attention to the Apple Java-Dev list you’d also notice:

  1. A huge amount of effort went into this release, especially setting things up to support multiple JVMs from multiple vendors. In the past, there was only one JVM available on an OS X install, it was upgraded with the OS and provided by Apple1.
  2. Even after this release, the Apple engineers who post to the list are still talking about their long term plans for the JVM (one example).

No one outside of Apple knows for sure what the future of Java on OS X is, and those inside who do know aren’t allowed to talk, but given the currently available evidence it seems at least as likely that Apple will continue to provide a JVM but as a separate download (or possibly just an optional install) as it is that they’ll abandon Java entirely.

Yes, there is a chance that Apple will just walk away from Java and leave a gaping void, but I don’t see indications that it’s a corporate strategy of Apple. Remember that Apple isn’t a company that sends a lot of mixed messages. They can turn a marketing message on a dime and they don’t pull punches. They’re also small enough and tightly managed enough that it’s rare for one part of the company to be off doing something that’s not inline with the company direction. If people are still building improvements to Java on OS X rather than moving to maintenance mode, that’s a strong signal that there is a future of some kind.

The real problem here is the same one that always happens with Apple – they’re not communicating their plans so developers can plan accordingly and not panic. But if you haven’t learnt to roll with the punches that approach delivers, you’re not a real Mac developer.

1 – A situation which caused most of the complaints on the java-dev list.

FireFox is Picky About Clipboard HTML, Java is Sloppy

Windows uses a particularly ugly format for putting HTML on the clipboard, called CF_HTML. Basically, it adds a header to the content with pretty useless information essentially declaring how many bytes in the header (and yes you have to pad the byte counts since they themselves are included in the count).

The problem between Java and Firefox is that Java always sets the ‘StartHTML’ and ‘EndHTML’ fields to -1 to indicate there is no context and Firefox will refuse to paste HTML from the clipboard if StartHTML or EndHTML is set to -1. As such, if you copy HTML from Java it will be impossible to paste into Firefox. It works perfectly with Word and IE.

I’m not 100% clear on whether the clipboard data Java is generating is valid but I consider it a bug in both Java and Firefox – Java for not being strict about what it outputs and Firefox for being too strict about what it accepts. Bug reports shall be made1.

On the Java side, the problem is in sun.awt.windows.WDataTrasferer.HTMLSupport.convertToHTMLFormat which sadly is Sun-specific, private and loaded from the bootclasspath so a little difficult to work around. There is however a nasty, but effective, hack from Peter Buettner which does indeed get around the problem. I’ve chosen to avoid the need to copy/paste HTML in this particular application but the approach is worth saving a reference to in case it’s needed later.

1Bug 598289 with Mozilla and there’s a simple test case available. The bug report has also been filed with Oracle and is now available in the bug parade.

Java AWT Robot and Windows Remote Desktop

Problem

If you’re attempting to use the Java AWT Robot to help automate tests, you may find it convenient to log in via remote desktop to watch the tests execute and verify they work well. You may also find that they work fine while you’re watching them but then inexplicably start failing whenever you aren’t. Basically your test is an angel from Dr Who.

What’s most likely happening is that when you disconnect from the remote desktop session, the console on the Windows box is left in a locked state and you need to enter the user password before you can resume interacting with programs on the main display. Since the AWT Robot is doing a very effective job of acting like a user, it also can’t interact with the programs you’re intending and instead is interacting, probably quite ineffectively, with the login dialog box.

Solution

It may be possible to get the AWT Robot to actually login before continuing, but then your tests would break when you were watching and it complicates the tests. Instead, you can take two approaches:

  1. Stop using remote desktop and switch to VNC which doesn’t lock the screen when you disconnect.
  2. Rather than disconnecting from remote desktop, transfer the session back to the console. Use Start->Run or a DOS prompt and run:
    tscon.exe 0 /dest:consol
    

Or of course just get up and walk over to the remote machine and watch the tests on the console directly, but that’s not always a viable option.