NetBeans 6.1: The Best just got Better

When it comes to IDEs, I've been around. I've used Visual C++ since version 1.5. Tried other environments over the years, but Visual Studio was by far the best no matter what other people claimed.

I started using Eclipse since that's what everyone around me was using for some Java work and I hated it. I'll reserve my thoughts on that for a future blog post but it was never a comfortable fit for me. Needless to say, I've converted my entourage from Eclipse to NetBeans now.

Version 5.5.1 of NetBeans was pretty good but the editor kept, well, I'm not quite sure on how to describe this, but it kept being wrong... or feeling wrong at least. Not sure if that makes any sense but that's the best I've got to offer.

NetBeans 6 was simply fantastic. It was just great. Probably one of the best IDEs I've ever used. That being said, it had a few shortcomings that were really annoying. On huge files, code completion was somewhat slow. Not that slow, but code completion is one of those features where you must literally work at the speed of thought of the developer. Otherwise, you break the flow of the developer. Startup time was annoying but manageable.

NetBeans 6.1 has really been great for me, so great that I've ditched 6 for the 6.1 beta. They are several reasons for this. First, it seems to me like this thing has had a lot more debugging time than a fully patched 6.0.1 release has. So it just works even if it's just a beta. That being said, a small caveat here is that I shun JavaScript work in favor of GWT. So I don't know how the rewrite has impacted that editor.

However, it's the little things that make the difference. For example, my favorite new feature by far is the default location of the Glassfish domain. Silly? Maybe, but I use Vista across the board. It has always been considered impolite under Windows to write to "Program Files" after installation has completed. Starting with Vista however, that folder has now been locked down. Meaning that with NetBeans 6, the default developer domain lived under "Program Files\Glassfish\domains\domain0". Under Vista, you had to either unregister your Glassfish server from the IDE and re-register it again with a more polite location, or you had to go into the Glassfish folder in "Program Files" and grant yourself write privileges to the domain's folder in order to support all scenarios. NetBeans 6.1 under Vista, and hopefully under any other Windows version too, creates the default domain inside your home directory. I think I almost cried when I saw that.

That being said, as much as I love this IDE now, ending a 14 year old run on Visual Studio/C++, I still have my pet peeves. In no particular order:

• it's still slow to startup even it's a lot faster than it used to be.
• I hate the fact that they are no project grouping feature similar to the solution concept in Visual Studio. NetBeans does actually have a project group feature but I just hate it. I hate it because it doesn't live on the file system, hence I can't commit it to source control. This means sharing project groups between team members is really annoying. I hate it because it clutters up the UI. The idea of a master project I find is also broken. Simply because you don't know right off the bat which of the project in a hierarchy is the master. I'm hoping that full support for Maven in NetBeans 7 will take care of this.
• I use this IDE for pretty much everything now except for Windows Mobile and Android development. Which means I use it for C++ too. I don't use C++ that much anymore but it does come in handy. It works really well under Windows with cygwin, I even have Microsoft's Platform SDK hooked into this thing. Again, works pretty well. That being said, g++ is the only supported compiler under Windows. Considering the Visual C++ compilers ship with the Platform SDK now, I would like to be able to just use those instead of g++.
• I would like to be able to run multiple instances of the IDE at the same time. The scenario here is when I want to debug both the client and server end of an application at the same time.
• Better GWT support. Matisse is great but with all these new languages and toolkits like JRuby, Groovy and GWT coming into the Java ecosystem now, isn't it about time this thing started to learn new tricks? Look at SharpDevelop for instance. It has a visual form designer for all the languages it supports.
  
• Message queues in the services tab. I really like the services tab. I really like the fact that databases are showing up there too now with this release. The Java DB menu item looked out of place in the tools menu in 6. Support for stand alone instances of JMS brokers would be a welcomed addition. I use Glassfish a lot, but I also use ActiveMQ outside of any Java EE container a lot too. Why? Because of the additional interoperability features it provides. Very handy to have around. And yes, before anyone comments on this, I know about the STOMP adapter from CodeHaus could probably be installed on OpenMQ.
• Support for Groovy, Groovy and Groovy.
  
• Lastly, I would like to see a Geronimo server plugin. Yeah, I know this a weird one considering I'm all Glassfish. However, I have one project where Geronimo was the best compromise I could reach. Maybe this is selfish but in my defense, I would probably have started coding this if it hadn't been for this thread here.

All in all, I'm pretty happy. I won't be switching back to Visual Studio anytime soon. The only real problem I have with NetBeans is that since everything is in the open and announced upfront, I find I'm always eager to get my hands on the next release, never truly satisfied with the current one. I would imagine however that's a good problem for NetBeans to have.

TopLink Lives

It was my hope that the union of BEA and Oracle would lead to the enventual demise of TopLink in favor of KODO(Apache OpenJPA). Obviously, Oracle being and enterprise player, any phase out plan would be over many, many years. For example, I think Oracle will move their customers to the vastly superior WebLogic over their own Java EE offering but will still probably continue to offer and develop OC4J for many years to come. However, when it comes to a Java EE server, they are many parts. Each part could conceivably be marketed and sold individually.

Of course, things were never that simple. The core of TopLink, TopLink Essentials, is the JPA version 1 reference implementation, is open source and ships with Sun's Glassfish server which also happens to be the Java EE 5 reference implementation.

Futhermore, Oracle donated not just Essentials but the full TopLink product a while back to the Eclipse foundation under, curiously enough, under a different, Eclipse compatible, license.

Today comes the announcement that TopLink Essentials is indeed being phased out but TopLink is moving up in the world. The full TopLink, the one donated to Eclipse, is now EclipseLink. EclipseLink has been chosen as the JPA version 2 reference implementation and will ship with the next version of Glassfish, also know as the Java EE 6 reference implementation.

All in all, this is good news nonetheless. The double donations, under different licenses no less, being consolidated in one code base is certainly less confusing. The Eclipse license, from EclipseLink, is also more permissive than the CDDL/GPL from TopLink Essentials. In fact, so permissive that the Apache Software Foundation considers it just fine too. For example, the Java compiler from Apache Harmony is actually the Eclipse Java compiler.

Now, if we can just get comprehensible error messsages from future releases, all should be good. That being said, I've been using TopLink Essentials more and more, and after a while, you get into this weird Zen state and actually start to recognize and understand the error messages. When you do, it actually works pretty well. That being said, I still think those error messages are nuts.

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 =
   Channels.newChannel(response.getOutputStream());

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
fc.close();

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?

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.

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.

The magic of the tablet

This blog post is special, it was all written by hand. That is, it was written using a Tablet PC running under Vista.

You know, people all around me are always complaining about how bad my penmanship is, but this thing is pretty good at figuring out the words that I'm writing.

So kudos to Microsoft how figuring out my bad writing. That being said, there's one slight problem. You know those toolkits that have custom widgets that do their own drawing? For example, Qt, Java swing and Mozilla based products to name a few, well, they don't work.

The problem is that the handwriting controls are tied to the native window class. So, if you have a window that has a native class of "text box", then Windows knows to pop up the handwriting widget button. When doing custom painting with widgets, the native Win32 class for all windows is, well, "window". So Windows can't tell that it's supposed to put up the handwriting pop up.

Too bad, Sun is really trying to position Java for rich client Internet apps. Is this important? Maybe, maybe not, but this is definitely something that the .Net Framework can do. Sun now has a lot of people working in Redmond to make Java run on Windows better. Well, this is one item that they can put on their todo list.

No More Heroes

This blog is usually about technology but every once in a while, a game pisses me off and I write bad things about it here, i.e., Resident Evil: The Umbrella Chronicles.

Even more rarely, I get to experience a real gem and it does take quite a lot for me to actually write something about it. After all, a lot of good games came out in 2007 and I didn't bother to write anything about the majority, if not all, of them.

No More Heroes, just released exclusively for the Wii, is such a gem. Do yourself a favor gamers, pick up a copy. You can see a video review here.

Use Eggs to Defeat the Final Boss in RE4 Wii Edition

Oracle Buys BEA

If you haven't heard by now, Oracle has just acquired BEA for a lot of money. Here's what I'm hoping will come out of the deal, or at least some predictions:

• TopLink dies a horrible death replaced by KODO.
• TopLink Essentials dies a horrible death replaced by KODO core (Apache OpenJPA).
• Oracle OC4J still doesn't do Java EE 5, it's still stuck on Java EE 1.4. It has almost no market share and BEA WebLogic has something like a 33% market share of application servers. Not sure what will happen here...
• JRockit will hopefully die a not so horrible death. JRockit is a full Java SE implementation but it's actually licensed from Sun with some custom patches applied that apparently improve performance. Enough already, if those custom enhancements are really worthwhile, just contribute them to the OpenJDK project already and move on.
• IDEs? Don't know what will happen there, both companies have their own Java IDE which have both failed to gain any significant momentum. To me, 0 + 0 is still 0. Here, please note that I am talking about market share and not the quality of these products

KODO was acquired by BEA which donated the core bits to Apache which formed the OpenJPA project. OpenJPA is now used by WebSphere, Geronimo and WebLogic. Having OpenJPA standard in Glassfish would be nice but even if Oracle decides to move forward with KODO, it still doesn't mean Sun would decide to dump the TopLink Essentials code that Oracle contributed to Glassfish. Well, here's hoping, see my previous blog post on TopLink Essentials on why I think this matters.