ERIC BRUNO'S BLOG

Java: The Daily Grind.

October 2006

With this release, on Oct. 30, Sun finally has an official Java EE 5 development tool.

Although Java EE 5 has been available for months, the version of NetBeans 5.5 that supported both it and the application server that Sun released with it, was still in beta. Sun put together an impressive package of Java EE development tools that included NetBeans 5.5 beta, Sun Java Application Server v9 with deployment and debugging, a UML editor, BPEL tools, web service support, and a bunch of XML editors. This package is called the NetBeans Enterprise Pack (http://www.netbeans.org/products/enterprise/). The only issue I had with it was the beta version of NetBeans.

Over the past few months, I’ve worked on a Java EE 5 project using this version of NetBeans, and found it to be buggy. I discovered ways to work around the problems, although sometimes the only remedy was to restart the IDE. Alas, with the official release of the IDE, I look forward to trouble-free Java EE 5 development. Every indication from my early work with the released version of NetBeans 5.5 is that it’s stable and quite usable. You can download the NetBeans Enterprise Pack, with the released version of NetBeans 5.5, here.

NetBeans, Eclipse, and the Mac

Readers may recall that I recently blogged about my thoughts on purchasing a Mac. I’m happy to say that I’m now a proud owner of a new MacBook. I’m also happy to say that the Mac makes a very friendly environment for the Java developer. I’ve downloaded the latest versions of both NetBeans and Eclipse, and find that they work just as well on the Mac as with any other OS. Although I would recommend at least 1G or RAM for any serious Java developer.

To be thorough, both NetBeans and Eclipse support Windows, Linux, Solaris, and Mac OS X. Eclipse also supports AIX, HP-UX, and a wider range of 64-bit Windows and Linux versions.

Happy coding.

-EJB

Posted by Eric Bruno at 09:46 AM  Permalink |

I love XML, but XML-based ANT scripts can be difficult to read and write. Enter project Gosling.

Project Gosling (https://gosling.dev.java.net/), named after the subect of the book, The Ugly Duckling, not the author of Java, allows you to write build scripts for Java projects in, what else? Java. Justin Lee created Gosling to work just like Ant, but with Java build scripts that use the Java SE 1.6 compiler API instead of XML.

In fact, Gosling's creator Justin Lee goes so far as to say that Gosling can be considered a fork of the Ant project, with some key differences:

- By removing the XML processing within Ant, the code has been cleaned up and restructured in a way that is more natural to most Java developers.
- Java 1.6, with the Compiler API, is a minimum requirement
- Gosling build scripts are written in Java, not XML

You can compile and execute your Java-based build scripts using javac and java, respectively. The benefits of Java build scripts over XML are:

- Java is a programming language; XML is not
- Gosling build scripts, being built in Java, are more comfortable for Java developers to deal with. There is no need to learn XML-structured Ant syntax.
- Build-file inheritance is supported
- Ant issues such as those around antcall go away as all logic is built in Java

To get an idea of what a Gosling build script looks like, here is the build script for Gosling itself:

import java.io.File;

import com.antwerkz.gosling.Default;
import com.antwerkz.gosling.Description;
import com.antwerkz.gosling.Project;
import com.antwerkz.gosling.tasks.Copy;
import com.antwerkz.gosling.tasks.Jar;
import com.antwerkz.gosling.tasks.Javac;
import com.antwerkz.gosling.tasks.Javadoc;
import com.antwerkz.gosling.tasks.Zip;
import com.antwerkz.gosling.types.DirSet;
import com.antwerkz.gosling.types.FileSet;
import com.antwerkz.gosling.types.Path;

public class Gosling extends Project {
public static final String VERSION = "0.1";

private static final String BUILD_DIR = "build/classes";
private static final String DIST_DIR = "build/dist";
private static final String DIST_FILE = "build/gosling-" + VERSION + ".zip";
private static final String BOOTSTRAP_BIN_DIR = "bootstrap/bin";
private static final String BOOTSTRAP_LIB_DIR = "bootstrap/lib";
private static final String JAVA_SRC_DIR = "src/java";
private static final String BIN_SRC_DIR = "src/bin";
private static final String JAVADOC_DIR = "api";

public Gosling() {
loadProperties("gosling/gosling.properties");
}

@Default
@Description("Builds the Gosling project")
public void build() {
new Javac(this, BUILD_DIR)
.addSources(new FileSet("src/java")
.addInclude("**/*.java"))
.addOption("-Xlint:unchecked")
.addOption("-Xlint:deprecated")
.addOption("-g")
.execute();
new Copy(this)
.setDestDir(new File(BUILD_DIR))
.addFileSet(new FileSet(JAVA_SRC_DIR)
.addExclude("**/*.java"))
.execute();
}

@Description("Removes the build directory")
public void clean() {
delete("build");
}

@Description("Builds the distribution bundles")
public void dist() {
clean();
jar();
mkdir(DIST_DIR);

new Copy(this)
.setDestDir(new File(DIST_DIR + "/bin"))
.addFileSet(new FileSet(BIN_SRC_DIR))
.execute();

new Copy(this)
.setDestDir(new File(DIST_DIR + "/lib"))
.addFileSet(new FileSet(BUILD_DIR)
.addInclude("*.jar"))
.execute();

new Zip(this, new File(DIST_FILE))
.addFileSet(new FileSet(".")
.addInclude("build.*")
.addInclude("src/**")
.addInclude("lib/*.jar"))
.execute();
}

@Description("Builds a jar of the compiled resources")
public void jar() {
build();
new Jar(this, new File("build/gosling.jar"))
.addFileSet(new FileSet(BUILD_DIR)
.addInclude("**"))
.execute();
}

@Description("Builds the javadoc")
public void javadoc() {
delete(JAVADOC_DIR);
new Javadoc(this, new File(JAVADOC_DIR))
.setSourcepath(new Path(this)
.setPath(JAVA_SRC_DIR))
.addPackageset(new DirSet(JAVA_SRC_DIR))
.execute();
}
}

Posted by Eric Bruno at 10:43 PM  Permalink |

Do you use a Java IDE, or just an editor and the command line?

Up until just a few years ago, I was still using the old-fashioned method of writing code in a simple editor, and compiling it from the command-line. Then, I would launch the application from the command-line, and watch the output of my System.out.println calls to analyze what was happening.

That was rough.

I did this because, at the time, Java IDEs were either too expensive, or just too clunky, to use. This was especially true if you were doing Servlet or EJB development that required an application server to launch your code.

Even when Eclipse came on the scene, I avoided it because I assumed my experience with it would be like all the previous IDEs I'd used. I was resistant to even waste my time reading about it to find out that my preconceived notions were wrong.

Source-level Debugging

As it turned out, I was wrong. Eclipse, and then NetBeans, boosted the Java development process lightyears ahead. These IDEs are fast, straightforward to configure, and easy to use. You can very quickly and easily code and debug (at the source-code level) your projects, whether they're standalone Java SE applications, or they require some form of a server to launch them. Source-level debugging is a powerful feature; being able to step through code in a Servlet or an EJB can save you loads of time compared to the println method of debugging.

I wonder how many people are still using the editor/command-line method of coding and debugging? If you're one of them, and you feel you have a good reason to stick to that method, share it with me and your fellow readers. Perhaps you can be persuaded to try an alternative to make your life easier. Or, conversely, perhaps your reasons for avoiding an IDE are valid. Your feedback might help to shape future versions of these IDEs to work for you and others like you. Feel free to respond to this blog, or send me an email at eric@ericbruno.com

-Eric

Posted by Eric Bruno at 02:27 PM  Permalink |

Many of you know Jabber, the open-source, XML-based, standard for instant messaging, but did you know about Smack?

Jabber has over 21 million users, and is the basis for Google’s IM client, Google Talk. There exist literally hundreds of existing Jabber-based IM clients and Jabber-enabled applications. There are some good reasons why you may want to incorporate Jabber IM into your application as well, such as to enable Internet-capable event notification, or to build a community around your users so they can communicate with one another.

With the Smack API for Java, it’s possible for you to add IM functionality to your Java applications today. A recent article by John Ferguson Smart, published on java.net, describes the process in detail. Let’s take a quick look at the highlights here.

eXtensible Messaging and Presence Protocol (XMPP)

Jabber uses an XML-based protocol called eXtensible Messaging and Presence Protocol (XMPP). The protocol supports all types of messages, such as chat, group chat, email-like messages, and headline (or alert) messages as well. Here’s a simple example:

<message to=”eric@ericbruno.com” type=”chat”>
  <thread>t12345</thread>
  <body>Hi Eric, great blog entry</body>
</message>

The Smack API

The Smack API itself is written in Java, and it easily allows you to integrate message sending into your Java application. Of course, you need to have a message server in the middle to broker the communication, such as Wildfire, or Google Talk.

Here is the code to connect to a generic Jabber server:

XMPPConnection connection = new XMPPConnection("ericbruno.com");
connection.login("user", "password");
Message message = new Message();
message.setTo("eric@ericbruno.com");
message.setSubject("Blog Entry");
message.setBody("I really liked your entry on the Smack API");
message.setType(Message.Type.HEADLINE);
connection.sendPacket(message);
connection.close();

It’s very simple: you login to a server; build your message; send the message; close the server connection. If you think that’s easy, take a look at the specialized Google Talk API:

GoogleTalkConnection connection = new GoogleTalkConnection();
connection.login("john", "smith");
connection.createChat("ericbruno@gmail.com").sendMessage("Nice blog entry");

Detecting presence is straightforward as well:

Roster roster = connection.getRoster();
Iteration iter = roster.getEntries()
while (iter.hasNext())
{
  RosterEntry entry = (RosterEntry) iter.next();

  if (presence.getType() == Presence.Type.AVAILABLE)
    System.out.println(entry.getUser() + " is ONLINE");
  else
    System.out.println(entry.getUser() + " is OFFLINE");
}

First, the code goes through your roster, which is the list of users you’ve indicated you’d like IM with from time to time. As we loop through the roster entries, we check their availability by calling getPresence on each RosterEntry. Finally, we display each roster entry’s username and an indication of presence: online or offline. The API supports adding and removing users to your roster, as well as user discovery.

Receiving messages is also straightforward. In fact, the entire Jabber API is quite easy to use. Most of your work can focus on the user interface of your IM-enabled application. For more details, see below:

- Jabber
- Smack API
- XMPP
- Article: Instant Message in Java Made Easy: The Smack API

-EJB

Posted by Eric Bruno at 09:15 AM  Permalink |

The debates over Java closures have become heated lately. It really should be about making things simpler.

Some well known people in the Java community, namely Bob Lee, Doug Lea, and Joshua Bloch, have written up an alternative proposal for Java closures (which is a subject I covered in this blog a few weeks ago).

You can view the proposal using Writely (Google’s Ajax-enabled group collaboration application) here.

In this paper, the authors discuss the shortcoming of Java’s current closure implementation: the anonymous inner class. Basically, the problem is that they’re ugly! And with concurrent application development becoming more pronounced with the latest toolkits and frameworks, this can lead to code that’s very difficult to read and maintain.

The authors propose a syntax for closures that removes the keyword new, the actual class declaration, and the method names from the closure definition. Below is an illustration from their paper to prove how this improves code readability:

EXAMPLE 1:

Here is the Java 5 code to start a thread whose run method invokes a method named foo:

new Thread(new Runnable() {
public void run() {
foo();
}
}).start();

With the authors' proposal, the following code would be equivalent:

new Thread(Runnable(){ foo(); }).start();

EXAMPLE 2:

Here is the Java 5 code to sort a list of strings by length (from shortest to longest):

List ls = ... ;
Collections.sort(ls,
new Comparator() {
public int compare(String s1, String s2) {
return s1.length() - s2.length();
}
});

Here is the same code rewritten using the proposed syntax:

List ls = ... ;
Collections.sort(ls,
Comparator(String s1, String s2){
return s1.length() - s2.length();
});

I like the syntax because it’s cleaner, easier to read, and it doesn’t add any new keywords or constructs to the Java language. It simply eliminates some. For more on the closure debate, read Bob Lee’s blog.

What do you think about closures? Is it a lot of hoopla over a relatively obscure new feature, or is it very important to you that the Java folks get this right? Respond to this blog or email me at eric@ericbruno.com

-EJB

Posted by Eric Bruno at 09:19 AM  Permalink |