Tuesday, February 26, 2008

I'm Tired of Closing Files

Not long ago, color commentator Bruce Eckel shocked the Java world with his article entitled: "Java: Evolutionary Dead End".

The press went wild stating that Java was doomed since one of its biggest supporters was now shunning it. If you actually read the article, this doesn't call for the end of Java, just slowing down or completely stopping the adoption of new features to the language akin to what C and C++ are today. C and C++ are governed by slow ISO committees that make a new language specification every ten years or so. Instead, he argues, hit the reset button and make a new language on top of the JVM. Certainly, the JVM is no longer a stranger to non-Java languages, both Groovy and JRuby seem to be carving a niche for themselves.

Furthermore, the Java virtual machine, at least the one from Sun, is constantly improving both in terms of speed and memory consumption. The version 6 virtual machine of HotSpot from Sun is nothing short of spectacular. New language, same great infrastructure, sounds perfectly reasonable doesn't it?

Now, why would he choose such a tittle? I'm familiar enough with this author, I probably still have the 1st edition of Thinking in C++ somewhere, to know that it was probably on purpose. He knew the
attention he would get with this kind of title than with one that more accurately portrayed the contents of his article. Nonetheless, it made a lot of people think about the core issue, should Java be frozen or not?

I've been thinking about that lately and I've come to the conclusion that I'm tired of closing files or any other type of resources for that matter. I think it's reasonable to freeze Java (the language)
but only after it has indeed reached adulthood. You can talk about Java 7's closures, asynchronous I/O and super packages all you want but it doesn't change the fact that I'm still sick of closing files.

With a garbage collector present, it is no longer clear when the destructor/finalizer of a class will execute. If I were to write a program that operates on files, I would have to manually close any file object created or risk running out of file descriptors depending on the operating system I am running on. The same can be said for any object that holds kernel level resources. Coming from C++, this is something I no longer needed to care about, why should I care about it in Java?

C# does something interesting here, any object that implements the IDisposable interface can be used inside a "using" statement. This means that at the end of the "using" block, the dispose method is automatically called. Something like this:

using System;
using System.IO;

class Program {
static void Main(string[] args) {
using (Stream stream = File.Open("foo", FileMode.Open)) {
// Operate on stream to foo
The problem I have with that is that it's still bound to one variable per "using" block. So, to copy a file to another, I need at least two "using" blocks.

In C++, the resource initialization is acquisition idiom is increasingly popular, made even more popular by the use of smart pointers, so assuming the use of shared_ptr here:
if (shared_ptr<x> p = someManager.get(id)) {
// operate on p
} else {
// p is also not in scope here
// p is no longer visible

All this to say, that the equivalent construct is missing in Java. Not only, but I don't like the C# solution as it's possible to go further.

If you have multiple "using" (or "if") blocks, why can't we just make a list? In other words, if I can acquire this list of resources, then execute the block otherwise don't? For example:
// Fake Java code sample
using (FileChannel r = new FileInputStream(path).getChannel(),
WritableByteChannel w =
Channels.newChannel(response.getOutputStream())) {

r.transferTo(0, length, w);
} finally {
// handle failure
Instead, I have to do something like:
// might throw
FileChannel fc = new FileInputStream(file).getChannel();
WritableByteChannel w =

if (w != null)
fc.transferTo(0, file.length(), w);

// null or not, w is still in scope
// Don't really have to close, but waiting for GC might be fatal later on
I write a lot of Java code now and I'm really enjoying it, I wouldn't go back to C++ at this point. C++ is only the last resort language now, the language that makes things work if it doesn't anywhere else. So, when I hear things about freezing Java, I think about things like this. I wonder how much time Mr. Eckel spends writing code versus teaching it. As an educator, I can understand the importance of a non-moving target, but in the field, I need relief for some common idioms. Saying let's do a new language won't make all the tooling that's available today for Java suddenly appear on that language. For example, I really like Groovy but I don't use it. The IDE support in NetBeans just isn't good enough for me to work with it.

BDJ Revisited

My last blog entry talked about Blu-Ray Java a.k.a. BDJ. Hanging out in the groups however, not all is well in the land of BDJ.

The first problem is fragmentation. BDJ is really young and the fact that fragmentation is already a problem is something I find completely unacceptable. Fragmentation means that either the reliability or availability of the code that ships with the device varies enough that you have to change your application code to work around bugs or missing features. In layman's term, it means you need to ship different SKUs and that costs money. Money to package, money to validate and money to distribute. Java ME fragmentation has really gotten out of control these last few years. The Transformers movie tie-in game is one of the biggest Java ME project ever undertaken. In all, some 25,000 SKUs shipped in order to support all the phones out there. Yes, that's 25,000, twenty five thousand SKUs. I can only imagine what the cost of getting that game to run on all these handsets was. No horror story of this magnitude in the land of BDJ yet, however the "Chicken Little" movie application apparently had 30 different variants in order to run.

Not all is lost however. Unlike Java ME (CLDC or CDC variants) on phones. The Java ME/CDC stack that is shipped with BDJ is upgradeable. If your device is networked, it can phone home and check for upgrades. If your player isn't networked, upgrades can still ship with a movie disk. I'm not sure what the experience is for the end user considering most users won't even understand what this is upgrading in the first place but let's hope it's very transparent.

For the moment anyway, this needs to be dealt with. Content authors are overwhelmingly choosing HDMV for their content over BDJ. Only 30 of the 600 or so Blu-Ray movies that have shipped, i.e., roughly 5%, use BDJ.

It could be just familiarity with HDMV since these authors have been using it for quite some time on regular non-HD disks, or could it be the complete lack of tools? This being the second problem. I've blogged before about JavaFX. JavaFX is many things, but what it really is a codeword to right all the past wrongs of Java on the client. So, even if we haven't seen any JavaFX authoring tools for designers, Sun has confirmed that it's working on components for Adobe products to output JavaFX scripts. Now that could be something that is enticing for content authors. The HDMV tools don't even come close to the Adobe design tools.

Finally, my last gripe is why did anyone even bother with Java ME in the first place for these devices? For crying out loud, these devices can decode and output 1080p video. I think they can handle the full Java SE platform. Considering that Sun has announced their intention to eventually phase out Java ME over the next decade to converge with Java SE, did they really have to add another few hundred million devices as part of that phase out plan?

Tuesday, February 19, 2008

HD-DVD is Dead. Where's the SDK for BDJ again?

So, it finally hit the fan. Toshiba has ended its HD-DVD business. This obviously impacts consumers since most people have wisely decided to stay away from this market until one format won out against the other.

What consumers don't know about these mortal enemies is that this war was being fought on two fronts. The other front being software, mainly codecs and platforms. Unbeknownst to the regular DVD Joe and Sally, all Blu-Ray players are shipped with Java ME.

Considering the horror that is Java ME on phones, you'll be happy to know that the Java ME that ships on Blu-Ray devices is the CDC profile. The CDC profile has considerably more features than the CLDC one that usually ships on phones but still falls short of .Net Compact and Java SE. Unfortunately, the CDC still has many optional packages too which means that fragmentation card is still in the deck. I'm not sure anymore if .Net Compact was shipping on HD-DVD players, information on the subject is very scarce but my belief is that it was. I know for a fact that .Net Compact ships on the X-box 360.

Officially, the Java that ships on Blu-Ray is called BDJ and they are basically two profiles, one that offers networking and the other one does not. So, for example, the Java that ships with the PS3 is BDJ with networking. Well, all these features are basically meant to offer a richer interactive experience on BR disks. However, with the rise of casual gaming and the presence of USB ports on most of these devices, I wouldn't be too surprised if some games started coming down the pipe using this technology. The problem so far has been about getting an SDK. In other words, BDJ has not been widely available since the movie studios aren't sure if they want developers writing code for these devices. The fear is that these SDKs will be used for cracking the copy protection of disks.

Well, I don't know if this coincidental or not, but we are finally starting to see BDJ related bits being made publicly available. You can see a introduction to BDJ from its main architect here. The HD cookbook project is also available from java.net.

So what does this all mean for consumers and developers? Well, if you bought an HD-DVD drive, welcome to the world of betamax. If you bought a Blu-Ray player, congratulations, you'll be able to get content for many years to come. For the Java developer, it means yet another way to leverage your existing skill set. With potentially hundreds of millions of Blu-Ray players that will be sold in the next few years, you have yet another avenue to market applications. For the .Net Compact developer, you still have a small, but sturdy niche of Windows CE based smart phones that you can still code for but that's about it.

Sunday, February 17, 2008

No More Heroes Again

I just finished the game. This is what fun is all about. In any case, I want a sequel. So go buy it. If you don't own a Wii, there's never been a better excuse.

In any case, if you have played the game and are wondering what Jeane was talking about at the end, it's available from YouTube. No wonder it was fast forwarded in the game, that "M" rating would have turned to an "AO" one real easy. If you haven't played it yet, don't watch it, it spoils pretty much the ending.