Simon Brown's Blog

J2SE Archives

J2SE 5.0 updates

This blog entry should really be titled, "J2SE 5.0 updates, or the lack of them". I've read Graham's blog entry about J2SE 5.0 updates a couple of times now and I still don't understand why you wouldn't want to push out minor updates via the consumer java.com website. The end result of this is that J2SE 5.0 Update 2 is available from java.com, while Update 3 is available from the java.sun.com website.

I can see why this may be simpler for end-users, but not for anybody else. Think about it. You're supporting an application and a user encounters a bug that you don't see on your computer with the JDK installed. A response of "make sure your JRE is up-to-date" just isn't going to cut it anymore. As far as the end-user is concerned, their JRE is up-to-date. Unfortunately we know better. Of course, we could point them at the java.sun.com website, but then that defeats the purpose of the user-friendly java.com website.

Anyway, putting the inconsistency issues between java.sun.com and java.com to one side (there are a lot of very good responses to Graham's blog entry), what happens when Apple starts delivering J2SE 5.0 through the Mac OS X Software Update channel? This is the primary mechanism to ensure that end-users (and developers!) have the most up-to-date version of the Java runtime. If Apple make Update 3 available via Software Update, for once, Mac users will have a more up-to-date version of the runtime than those running Windows! Well, until Mustang is released anyway.

I just don't get it. The Java runtime version numbering is confusing enough as it is. Take a look at the java.com website, even that refers to "JRE 1.5.0" rather than "J2SE 5.0". Complicate matters further by not ensuring that everybody is in step and we've got a real problem on our hands. No wonder Java is struggling to gain ground on the desktop. Sun, please revisit this decision and let us have the same version of "Java everywhere".

Collections.unmodifiableX()

I just got bitten by the collections framework. I always thought that the Collections.unmodifiableX() methods returned an unmodifiable copy of the supplied collection, like a shallow copy. This is useful for getter methods where you want to return a copy of a collection to a client class so they can't directly alter the contents of that collection. This enforces encapsulation and ensures that clients use the methods that you have specified to manipulate your data.

But the Collections.unmodifiableX() methods don't work like that. Instead, they present an unmodifiable view of the specified collection. If you modify the underlying collection, this shows up in the unmodifiable view too. I won't be making that mistake again. To make a shallow copy of a collection, you can either use the clone() methods on the collection implementation classes or construct a new list/set/map, passing the original collection as an argument to the constructor.

It pays to read the javadocs, but without a unit test I would have spent even longer hunting this problem down.

Reasons to use Eclipse and SWT?

I popped down to the JSIG today, the topic of which was Eclipse. Unfortunately I had a 2pm meeting so could only stay for the first presentation by Berthold Daum (author of Eclipse for Java Developers) which was an overview of Eclipse, SWT and plugin development.

The first part of the session took a look at Eclipse itself, and Berthold gave a good overview of the tool, the workbench, the various views, perspectives and so on. Following on from this was a look at some of the features that Eclipse provides including things like code completion, code assist, refactoring, etc. Overall this was technically a good presentation although it didn't leave me wanting to download the tool and give it another try. If you've been following my blog, you'll know I'm a big fan of IntelliJ IDEA and I have a personal license to prove it. In terms of the content covered in the presentation, feature for feature there's nothing new that I can't do with IDEA. Apart from the obvious advantage (i.e. price), why should I switch to Eclipse?

The next part of the presentation looked at SWT - the Swing alternative that Eclipse uses and that we (as developers) can use to build our own desktop applications. Again, this was a good presentation that covered topics ranging from the SWT architecture to the various widgets it provides. For me, the interesting part of the presentation was the summary of the pros/cons for using SWT. Advantages quoted include richer (native) widgets and integration, more stable and more responsive than Swing. Disadvantages quoted include SWT only runs on a limited number of platforms, widgets (can) have different behaviour on different platforms and deployment is an issue because of the native code. So, to summarise my understanding, SWT takes all the things that Java tries to achieve (platform independence, compatibility, etc) and throws them out of the window for something that is perceived to be faster, richer and more stable than Swing? I think I need some more convincing, particularly with the advances that J2SE 1.4.2 has provided in this area.

Just as a last point, there was a quick poll done about how many people have used Eclipse and, unsurprisingly, about half of the audience (about 40 people) raised their hands. Whether you like it or not, Eclipse is gaining a large "market" share. There's been a lot of discussion about Eclipse/SWT, but why should developers make the switch to either of these two tools?

Panther ships with Ant, XDoclet and JBoss

I've just installed Panther and since you don't get stuff like CVS installed by default, I decided to open up the XCode CD and install the developer tools. To my surprise there are some Java tools tucked away including Ant, XDoclet, log4j and JBoss. If you install the Java tools, they can be found in :

• Ant 1.5.3, XDoclet 1.2b and log4j 1.2.8 in /Developer/Java/J2EE
• JBoss 3.2.2 (RC2) in /Library/JBoss/3.2

In Apple's inevitable way, running JBoss is as simple as navigating to the bin directory of the JBoss installation and running the run.sh script. No need to even set up environment variables such as JAVA_HOME. Okay, getting JBoss running on any platform is easy, but you have to admire Apple for making it even easier.

I knew that the server editions of Panther were going to include JBoss, but not the normal editions. Of course, you can already get newer versions of the tools yourself, but it's nice to see Apple making this stuff available and pushing Java as one of their development platforms. It just enables people to get up and running quickly, meaning that they can concentrate on learning how to develop applications rather than setting up tools. I wonder if we can convince Microsoft to include J2SE and Tomcat in the next edition of their OS? ;-)

HttpClient - another great Jakarta Commons component

I was putting TrackBack support into Pebble the other day and the found that the technical details of a TrackBack involve sending a HTTP POST request to the remote server. I've implemented HTTP POSTs before using the classes in the java.net package, but rather than write all this code again, I thought that I'd take a look at Jakarta Commons HttpClient. What can I say ... this is another top notch component from the Commons project.

The following code shows how easy it is to make a HTTP POST with some name=value pairs and get the results back as a string.

      HttpClient httpClient = new HttpClient();
      PostMethod postMethod = new PostMethod(url);
      NameValuePair[] data = {
        new NameValuePair("name1", value1),
        new NameValuePair("namen", valuen)
      };
      postMethod.setRequestBody(data);
      int responseCode = httpClient.executeMethod(postMethod);
      String responseBody = postMethod.getResponseBodyAsString();

As you can see, there's not much code here at all, and HTTP GETs are easier still! From start to finish, making use of this component took about five, maybe ten, minutes. If you find you need to access HTTP-based resources, take a look at HttpClient.

Casting affects performance?

One of the only websites that I can access from the client site that I'm on is the IBM site, and I must admit that it's not on my list of Java related sites that I regularly visit. So, scanning through some of the forums I came across this thread about the overhead of performing object casting in Java. Interesting, and something that I've never really thought about before. I can certainly see how running all the various checks at runtime can introduce some overhead but I imagine that it's still fairly tiny. I've not read the book that's mentioned (Java Performance Tuning) but perhaps I might look it up now. Hmmm ... interesting.

Java Rules!

There's been some interesting activity in the Bunkhouse Porch recently. Douglas Dunn has just released the 2nd volume of his Mastering The Fundamentals of the Java Programming Language ... for free! His first book, Java Rules was rated very highly and apparently this is even better.

I said the same thing yesterday about Mac OS X for Java Geeks - this is not your normal Java book. Instead, think of it as a commentary of the Java Language Specification. It basically delves into an amazing amount of detail about various features of the Java programming language by looking at and questioning how things work in the way that they do. For example, it looks at topics such as whether interfaces extend the Object class, and there's a whole section on how exceptions work underneath the covers.

This certainly isn't a book for the fainthearted, but if you’re up against some weird JVM bug or just want to delve deeper into the inner workings without reading the Java spec, then take a look. The 4Mb PDF file is available to download from http://www.javarules.com.

Review of Mac OS X for Java Geeks (O'Reilly)

I've just reviewed this book for the JavaRanch Bunkhouse and thought that I would share it via my blog...

I’ve had a PowerBook for about three months now and I thought that I had Java on Mac OS X figured out. How wrong could I be! First of all, it’s worth pointing out that Mac OS X for Java Geeks by Will Iverson is not your normal Java book. It doesn’t teach you how to use Java, and it doesn’t teach you how to use Mac OS X either. Instead, it takes you on a tour of what’s available for us Java developers on the Mac OS X platform, looking at topics that pull together to make Java development an easier and richer experience.

First up is a look at Apple’s implementation of J2SE and how configuration of the Java environment differs slightly from other platforms. This is certainly something that does confuse most Java on Mac newbies (myself included) and it’s great to see an explanation of how this all works. Next is a discussion of a selection of tools that are useful to Java developers, including all the usual text editors, IDEs, open source projects and even some tools that are bundled with OSX that you might not have found. Again, all very useful stuff, particularly with Mac OS X specific tips thrown in here and there.

Now we get to the interesting stuff by stepping up a gear and looking at the development of desktop applications for Mac. Apple’s JVM includes an implementation of the native Aqua look and feel for Swing, meaning that you can write applications in Java that look native. Here, we’re treated to a fascinating discussion on some of the usability issues and gotchas associated with cross-platform GUI development. With this in mind, the book then goes on to look at some of the Apple specific features and extensions that we can take advantage of in our applications, along with some strategies to help ensure that our Java applications are still cross-platform compatible. This includes integration with things like the Finder and Dock, and we also find out that it is possible to package up Java applications in the same way as native applications, rather than delivering an executable JAR file. After all, one of the key mantras behind Mac OS X is the richness of the user experience.

Moving on, and if that’s not enough, the book delves into some of the Java APIs that Apple provides if you are targeting Mac as your deployment platform, including a look at the Speech, Spelling and QuickTime APIs. The functionality provided by these APIs is amazing, although the actual APIs themselves are incredibly simple. The coverage of the APIs is well balanced. There’s just enough to whet your appetite while still providing a good overview of how to use them.

Finally, the book moves on to look at how to use some of the more mainstream development tools such as MySQL, Tomcat, JBoss and web services. Again, there’s a lot of useful information in here although it’s not as Mac OS X focussed as the rest of the book, instead providing a simple instructional approach to getting something simple coded and running. Sure, there are some Mac specific hints in here, but these sections seem to be aimed at developers who are new to these technologies.

Overall this is a great book, and the use of a simple yet very complete example throughout the book makes it very easy to read and follow exactly what’s going on. My only real criticisms would be that the last few chapters are focussed more on using the technologies (e.g. building your first JSP-based web application) and it might have been good to see a section that talked about J2ME development on OSX, just for completeness. In summary, if you’re an existing Java developer and have recently moved over to the Mac, I strongly recommend this book. I only wish I had found it sooner!

Building desktop clients for Mac OS X with Swing

I'm currently reading (and reviewing for JavaRanch) Mac OS X for Java Geeks by Will Iverson and I'm surprised at how good the integration between the core Java platform and Mac OS X really is. Okay, I knew that Apple ships JDK 1.3 and 1.4 along with OSX, but I never realised that you could build a Java application and package it up to look like a regular native app wihout running your code through some native compiler. Instead, Apple provides a way for you to use the same application packaging mechanism as native applications use - you just bundle up all of your classes and resources into a directory and write an XML file to specify the characteristics of that application, much like a deployment descriptor. Once built, you then have a seemingly normal Mac OS X application. In fact, with a little more work on your part, you can even have integration with the Finder and Dock without leaving the Java environment.

With pluggable "look and feel"s available for Mac OS X and now Windows XP, are we now truly going to start seeing the return of the Java desktop client en-masse? If you had asked me a couple of years ago which Swing L&F I preferred, the answer would have been Metal because it looked consistent on all platforms. Although I do like Metal, I think end-users really deserve to be given an application that integrates seamlessly with their native environment. The hard part, of course, is making your desktop applications look and behave the same on your target platforms. I recently blogged about a framework that I developed in the past and perhaps it really is time to dig this out and take it further. Does anybody know of any existing open source frameworks that help you build cross platform Swing applications?

This work is licensed under a Creative Commons License.