Friday May 12, 2006

I've been silent lately, but for a good reason. It's been a crazy month. It's like being back in college again, complete with coding all-nighters. But as of late last night, everything is working beautifully - so I can catch up on some sleep this weekend before the fun begins!

The other guys on the Java Posse went out to Las Vegas last week and had a lot of fun. They even recorded some live podcasts from the TopCoder open. I unfortunately had to miss it. The trip was scheduled a while back, but I declined since I knew from experience the month leading up to JavaOne is always hectic for me. And I was more right than I wish I had been!

Be sure you don't miss our technical session - TS-3576. It has been moved. It is no longer at 1:30, it's at 9:45am in the morning on Thursday, so be sure to check the updated schedule. I can't give any more details about the talk yet, but hopefully you'll see more in a brief demo in one of the keynotes! I have two other "gigs" too: The JavaPosse BOF, which should be a lot of fun, on Tuesday night. And the JSR 273 BOF, on Wednesday night. With a technical session on Thursday and a possible keynote on Tuesday, and hopefully lots of podcast recording sessions and other social gatherings, this is going to be a blast.

But first, sleep!! Zzzzzzz

P.S. I have 1200 unread e-mail messages in my inbox. If some of them are from you, I apologize.

Friday February 24, 2006

(See intro for a background and caveats on these coding advice blog entries.)

When a method is supposed to return an object, and it returns "null", the null is used to convey a number of meanings:

• Empty (when it's supposed to return an array or a list, but the list is empty)
• Can't (when some error happens and an object to be constructed failed; the caller is now supposed to gracefully handle the error)
• Unknown (when a method is supposed to compute some result that it couldn't figure out)

Whenever possible, avoid using nulls. There are several better alternatives.

1. When a method needs to return an array, and you know the array is empty, don't be lazy and just return null. Perhaps you're not being lazy, but believe you're being efficient, because by returning null you can communicate empty to the caller without having to construct an object (the empty array or list). However, the performance impact is minimal. It's very cheap to construct short-lived objects in Java - much less than malloc cost in C. However, you can use the following pattern if this is going to be frequent:

         class Window {
             private static final Window[] NO_WINDOWS = new Window[0];
    
             public getActiveWindows() {
                 if (whatever) {
                     return null;
                     return NO_WINDOWS;
                 }
                 ...
             }
             ...
       

   An approach like this has the advantage that you can start simplifying your own code, since you won't be doing null checks everywhere. If you call the getActiveWindows() method above, you can simply iterate over the results directly rather than branching on null first.
   
   
2. When the "null" return value means something like "unknown", it's even better to use a special marker object. This has a number of advantages.
   • The intent is more clearly communicated, so the code is easier to read.
     
     
   • The marker object can customize some of its methods such that it reacts appropriately. This allows you to move some handling code into the object itself rather than in the client code. (As a simple example, your toString method can be written to be more informative.)
     
     
   • The class containing the marker object can also be written to consider marker objects in a correct way; for example, the right equals() semantics can be written.
     
     
   The above is a bit abstract so let me illustrate with another example. Let's say we're writing a word processor. We have a Document class, representing a document, and a Caret class, representing a visual caret (text insertion cursor). The caret has an associated position in the document, and this is represented by a Position object. Thus, the caret has the following method:

         public Position getPosition();
       

   Sometimes a document doesn't have an associated caret position - for example, when the document does not have focus. We could simply have getPosition() return null for this. But that would mean that client code relying on positions would always need to check for null before calling methods on the position they receive. Instead, the Position class should have a static field representing a non-existent position:

    
          class Position {
              public static final Position NONE = new Position(xxx);
              ...
       

   Now, most client code can simply call Position methods without worrying whether it will be null or not. The Position class itself can be modified such that various methods handle the NONE case correctly: not only can toString() do something like this:

           public String toString() {
               if (this == NONE) {
                   return "Position.NONE";
               } else {
                   ...
       

   but for example position comparison methods can have special considerations for how to handle positions where one or more represent the nonexistent position. Yes, this could be achieved by consistent use of null instead, but it's a lot less readable, and harder to search.

Null handling has gotten some renewed attention recently. With the advent of annotations, you can annotate whether a method is expected to return null or not (e.g. with @notnull). This allows tools to perform static analysis of your code and find potential bugs. For example, if you indicate that a method cannot return null, the tool can obviously flag any "return null" statements within that method (or returning expressions calling methods that may return null). But they can also flag code calling this method that unnecessarily check the return value for null, and more importantly, flag missing return value checks in code calling methods that may return null.

IntelliJ has added this feature already. Looks like it has been around for at least 10 years with lint checkers in C. I look forward to getting this in my favorite IDE (why oh why isn't @notnull and @nullable part of the standard annotations set?) - but in any case, try to avoid nulls by using place holder objects where appropriate.

Sunday February 12, 2006

IDEs tend to de-emphasize comments. Visually, code is more prominent than comments. For example, while most IDEs use black for "code", in NetBeans comments are light gray; in IntelliJ they are also light gray, in Eclipse they are light green and in Visual Studio they are also light green. In all cases, the comments have less visual weight than the surrounding code.

I have a new co-worker, and when I went over to his computer the other day I was shocked to see his modified syntax highlighting color scheme. He had basically turned everything to black - except comments. And the comments - bright red! His rationale is that comments are vital, and he wants them to jump out visually.

I decided I'd try out his scheme. Switching all comments over to red was too much - I like javadoc for methods to stay "quiet". So I settled on switching line comments over, and leave block comments alone (and these are always javadoc, because I use line comments in all other cases, even for comments that span multiple lines.)

I've tried it out for several days now and I think I might stick with it. Judge for yourself - if not by screenshot then in your own IDE.

(Click image for full size)

Saturday December 31, 2005

Joel Spolsky recently blogged about the perils of Java schools. The introduction goes like this:

...When I was a kid, I learned to program on punched cards. If you made a mistake, you didn't have any of these modern features like a backspace key to correct it. You threw away the card and started over.

That instantly reminded me of my favorite Dilbert - one I have handy now because I used it in one of the first few slides in my JavaPolis presentation. I think it portrays a pretty common attitude in the programming world - "it was hard and we liked it that way!"

Wednesday November 16, 2005

As should be obvious from my recurring blog topic of coding style, I care a lot about code readability and style.

One criticism I've heard frequently is that you shouldn't reformat code to be style-compliant, since that introduces lots of diffs into the version history of a file. Oh no, diffs! What horror! Think of the children! Somebody, The children!

I have two responses to that line of thinking:

• First, you clearly don't agree with me on the importance of consistent formatting and readability. Perhaps I should just grow up, but when I see code like this I cringe:

     void myfunc(int a_foo, int a_bar)
     {
       foo = a_foo;
       myfunc (foo);
     }
  

  Source formatting typically doesn't rename variables (to wipe out the underscores ( _ ) from variable names) but it certainly could put the opening brace back up where it belongs, as well as remove the space between the method name and the opening parenthesis, etc.
  
  Reading the above code is the common operation. Tracking down line history is the occasional operation.
  
  
• Second, and this is the more important point: You're probably not familiar with, or at least well versed in, source code archaeology.

Source code archaeology is very similar to the archaeology you're familiar with: you dig down, layer after layer, uncovering artifacts from a particular time period. You essentially get to see the state of affairs at one particular point in time. Then historical events occur and layers upon layers are deposited on top.

With source code archaeology, you can dig back into the history of a file. Let's pretend we agreed on a particular coding style for the NetBeans source code base, and I went and ran a filter over the entire code base, reformatted it, and checked the code in with the comment "Source code reformatted to spec using codestyle ide/formatsettings.xml". Reformatting the entire source base (yes, I know, blasphemy!) is usually criticized as bad because you can't find out why a particular line was added or changed, since now the version information for the line points to the reformatting delta. But but but - remember the layers! (Insert mandatory Shrek reference here...) It's easy to go to the layer below the reformat, and see what the version of the file looked like prior to the reformatting delta. So, once you've done a giant reformat of the source base, looking for the origin of a particular source file line may involve multiple operations. First you determine what delta corresponds to the current version of the line. If you see that it was for a reformat, you peek at the version below it, locate the same line, and look at its original comment.

Now, you might argue that that's an extra step. You would be right - but think about it, what's more common, reading code, or reading the checkin comment for a particular source line? As long as you can get the team to use the same source formatting conventions (perhaps even performed or enforced automatically at checkin) you'll only need to do this global operation once.

Tools should make this job easy. It's not all that hard on the command line either. You may have heard of the "cvs blame" command.

tor:1% cvs blame
Unknown command: `blame'

CVS commands are:
        add          Add a new file/directory to the repository
        ...

With cvs annotate you can get annotations for the current version. Let's say that you discovered that a reformat happened in revision 1.43 of file Foo.java. To see what the file looked like before that, simply do

tor:2% cvs annotate -r 1.42 Foo.java

1.1          (tor      24-Mar-03): /*
1.1          (tor      24-Mar-03):  * Copyright 2003 Sun Microsystems, Inc. All rights reserved.
1.1          (tor      24-Mar-03):  * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
1.1          (tor      24-Mar-03):  */
1.1          (tor      24-Mar-03):
1.1          (tor      24-Mar-03): package foo.bar;
1.1          (tor      24-Mar-03):
1.1          (tor      24-Mar-03): import java.awt.geom.Rectangle2D;
...

As I mentioned, tools should make this easy. I'm not sure what the current state of this is in NetBeans' new CVS support, or in other IDEs. I had a strong need for this back when I worked with SCCS and Teamware on Sun's C++ development environment. I built a prototype for doing this kind of exploration; I think it's still relevant today, seven years later, so I'll include a couple of screenshots of it. Consider this a wishlist for $favorite_ide, in my case NetBeans.

The idea is that you get to open your source file in a version-annotated view, where all the source lines are colored according to some source code metrics. For example, really old lines have a dark background, and recent lines have a bright red background. (To show which lines belong to the same delta, look for the < and > signs in the left margin showing contiguous blocks, since code about the same age can have roughly the same color but should be logically distinguishable.

The point is that you want to be able to click on a line to be able to see its checkin comment - and to quickly cycle through previous versions of the file (and diff between versions).

Another possible coloration assigns a different color to each user who has touched the file. The overview gives you an indication of who's most responsible for this source file.

There are some other minor things here too, but I think I've made my point: Source Code Archaeology - it's important. It needs better tools support. But it's possible today, and should help you make the transition to a properly formatted source code base.

(See intro for a background and caveats on these coding advice blog entries.)

In my previous entry I covered source code archaeology. That entry was leading up to a coding tip: Reformat your source code.

Sometimes you find yourself working on an old code base. Perhaps it has some accidental embedded tabs here and there, perhaps it follows an old-school formatting style (perhaps from a recently converted C++ programmer still hanging on to the unholy GNU bracing style.

If you own the source code yourself, or if all the programmers cooperating on this source base agree on a coding style, consider reformatting all of it to your agreed upon style - and keep it that way.

I won't go into the arguments against reformatting again - I cover those in the source code archaeology entry. Let me just state how this can work. In my case, I use the Jalopy plugin to NetBeans to do source formatting - but of course it has plugins for other IDEs (or even command line usage) so the IDE choice is not limited by your decision to reformat the source base. Now, the formatting settings can be exported to XML. Check this XML file into your versioning system, and have everybody import it. Now you'll be sure people format the source code in the same consistent way and you won't have "noisy diffs" as two developers take turns checking in versions of a file using different formatters or settings.

Here's my settings-file. It's basically the default jalopy settings (which closely match the JDK style) but with some tweaks. First, line lengths are bumped to 100. Second, limit grouping in import statements to only differentiate between top level domains, e.g. java, javax, org and com.

Two final comments:

• First, make sure that your formatting checkins don't contain any other changes (e.g. code changes); with lots of diffs it will be a lot harder to discover what they are. Future source code archaeologists should be able to read your "source reformat - no semantic change" comment and be able to mostly ignore that delta.
  
  
• Second, if you're dealing with branches, you might think you would have a hard time merging changes back to the (reformatted) trunk, but no - that's easy: just perform a source reformat on the branch code too before diffing!

Monday November 14, 2005

The interview with Jonathan Schwartz for the Java Posse is now available.

We cover a number of topics interesting to Java developers, such as why Sun would give software away for free, the Web 2.0 hype, DRM, etc. Go check it out; better yet, subscribe with the iTunes link on the right side of the page.

I've been frustrated that the audio quality in some of our interviews has been pretty bad; doing voice-over-ip certainly has its limitations. We didn't want that to happen this time, so rather than our usual over-the-net interviews I went to Jonathan's office in person such that I could record the audio feed directly with my headset. So, the audio quality this time around should be perfect!

Monday November 07, 2005

(See intro for a background and caveats on these coding advice blog entries.)

I've started using the Java 5 language features - and loving every minute of it. The other day I wrote an enum. (Tip: Did you know that there are two new classes, EnumMap and EnumSet, which lets you write "bit flags" with int-performance and with type safety?).

But, I've seen enum constants capitalized in different ways. For example, in this technical article enum constants are in all lower case, in this article they're all in upper case, and finally I've seen people argue (can't find a link at the moment) that enum constants should have their own capitalization: initial cap. The latter form is interesting, but when I read about it, no solid argument for why it should be done that way was offered, so it seems better to not confuse it with Class and Interface name capitalization.

We should pick one convention. And I think that convention should be: All uppercase, same as constants today. Why? It makes a lot of sense, because enum constants ARE final like the old public static final's you're used to capitalizing.

So:

public enum StopLight { red, amber, green };
public enum StopLight { Red, Amber, Green };
public enum StopLight { RED, AMBER, GREEN };

Tuesday October 25, 2005

Be sure not to miss the latest Java Posse interview: #9 - Joshua Bloch. In case you don't know, he's behind java.math, the Java Collections framework, annotations, and my personal favorite book on programming: Effective Java.

In the interview you'll hear what he would like changed in the Java libraries, you'll hear about his plans for an update to the Effective Java book, his thoughts on Ruby and Python, and of course we cover his feelings about Java. The title of this blog entry is a direct quote.

I won't, and haven't, posted a note every time there is a new Java Posse episode. (There is a blog on the javaposse page you can subscribe to for that.) But I really didn't want you to miss this one!

One note on the audio quality. You may notice that the interview episodes have lower quality audio then our news programs. That's because when we interview people, we need to use either the phone, or some kind of voice over ip solution like Skype, which means we can't use the better quality (but harder to set up) rig we have for our own recording sessions. Bear with us. We're looking into better solutions for the future.

If anybody would like to create transcripts of some of the interviews (people have requested them) we don't have time to do that ourselves but would happily post contributed transcripts.

Saturday October 15, 2005

I've got a new toy: a brand new Sun Ultra 20 workstation. It's for home use. It's a great system, and very fast. I used one of these to do my coding challenge back in June. Now I've got my own!

(If you're looking for a new home computer, check these out. They're using AMD 64 bit Opteron processors - mine is 2.6 Ghz - so you can run many different operating systems on it. Here's a very enthusiastic review of it, and here's another. I just wish the fan could have been a little quieter.)

I decided to put Ubuntu linux on this one. It was straightforward. (I had first tried putting Fedora Core 4 on it, including the various java tools. But those systems do all kinds of weird things to support Java (some kind of GCJ variant plus various "smart" scripts which essentially prevented ant from running). For Ubuntu I didn't install any of the Java development tools, and instead downloaded them directly myself and put the latest Ant and Tiger on there.

I then decided I wanted smooth fonts; after looking at nicely rendered fonts on an Apple laptop it sure hurts the eyes to look at the default configuration of a Linux desktop! Luckily I could enable subpixel antialiasing in one of the configuration screens. Much better. But my IDE still didn't look good. That reminded me that Mustang, the next generation JDK, will support LCD subpixel rendering. So I downloaded Mustang, restarted NetBeans with it, and lo and behold - it works very nicely. The following screenshot shows the before & after effect but will only look right on LCDs:

Here's some more indepth analysis of the rendering changes.

Monday October 10, 2005

(See intro for a background and caveats on these coding advice blog entries.)

It's important to write readable code. But that's not the whole story. Your code should be easy to debug too. In this blog entry, I'm pointing to some Bad code patterns that makes your code hard to debug.

The first, and most evil practice is to write a conditional on the same line as the if:

    if (foo) bar();

Yes, this already violates other rules of good coding style in that it's missing braces. But even the cleaned up version is no better in terms of debugging:

    if (foo) { bar(); }

This is Bad for debugging because as you're stepping through code, the whole if block becomes a single step! While you're debugging, you typically want to know if the conditional branch was taken or not. With the "correct" three line version this is not a problem; you step once over the if, and you can then separately decide if you want to step into the conditional method call for example.

    if (foo) {
        bar();
    }

You may not realize you're guilty of the above problem, but if you use the ternary operator, a?b:c, you might be. The ternary operator is really an if-then-else block in disguise. Don't write code like this:

   x = foo ? bar() : baz();

for the same reason as above: this is now a single debug statement so it's hard to decide if you want to step into or not (if you for example are only interested in stepping into if the target is baz().)

This frequently comes up in conjunction with return statements. I've seen coding styles recommend you to use ternary operators instead of if blocks. This is where code simplicity (for those who feel that a terse ternary statement is more readable) goes squarely against debuggability. I recommend you stick with the if block. I feel if blocks are more readable too. The argument for collapsing statements is usually that it makes the code more dense, so you can "fit more on the screen", but the same argument could be used against whitespace between logical code blocks and methods etc., and I think we all agree that optimizing for code density is not optimizing for code readability.

Another bad code pattern for debuggability is

    getFoo().getBar().getBaz().doit();

or even the slightly less evil, but still bad

    getFoo().doit();

What's wrong with this? Convenient Steppability^TM. In this pattern, all the method calls before the last one are simply getter calls. The doit() method is the interesting code we want to step into. However, since all the preceeding accessors are called in the same statement, we have to Step Into, then back out of, each method in the call chain up until we finally get to the interesting method!

Overshooting (the technique of Stepping Over, then Undoing when you've gone too far) doesn't work here. There are some simple workarounds; for example, some debuggers let you put the caret on the last method, and then invoke a different stepping action to step into the desired method. But this is clearly inconvenient; you don't want to force users who are rapidly stepping with F7 and F8 to have to click to step into interesting code.

Thus, you should write the above code like this instead:

    Foo foo = getFoo().getBar().getBaz();
    foo.doit();

Obviously, if any of getFoo(), getBar() or getBaz() were interesting too, you could break this up further, but the whole point here is that you typically don't want to step into accessors (which I'm assuming the above are) so get those into their own statement. Now you can step right over the first line and into the second.

Tools can help this situation. In Sun's C++ development environment, there is a fourth Stepping action: Run Into Last Statement Call. This stepping action "magically" achieves precisely what you want: It analyzes all the method calls in the current statement, and steps into the last such statement. The net result in that the code example above (before we broke it up) you could click on the Run Into Last Statement Call button, and it would step right into doit() ! I really really want that action in the NetBeans debugger. I guess it will require some fancy bytecode analysis. The screenshot on the right shows the Stepping action part of the menu in Sun Studio - the last action is the magical one...

Thursday September 29, 2005

A new episode of the Java Posse podcast is available. Episode #1 was an interview recorded a while back by Dick, so this episode is actually our first joint recording. It was a fun start.

Let me apologize in advance for using the phrase "you know" way too much. It's, you know, totally subconscious. Next time I'll try to slow down and reduce the you-knows. And Carl is getting a new microphone :-)

iTunes link

Tuesday September 27, 2005

Until now in this "column" I've written about source code itself: Don't use vanity tokens, don't capitalize acronyms, don't use tabs, and don't (over)use logging. Today I'd like to talk process instead: debugging.

The process of debugging usually involves mental verification: you step through the code, and compare what you think should be happening with what is actually happening. As you do this, you frequently have to decide if you should Step Into or Step Over method calls. On the one hand, you don't want to step over a method in case the bug is occurring within the method call. On the other hand, if you don't know where the bug is yet, you can waste a lot of time stepping through methods before the bug is triggered.

With the following technique however you get the best of both worlds. The approach is as follows: Always step over. If you detect that the bug has happened (e.g. some return value from a method is wrong, or a class field is changed into the bad value you're looking for, etc. etc.) then simply Retry the method. By retry, I mean pop the current stack frame and step back into the method! This gives you a primitive "Undo" function. Without restarting your program, you get to step through the method again.

Many debuggers offer actions to pop the stack, so you can use this technique today. What I really want however is a convenient action which does both of these operations (pop followed by step into), and have it located in a convenient place such as the debugging toolbar.

So I decided to try out the new NetBeans 5.0 module plugin development support. Holy cow! - It was unbelievably easy! In 25 minutes, I wrote a plugin (which adds a debugger toolbar action which pops the stack and steps into in one step), I generated a plugin bundle, installed it in the IDE and tested that it works on a simple test program. And this was as a first time user of the plugin support! I especially liked the "New | Action" wizard which automatically handled everything from icon and displayname to positioning the action in the menus and toolbars.

I'm not exaggerating - it took just 25 minutes. And I'm not bragging either; doing all this in 25 minutes says something about the productivity of the tool, not about my programming skills. There's a quick-start document available with more information on how to build plugins in 5.0. But I wrote the plugin while on the train commuting to work, and without a network connection I figured it out anyway on my own.

You can download and install the plugin yourself in NetBeans 5.0. As you can see, the main source file is very trivial.

The screenshot on the right (click for full size) shows the IDE in action; notice the new action in the toolbar (easily spottable by the ugly icon I supplied) as well as the plugin project in the navigator.

Anyway, you can use this retry technique as long as your IDE supports Pop Topmost Stackframe. It sometimes requires a little work on your part. If you're stepping through a method that has side effects (such as initializing fields), you may have to account for these. By "account for" I mean undo the side effect. Usually I handle it by clearing out the fields in the watch window after popping the stack. You did realize you can change values in the Value column and cause assignment in the debugged process, right?

Monday September 26, 2005

The iTunes directory has been updated to include the Java Posse podcast now. If you search for "Java" in the music store it's also the first match!

Click on the image on the left to subscribe. If you've already subscribed manually consider resubscribing so you're counted in the iTunes statistics.

Thursday September 22, 2005

The Improved JavaCast is here: Java Posse. A wild band of Java mercenaries riding through the frontier of .... ah never mind. You get the idea: A group of people talking about Java. The charter is the same: weekly programs covering the Java world. But the format will change. Less ranting. Shorter programs. Separate interviews. And the show will evolve based on feedback.

The set of anchors has changed too. The show will now be hosted by Dick Wall of New Energy, Carl Quinn of Google, and yours truly. I'm hoping Carl will use his insider status to get some of Google's A-list Java personalities on the air, and I will do the same at Sun... and by then the ball should be rolling!

There is already a first episode available. This one was recorded by Dick a while back under the JavaCast banner, but never got broadcast (JavaCast story here.) It's an interview with one of the people behind the IntelliJ IDE. I thought it was very interesting - and several of his metaphors work for me.

Unfortunately there's no subscription link up in the iTunes music store yet. I'll post it as soon as it's available. Please tune in, and if you have feedback on the format do share it. We'll record our first "new" show next week. For more details, subscribe to the javaposse blog at http://javaposse.com.

P.S. If you want, you can subscribe to the podcast manually now; in iTunes, go to the Advanced menu, select "Subscribe to Podcast" and paste in http://feeds.feedburner.com/javaposse