Blog Without An Important Name

I’ve just put out eMusic/J 0.23. The main reason for getting this out there is that there is a bugfix for a problem that occurs in a certain (rare) circumstance.

Here’s a list of the changes:

• Allow multiple tracks to be selected This means you can shift-click or control-click to perform operations on multiple tracks. This is a prelude to drag-and-drop support, which I hope to get to some time soon.
• Adds auto-remove timer to tracks that were finished when the program started Previously, and tracks there when the program started were never cleared automatically. Now they are.
• Trim spaces from ends of album/track/artist names as vfat doesn’t like them
• Changed default save location of files to ~/Music or ~/My Music (whichever exists), defaulting to the first one if neither do This should make its default save location a bit nicer on various platforms.
• Fixed an infinite loop if the album/artist/track names contain a path wildcard (e.g. %t). Thanks to Hugh Brackett for spotting this one. This caused the program to peg the CPU on this album due to the track “S#%t Outta Luck”

It can be downloaded from the eMusic/J homepage.

An extra note, a customised version of this program was developed for Reggae Country to use with their download service. Thanks for their support!

They’re coming thick and fast now, I’ve just released a new version of eMusic/J.

Here are the changes:

• Added quotes around $@ in launch script to make it work better with some temp file names. If your browser stores files in a location with a space in the path, eMusic/J probably would have had issues opening them. Now it won’t.
• Changed default cover art name for windows and mac to ‘folder.jpg’. Works better on Mac and Windows, iTunes should automatically pick the cover art up now. It still saves as ‘cover.jpg’ on Linux because that seems to work well enough there.
• Cover art filename can be overridden by coverArtFilename option in prefs file. If the above doesn’t suit, you can change it by providing a name in the preferences file (~/.emusicj/emusicj.prop)
• Current download list saves when files are added, this means that the computer crashing won’t lose the current progress. Previously, the current download state was only saved when the program closed. However, if the computer crashed, the in-progress stuff was lost. Now, whenever you add files to download the list is saved, so the worst that’ll happen is that it’ll retry them.
• Added ” and & to the stripped out characters, they may be causing issues on some file systems. I’ve had reports of files repeatedly refusing to save. It may be caused by these characters, so they’re turned to ‘_’. Hopefully that deals with it.

Go here to get yours!

After a hiatus of about a year, I finally made a new release of eMusic/J. This was mostly caused by the change in the file format that eMusic provides for downloading albums. This version is (internally) quite different to the old one, as it is set up to make it easy to produce customised versions, so that one set of source code can produce both the downloader for Naxos’ Classicsonline service, and the regular eMusic/J.

The most important change in this is that it now supports both .emx files, as well as .emp files. It also now requires Java 1.5 (this is less of an issue now that Java is going properly open source), and is available for five platforms: Linux i686, Linux x86_64, Linux PPC, Windows (32-bit) and Mac OSX (Intel and PPC, but in one package). There were also numerous bugs fixed, mostly thanks to Naxos’s QA people, but nothing earth-shattering.

I also had the lead developer behind eMusic’s new download manager get in touch with me, and he provided me with some information that made this easier than it would have been otherwise, which was good.

Anyway, the new version can be found at the usual location.

Just recently, eMusic updated their download manager to one based on XULRunner, to the outcries of many people on the forums. So I took the work I did for Naxos a while back, and built Windows and Mac OSX versions of my formerly-Linux-only eMusic/J download manager. I’ve had feedback on the Windows version saying that it’s working great for people, which is good. I don’t have a Windows or Mac machine to test either of them on, so I wasn’t terribly confident.

Anyway, they can be found here:

• Windows version
• Mac version

I currently am doing some spare-time work for Naxos (the music label), customising my Java-based, open-source eMusic.com downloader, eMusic/J, to work with their Classicsonline download service. This means taking what was a Linux-only application and making it work on Windows and Mac OS X also. Getting the Linux version was obviously easy, I’d already done that; making a Windows version took a little more time, but most of that was learning how to make EXE files and installers (I’m using Launch4j and NSIS for that). However, making it work on Mac OS X was quite a trial, because this platform decides to do some things totally differently to the others.

The fundamental issue was an incompatibility between SWT, the GUI toolkit I’m using, and the Apple event system. Basically, to make SWT work you need to pass a special option to the JVM: StartOnMainThread. However, as soon as you do this, you lose the ability to catch events for things like “someone double-clicked one of my documents”. So I had the option of having a broken GUI, or no events. Neither of which is a possibility, as opening a particular file is the major purpose of this program. My theorising about what the actual issue is is in this message.

However, Azureus manages to do this, so I knew it was possible. With some help from the Azureus devs on IRC, and staring at undocumented code, I finally have a solution which I’m putting here in the hope that other people don’t spend hours of fruitless searching like I did.

It is possible, with some JNI hooks into the Carbon layer of OS X, to catch the events there and have them passed through to the application. Basically, you include this JNI code, create some callbacks using SWT, sacrifice a chicken and bleed a goat, and all of a sudden your code gets called when someone opens one of your files.

The code that I use is here. If you look at one of the ...Mac.java files, you can see the open doc handler being loaded, and inside that (OpenDocHandler.java), at the bottom of the target object, you have the bit that sends the files to the rest of the program. I don’t understand most of what it does, but it works. If I get around to it, I plan to refactor this and create a fairly stand-alone bit of code that means you can just register your own callback, and get the events without having to modify the handler. That would be pretty easy to do, I just didn’t want to touch it once I got it working. This method can probably be adapted to handle the other events, but I don’t need them so I stripped those parts out. Have a look in OSXAccess.java in the Azureus 2 code if you want to know how to do that.

Once you have this, and someone double-clicks a document type you have registered, you get told about it. Conveniently, you also get an event when your application is opened because someone opened your document.

Note: most of the code there is GPLed as I ripped it from Azureus (and eMusic/J is GPL too), but I think the actual C bit is probably something more liberal, as it was done by IBM and I expect they intend for it to be under something like the Apache licence. But I don’t know for sure, as the original file doesn’t have licence details.

So, hopefully very soon, Classicsonline will have a cross-platform, open-source download manager for its users.

I recently saw mention that Google had released Guice, their internal dependency injection framework. As an experiment, I ported a few parts of the web application I’m working on for work to use it. I’ve never used dependency injection before, and so it was a chance to learn about it too. The executive summary is that it works great. Previously I had a giant factory class handling all the instantiation of singletons (mostly which handle talking to the database), so I would do stuff like:
Configuration.getObjectRegistry().getNoticeHandler()
This worked well enough, but all the static references made testing hard, I couldn’t substitute in my own fake classes at all.

Now, for the classes that I’ve ported to use Guice, in my test case I can create a module that makes it load a bunch of fake classes to simulate what the real ones would do, so I only need to test the one class that I’m looking at. It also means I don’t have to set up database entries for everything that might get touched. I just add a line to the module like:
bind(INoticeHandler.class).to(FakeNoticeHandler.class).in(Scopes.SINGLETON);

The only gotcha I had was that I couldn't get it to inject into the servlet objects automatically. This is because you have no control over their instantiation, the application server handles that all itself. The solution to this is for the class that catches the application loading to store the Injector instance in the ServletContext, and have each servlet object load that and inject the dependencies into itself on init:

@Override
public void init(ServletConfig config) throws ServletException {
	super.init(config);
	ServletContext context = config.getServletContext();
	Injector injector = (Injector) context.getAttribute("injector");
	if (injector == null) {
		throw new UnavailableException("The Guice injector could not be " +
				"found in the ServletContext. It is expected to be named " +
				"'injector'.");
	}
	injector.injectMembers(this);
}

if every servlet extends the abstract class that contains this (and this extends HttpServlet), then it all magically just works.

Over time I plan to port the rest of the application to use this, but probably just as I’m working on those classes. In the documentation it says:

Dependency injection is viral. If you’re refactoring an existing code base with a lot of static methods, you may start to feel like you’re pulling a never-ending thread. This is a Good Thing. It means dependency injection is making your code more flexible and testable.

This is definitely the case, it would be easy to start and just keep following the thread of dependencies until the whole thing was done. However, I’m avoiding that now just due to a) being scared to refactor the whole damn thing at once, and b) I should be spending time on bug fixing and critical features right now. But, it probably won’t be too long before the whole thing is done, as a side-effect of testing.

All my transport for Linux.conf.au 2007 is booked, and there’s quite a comfortable holiday surrounding it all. I have yet to pay for the conference itself, but that’s because they’re having technical problems it seems. (Update: turns out the payment went through fine)

My itinerary is:

• 11/01: Christchurch -> Melbourne
• 14/01: Melbourne -> Sydney, Conference checkin
• 20/01: Conference checkout
• 24/01: Sydney -> Canberra
• 27/01: Canberra -> Brisbane
• 31/01: Brisbane -> Christchurch

Involved in this, are four plane flights with three different airlines, and a train ride from Sydney to Canberra. It should be fun.

There is a lot going on at the conference. I haven’t yet gone through that properly to see what I want to go to. If I’m lucky, I’ll manage to get a laptop for the duration, which will mean I can go to the tutorials (this one on GTK could be interesting, an alternative to using SWT in Java).

Aside from that, there’s a fair number of family and friends to visit in all the places. It seems that half the people I know have ended up in Sydney, and a sizable chunk of the rest scattered around a bit further away.

My credit card is just about smoking from all the money passing through it though…

A few days back I upgraded my machine to the newest Ubuntu release. As is often the case with upgrades like this, there were a few issues. The main one is a conflict between my M2N4-SLI motherboard and the 2.6.17 kernel. I get the impression that Asus has left quite a few bugs in the firmware, and if you boot straight up, it gets so far and then just locks up. My first solution was booting the kernel with the noapic parameter, and that works. However, I was also reminded of this comment that suggest using the enable_8254_timer parameter. I’ll try that next time I reboot.

One of the other problems I have is that Wyrd is completely, totally broken. A pity, because it’s really a nice tool. I suppose I could go back to using straight remind, and scripts that email me reminders. But I like wyrd.

The final thing that’s been annoying is that beagle (the search indexing program) is really prone to sucking up all CPU when it thinks you’re not looking. Originally, it used a lot of CPU indexing some files (including ones that it didn’t understand). I could live with that, it only had to do it once, however now when the computer has been idle for a while it starts up, not doing anything as far as I can tell. At least, nothing is being logged. This wouldn’t be a huge problem, but my computer’s fan only turns on when it’s under load. So if it’s on overnight doing something like downloading, it’ll be completely silent - until beagled starts up, and the computer makes a constant whine.

Oh, something else, but this is not at all a Ubuntu problem, it’s an example of why closed-source software is a pain to work with. What is it with Sun being so backwards about 64-bit machines? The third most requested enhancement is for a 64-bit version of webstart and the browser plugin. Apparently, 64-bit machines are all server machines (despite the fact that Sun sells 64-bit SPARC workstations), and so have no use for plugins and such. So they haven’t gotten around to releasing them, and it looks like they’re not going to be in Java 1.6 either. I’m fairly sure it couldn’t require much more than a recompile to make them work. Hopefully when Java is open sourced, the community will come out and produce these.

In the meantime, I’m living without a Java plugin (I don’t use applets heaps anyway), and OpenJNLP for webstart. It’s old, appears to be unmaintained, but it works. I’m thinking about writing a ‘loading’ screen for it though, currently it doesn’t have one.

Anyway, about Edgy: other than the problems, I haven’t noticed huge differences. Things are a bit newer, a bit nicer. KMail seems a bit less crashy. OpenOffice is finally proper 64-bit, not that I ever use it anyway. Oh, and the spellchecking in Firefox is good, too. I wouldn’t rush to upgrade if I didn’t care about using the most current stuff.

I’ve just put out an 0.20 release of eMusic/J. This fixes an issue that appears only on some JVMs (in this case, it seems to be Blackdown) where System.getenv(String) isn’t supported. However, it doesn’t fail gracefully, no…it throws an Error (not just an Exception even).

See these Sun bug reports for details. I think that in Java 1.5 they put it back in, and GCJ seems to handle it OK too, which is why I hadn’t noticed it in my testing. Good thing too, I think removing it to be a very short-sighted decision. It’s more ‘pure’, but so much less practical for real world things that I can’t believe they actually took it out at all.

Users of eMusic/J 0.19 don’t need to upgrade (and won’t be prompted to), nothing else has changed. This is just to help new users.

After several months of not getting around to it, I’ve finally put out a new version of eMusic/J. There aren’t a huge number of changes in this one, but there is one that will be significant for new users: it no longer requires Sun Java, any 1.4 Java environment will do the job. Thanks to Retroweaver, eMusic/J can be run in a completely Free Software environment. And, as a more practical benefit, no more jumping through hoops to get the right version of Java installed, and then recognised as default by the system. I’ve tested it on GCJ 4.1 (which comes with Ubuntu) and there was no noticable difference.

I hope that this gets me closer to being able to do a native build, and have it run without a Java runtime at all. However, despite running it just fine, GCJ is unable to compile it (even compiling the bytecode - the source is still 1.5, which I expect it to choke on anyway). If anyone has experience with this kind of thing, please let me know!

Here’s the changelog:

• Added ‘User Manual’ option in help menu, which opens a browser (by
  default Firefox, this can be changed by using the ‘undocumented’
  browserCommand option in the prefs file.) - this should have been there some time ago, but I kept putting it off, planning to try using JDIC to do it. However, JDIC doesn’t provide a 64-bit build, and I don’t yet have one of those machines myself to build it on. So I did it by hand.
• The update dialogue now offers to open a browser to the application homepage - as above
• Updated SWT to stable 3.2 build - a recent SuSE update has killed SWT for a few people. Hopefully this fixes it. Unfortunately, I can’t test it.
• Added option to automatically remove completed downloads from the downloads list. This happens 30 seconds after it finishes. - I don’t see much point keeping a list of completed downloads at the top of the screen, you’re normally just interested in the ones that have finished. So now, completed ones go away after 30 seconds (this can be turned off)
• Builds now use retroweaver to gain JDK1.4 compatibility. This means it works with GCJ, and probably other open JREs. - probably the most important change, but the one that current users will (hopefully) notice the least

Don’t delay! Go get yours today!