I am not an IDE user, except for Netbeans 4.1 and JDK 5 (Tiger)

I am not an IDE user, except for Netbeans 4.1 and JDK 5 (Tiger)

If you haven't Tried NetBeans 4.1 with JDK 5 (Tiger), you may be missing out. Take it from someone who doesn't consider himself an IDE user.

Introduction

Lately I've been working on a project that is 100% Java, which is unusual for me, normally I'm working on JDK projects that are mostly in C or C++ with a smattering of Java code. This particular Java project isn't destined for inclusion into the JDK and technically it's a major modification or re-write of some existing 20,000 lines of Java code. It's not a J2EE application, and it's not a Web Service, it's just a large batch of Java code that runs on:

• Solaris 8/9/10 SPARC
• Solaris 8/9/10 SPARCV9
• Solaris 8/9/10 X86
• Solaris 10 X64 (AMD64)
• Linux X86
• Linux X64 (AMD64)
• Linux IA64
• Windows 2000 X86
• Windows 2003 X64 (AMD64)
• Windows 2003 IA64

And any IDE I use needs to run well on most if not all of those platforms. So I decided to make this my first big adventure using the NetBeans 4.1 IDE. Keep in mind that I'm an old vi/dbx user, and in my opinion the very best IDE ever created was dbxtool, or sparcworks as it was more famously named, which was probably the simpliest IDE on the planet, ok, maybe some people wouldn't even consider it an IDE. Sure, I've used many IDE's for debugging and doing performance analysis, but to actually use an IDE for source code editing and code development? Live in it all day? Nah! Seemed like such overkill and not very productive. I had always felt more productive in an extremely responsive but simple text editor like vi. Using an IDE was limited to the extreme cases where I needed to debug or trace some kind of platform specific problem that needed the power of an IDE. I did start to use emacs many years ago, but decided it looked too much like an operating system and figured I'd wait for the next great wave in source code editors to come along. Well, it never really happened (forgive me emacs), and I've always managed just fine with vi/dbx, so nothing ever changed. My retirement would happen before I stopped using vi. ;^)

My Java Experience

I've worked on many Java projects, but few that were 100% Java. I was in the Java WorkShop 2.0 project many years ago, which was all Java except for fastjavac (written in C). Unfortunately, I spent all my time working on fastjavac, and about the time I started working on the Java sources, the project was cancelled and I ended up back in C/C++ on another project at Sun. So I've written a java compiler (fastjavac in C), have written many small Java testcases, and fixed a lots of bugs in Java code, but doing any large and serious Java source development had escaped me. I know the language syntax inside and out, and can probably parse class files in my sleep (and think I have sometimes, boy that's a scary thought). It was just all those JDK Java API's that I didn't feel I knew, and maybe I'm not the only one, how many people know about every Java API in the JDK? Just kidding, please don't send me any email, I'm sure there are lots of you out there. :^) So this little Java project was a new adventure for me, and I decided that NetBeans 4.1 would be part of it, and hopefully it wouldn't be a Freddy Kruger role. :^)

MacOS 10.4 and JDK 5 (Tiger)

The first thing I wanted to do was use JDK 5 (Tiger) with it's new language features, but I also wanted to be able to switch back and forth between platforms as my situation allowed. This would also be important too because this resulting Java application needs to run on all flavors of Solaris, Linux, and Windows. NetBeans 4.1 was the answer, and also worked on my Mac 1.5GHz PowerBook. Unfortunately I needed a JDK 5 Beta from Apple, and it only ran on MacOS 10.4. This initially delayed the project because I was waiting for the initial MacOS 10.4 problems to be resolved, specifically the issue with the VPN Client software from Cisco. I sure wish Apple would have made their JDK 5 available on 10.3, oh well. So eventually I upgraded to Mac OS 10.4, suffered a few minor issues, but got the Apple JDK 5 installed along with NetBeans 4.1 and off I went.

RAM Memory

The first issue I ran into was a performance one, especially when running many applications at once, the performance was not zippy and I suspected quite a bit of page thrashing. I had been waiting for an excuse anyway, and upgraded to 1GB RAM, the performance issue went away. If you are going to use NetBeans 4.1, and want a good experience, get 1GB RAM. This probably isn't just true for NetBeans, any serious large Java GUI usage will demand memory, and memory is cheap, I'd spend the bucks if I were you, it's worth it.

Although I started with my Mac PowerBook, I've also used NetBeans 4.1 on my rather ancient Sun 360MHz Ultra60, the page thrashing issue was much more obvious on the Ultra60 when it had 512MB RAM, the disk noise was pretty bad and only calmed down when you stayed in one application for a long time. I was running Solaris 10 and JDS on the Ultra60, and several Java GUI applications at the same time, along with Mozilla, so this page trashing wasn't a big surprise. After boosting the Ultra60 to 1GB RAM, I now have a quiet office and NetBeans 4.1 actually works very well, and is very acceptable, darn close to the performance on the PowerBook.

Startup and Interactivity

The startup of NetBeans 4.1 is a little slow, but not really an issue. On every machine I have tried it on, it has worked very well. Once it was up and running, I never had to re-start it, it was solid and reliable. So who cares about startup time?

Most of the defaults provided by NetBeans have been left alone, with the exceptions of trying to turn off the popups in the editor for the javadocs, which I didn't like, and the netbeans.conf file described below.

Interactivity was acceptable with one minor issue around occasional 3-5 second pauses during editing. With some advice from the NetBeans people, I created a "~/.netbeans/4.1/etc/netbeans.conf" file and added this line to it:

netbeans_default_options="-J-server -J-Xms64m -Jmx128m -J-Xverify:none -J-XX:PermSize=64m -J-XX:MaxPermSize=96m -J-XX:+UseConcMarkSweepGC -J-XX:+CMSPermGenSweepingEnabled -J-XX:+CMSClassUnloadingEnabled"

This improved things on the PowerBook and seemed to eliminate the pauses, but I need to spend more time with this before I come up with a final formula. The NetBeans Memory ToolBar told me that I rarely needed more than 64Mb, and often was running with less than 40Mb, so I set my initial size to 64m. The CMS garbage collector distributes the garbage collection work and is a better GC to use when trying to avoid long pauses due to garbage collection. Now I have no concrete proof that GC's were causing the pauses, but I'm not seeing the pauses much anymore after I made this change. So if you try this, be prepared to experiment.

The same change on the Ultra60 gave different results, and I removed the -J-server. I suspect the speed of the CPU may impact things, unfortunately I've been working more on the PowerBook so I don't have any further data to provide on the Ultra60 usage. I suppose someday this kind of configuration will become more automatic, but for now people will need to find their "high water mark" of their NetBeans usage and set these accordingly.

Project Creation

So I started a new Java project in NetBeans, and pointed it at the existing source directory of my Java project that contained the 200 source files and 20,000 lines of Java code. NetBeans 4.1 slurped it up, no problem, and didn't miss a beat. There is one jar file I needed in the class path, so I had to add a library via the project properties, a simple process, just remember the word "Open" means "Select". :^) After hitting the 'Clean Compile' button, everything compiled up with no problems. Well, lots of warning messages, but they were there all along.

Using Generics

After starting to introduce Java 5 Generics into the sources, I had to go into the Project properties and change to the JDK 5 Java Platform, and also change the source option to "1.5". But NetBeans handled Generics and all the new JDK 5.0 language features I have tried so far. It might be a little lost on 'enum', and doesn't allow you to create a new 'enum' file yet, but it handled the 'enum' syntax well, and it was trivial to just create a new Java class and edit the 'class' to 'enum'.

First off I turned on all compiler warnings and added -Xlint:all so I got the maximum warning messages, and boy there were quite a few. Then I just started double clicking on the warnings and as I fixed the warnings, I added the use of Generics, and also learned quite a bit about the code base. Adding in the Generics not only tightened up the code, but cleaned it up considerable.

Massive Changes

Now I've always been a rather neat programmer, not as neat as some, but generally my source code is usually well formatted and as trim as possible. Maybe it's the latent artist in me, I can't draw worth a crap, but I do like to stand back, look at the source and say "Looks good". And if I can't make it look good, like a good Catholic boy, I add something in the comments and confess my sins. So I usually don't hesitate to re-write ugly code, delete unused code, or rename mis-named methods or classes. In this regard, NetBeans 4.1 has been GREAT! The Refactoring, Find Usages, Fix Imports, and Format Code features have been so cool, it's changed the way I look at the code. And the Java language is so tight that a re-compile the world can verify most of the changes as being correct or not. NetBeans seems to save away many levels of 'undo', and I've occasionally had to use it, but have gotten into the habit of frequent 'Clean Builds' which for this project take maybe 10-20 seconds. If I don't like something, I change it, wholesale, and get it right. If I didn't like the order of the methods, or the lack of 'private' on the fields, you use 'Find Usages', verify the usage is local, and fix it. If you didn't like the name of a package, a class, a method, or a field, you can use refactoring to rename them. If you need a set of encapsulation methods over the private fields, simple to do, I never write my own encapsulation methods anymore, I let NetBeans create them. If I didn't like the wildcard import statements, I'd delete them, use 'Fix Imports' and get a specific set of import statements. After all the Refactoring, Renaming, and Import changes, I'd use 'Format Code' to clean up the source and fix all the indenting. Then, after I'm all done, I could use the 'Comment Code' feature to update the javadoc comments. If I wanted to see the resulting javadoc documentation it was trivial to build it all and browse it. All very slick.

Now there is a problem with this. In a short amount of time you can make massive amounts of changes to a Java source base, I mean MASSIVE. It might turn an ugly duckling into a beautiful swan, but there might be a few Mother Ducks out there that won't recognize their baby anymore. So if anyone else is trying to track these massive changes, good luck to them. Or if you need to re-sync with the original version of the sources, not an easy task. I haven't come up with a good answer to this yet, seems like we need better code merging tools. Maybe that will be my next big adventure.

Of course when dealing with a product like the JDK, you don't encourage people to do wholesale massive changes to the Java source, it's just too risky. So anyone working on sources that need to be carefully changed should be careful with some of these NetBeans 4.1 features. Not that a little 'Format Code' clicks wouldn't help some of that old stable code. :^)

Running and Debugging

Now I hadn't expected that this Java code that was destined for Solaris, Linux, and Windows machines would make sense to run on my PowerBook, but guess what? It came in pretty handy. I wrote a small test and was able to run and debug it on my PowerBook and it worked quite well. My next step will be to learn how JUnit tests work, since this code base never had any tests, and the artist in me doesn't like that.

Conclusions

My conclusions? I'm having fun and the project is on the road to being a success. I honestly cannot say that the NetBeans 4.1 GUI is 100% the way I'd like it, but it's a pretty powerful tool, and when it comes to Java sources I'm not sure I'd want to use anything else. I'd encourage anyone with a large batch of Java sources to give it a try.

And I guess I lied, I am now an IDE user, a NetBeans 4.1 IDE user. :^)

Posted at 12:00AM Nov 10, 2005 by kto in Java  |  Comments[2]