Simon Brown's Blog

Tools Archives

JSIG session : Java Development on Mac OS X

Sam Dalton and I are running a JSIG session about Java development on Mac OS X next month...

Java Development on Mac OS X
The Mac OS X platform is gaining ground with developers because of its stable UNIX based architecture, easy to use UI and integrated Java runtime. This session discusses experiences of Java/J2EE development on Mac OS X, talking about the advantages and disadvantages of adopting the platform. The session also demonstrates some of the open source and commercial development tools that the speakers use on a regular basis, discussing any "gotchas" that have been encountered along with way. If you’ve never seen a Mac or are thinking of buying one then this session is for you.

The session is taking place on the 26th of March in Sun's offices near London Bridge, between 12 and 2pm. Full details (including how to sign up) can be found on the JSIG website. As the abstract implies, it's a good opportunity to see what Mac OS X looks like if you've not seen it before. Besides, it's also a good excuse for us to demo our shiny Macs. ;-)

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?

First impressions of Clover

I've recently started using Clover on my open source projects and it's an amazing product. I've not used the Ant tasks yet, but I am using the integration with IntelliJ. Wow, this is probably one of the most impressive products since IntelliJ itself!

If you've not seen Clover before, it's basically a code coverage tool that will help you identify what sort of coverage you are achieving during execution of the code. This means that you can see how much of your code is called when your program is being run, and also how much of your code is run during the execution of your unit tests. In addition to this, it can tell you how many times each particular line/block has been called and also how many times conditionals have been evaluated to true/false.

I'll write a full review when I've had some more time with the tool, but the IntelliJ integration makes using Clover a breeze. Once you've installed the plugin by dropping a JAR file into the IntelliJ plugins directory you get some additional toolbar buttons. Essentially, running Clover is then a simple matter of rebuilding your code with Clover, running your code and then returning to IntelliJ to see the graphical representation of the coverage. I think from the initial download to my first coverage results took about 15 minutes. This really is a great tool and, as I said, I'll write a full review sometime soon.

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? ;-)

XDoclet in the J2EE web tier

It's common that you'll find somebody using XDoclet to help build their EJBs, but how often do you find people using it to help with the J2EE web tier? In his recent weblog, Dave says he is trying to convince his team that using XDoclet is the way to go for generating artefacts like tag library descriptors and the web.xml file. I must admit that while XDoclet is very useful when building EJBs, I'm not sold on the idea of using for the web tier myself. Why? Well, I think that there are several reasons for this.

For each EJB, you have to build 3 classes and the ejb-jar.xml file - all of which can be automated with XDoclet and a single source file representing the bean implementation. This is nice because the remembering all that nasty EJB deployment descriptor stuff is a pain, and everybody knows it's a pain. In one of the JavaOne sessions that I went to this year, the EJB team talked about how they were thinking of taking advantage of the new J2SE 1.5 (Tiger) feature of annotations/metedata (JSR-175) so that the deployment descriptors were automatically generated. Basically this would make XDoclet-like, attribute-oriented programming available to the J2EE platform, and that can't be a bad thing.

Another reason to use XDoclet is so that package and class names are kept in sync between the Java source and the deployment descriptors. However, when you use tools like IntelliJ to refactor a class/package name, you can ask it to look in other files too so you get the deployment descriptor refactoring for free.

I do like using XDoclet for generating the EJB stuff, but for me it doesn't add much for the web tier technologies. Are you using XDoclet in your J2EE apps? I'd be interested to hear from anybody with thoughts on this.

Using another painter's brushes

After a few weeks of working on a project in our offices, a new environment is in the final stages of being set up and we've made the move over to the client site. The work that we've been doing so far has been more like prototyping/proof of concept development. As far as tools go, we've had an almost free reign on what we've been using. Me? I've been using J2SE 1.4, Ant, IntelliJ and some other open source bits and pieces. However, now that the project is about to move up a gear, the toolset is about to change.

Like many large clients, our new environment is going to be locked down for security and management reasons. For example, policies on our XP workstations permit very little in the way of configuration, although thankfully we (developers) are getting local admin privileges. However, just because we will be able to install software doesn't mean that we'll be allowed to install it. Open source is one particular area in which there is still ongoing controversy. In addition to this, the development environment has been defined outside of the immediate group of architects and developers. Without being specific, all I can say is that it's not my choice. ;-)

This brings me on to the point of this entry. How many of you frequently get a choice in your development environment? Also, do you find that open source is still controversial? Having been involved in mentoring a team of new Java developers, I totally understand the thoughts around a standard development environment. Using a mixed environment can be a pain, but can it work? Not using your favourite development tool is something that we have to live with, but would you use somebody else's brushes?

This work is licensed under a Creative Commons License.