Friday, December 31, 2004

Need SWT Fans/Volunteers

I'm planning on putting an SWT section into the GUI chapter of Thinking in Java 4th edition. I've begun learning about SWT (I like it), but I realized that I might be able to get help from the SWT fan base on this. The goal would be to translate the Swing examples to SWT, so that people would be able to compare and contrast the two approaches (I won't have space for all the examples, but I'd like to see what they look like first so I can choose the most interesting/compelling ones). If you're interested in volunteering for this, email me at I suspect there will be several folks interested in this so we'll try to coordinate and prevent duplicate efforts, and post the results via a wiki and/or a weblog.

NetBeans 4.0 & IDEs

Since NetBeans 4.0 is (cleverly) an optional rider on the JDK5 update that just came out, I thought I'd give it a try. Initially it looked quite promising, as it said it would use my existing sources and ant file (which works just fine as a standalone ant build). It brought them in and at first seemed to recognize all the files with no fuss, but alas, the classpath once again reared its ugly head. The documentation that desribed how to set the classpath was out of sync with the windows that I was looking at while following their directions, and no amount of adding classpaths let it recognize that my imports actually existed. It didn't seem to pay attention to the classpaths set in my ant build files.

It also didn't bring up a lot of the files in the "Files" view of the project. At first I thought that this was because many of the book files don't have package statements, but then I discovered some unpackaged source files that did show up. Quite confusing.

So I think Netbeans has potential, but like many IDEs too much time has been spent on advanced features and not enough on the "initial experience." It doesn't matter that I'm not an idiot and I might be able to figure these things out eventually, I still want an IDE that's idiot proof, because

  1. I don't want to struggle with it; I have other problems that I want to solve and the IDE should be a helper and not something I have to work against.

  2. When I teach, I don't want seminar attendees to get lost in the IDE, either. That's not the problem we're trying to solve in a seminar.

Before you say "well, Eclipse does..." or "Idea is ...", yes, Eclipse is probably the closest thing to ideal, but until now it hasn't supported J2SE5 (or at least, people claim that it now almost completely does -- but I'm using all the J2SE5 features). Also, it's heavyweight, very project-oriented with lots of interesting distracting stuff so I hesitate to get too deep into it because it's too much of a hurdle in introductory classes. But it's free, so in more advanced classes it could make sense. However, by then people are hooked into an editor and are not interested in using a different one because they're not productive, so I say "use whatever you're comfortable with."

For introductory classes, the best luck I've had so far is with JEdit, because it helps without getting in the way of creating one-file exercises.

And JetBrains Idea costs significant money, so I can't just say that's what we're using. On top of that I've had no luck getting a real review copy. Many months after Java One when they said they'd get me a copy right away, they gave me a license that would timeout. Yes, I could afford to buy it, and I do buy products when it makes sense. But I'm sorry, there's a line; I'm not going to invest a lot of effort into something that, if I like it I would end up promoting, just to have the license timeout. So I haven't gotten re-hooked into Idea (although I liked it very much when it initially came out).

(1-6-05: Milani Marketing contacted me as a result of this blog entry, and has promised a non-expiring license. So I may get sucked back in after all. And I've also heard from a reader that the Eclipse 3.1 beta is very J2SE compliant, although I try everything so I would probably encounter the non-compliant parts. It's not clear how much help these will be for Thinking in Java, 4th edition, which is due at the end of February, but one or both will certainly be helpful when working on Thinking in Patterns, slated as the next project).

Thursday, December 30, 2004


This morning I got FindBugs working; for some reason when I tried it some months ago I had problems.

So far it's been helpful, finding a number of things that I either wasn't looking for or had overlooked.

One mistake, which I've reported, was when it said that you should use StringBuilder instead of String when building complex Strings. It turns out that the Java compiler is fairly clever when compiling Strings; it converts them to StringBuilder objects.

Try it. Compile this (based on the code that FindBugs presented as 'bad'):

public class Test {

Integer[] field = new Integer[10];
public String toString() {
String s = "";
for (int i = 0; i < field.length; ++i) {
s = s + field[i];
return s;
Then run
javap -verbose Test
See all the StringBuilder operations?

(Later: see the first comment. Apparently the compiler only does a credible job on very simple cases).

Wednesday, December 29, 2004

This describes my world

A delicate balance is necessary between sticking with the things you know and can rely upon, and exploring things which have the potential to be better. Assuming that either of these strategies is the one true way is silly. Graydon Hoare

Another, even trickier, dimension is deciding when to explore.

Here is an insightful speech on managing change.

Tuesday, December 28, 2004

Finding Unused Imports

I've posted a new article with a Python program that finds and eliminates unused imports in a collection of Java programs. It's brute-force and slow, but you can go away and leave it running and it will do the job.

Thursday, December 23, 2004

Good Essay on Design

Elliotte Rusty Harold's XOM Design Principles describing the principles he used for designing his Java library for creating and manipulating XML is also a great read about design in general and design decisions in particular. One thing I like is his penchant for questioning existing knowledge and practices. For example: "Prefer classes to Interfaces" is a nice one.

Tuesday, December 21, 2004

Blog Spam

I started getting blog spam (what a lovely thing :-() so I've turned the commenting back to "registered users only." But I think it's simple to create an account for commenting.

Sunday, December 19, 2004

Javadoc broken for enums?

Here's another puzzle, stripped down as much as I could so you can see the problem:

import com.sun.javadoc.*;

public class TestEnum {
static void test(Doc d) {
System.out.println(d + " is enum");
System.out.println(d + " is EnumConstant");
public static boolean start(RootDoc root) {
for(ClassDoc cDoc : root.classes()) {
for(FieldDoc fd : cDoc.enumConstants())
for(FieldDoc fd : cDoc.fields())
for(MethodDoc md : cDoc.methods())
return true;

enum Foo { bar, baz }

If you use the following command line:

javadoc -doclet TestEnum -package

Here's the output:

Loading source file
Constructing Javadoc information...

So it sees the enum Foo, but it doesn't seem to recognize it as an enum. Similarly, it sees the fields but not as enum constants.

I'm thinking this is broken, but maybe I missed something. Anyone know?

Saturday, December 18, 2004

New Ant Timout Issue

I just installed the latest version of Ant and discovered that my timeout arguments:

<target name="Applet1c">

Which used to nicely terminate the application (after 4 seconds, in this case), now terminate the application and hork out an exception stack trace. Does anyone know if this is the intended behavior, or a bug? Thanks.

Thursday, December 16, 2004

Because Unanswered Problems Are Always Hard

Ian Bicking does a good job of trying to answer the question I posed in Static vs. Dynamic: "This last point is a major puzzle -- we believe that static type checking prevents bugs, and yet a dynamically-typed language produces very good results anyway."

I like the way he thinks. Perhaps we'll be able to sit down and talk about these kinds of things, or even do an openspace, at Pycon.

Powerpoint is not evil

This is wonderful. It takes Edward Tufte's The Cognitive Style of Powerpoint (which does a thorough job of bashing Powerpoint presentations) and presents it as Powerpoint bullets in a very compelling and succinct way -- I'd rather read the powerpoint bullets than Tufte's version, because I get it in a clear and dense fashion.

Powerpoint and its clones are a tool that makes it easy for anyone to create bullet-point presentations, add graphics, etc. Why are people surprised that if anyone can do it, anyone will? Naturally there will be lots of mediocre presentations and of course poor presenters will use it as a crutch. But people were creating bad bullet points and reading their slides to the audience before Powerpoint came along. People who need a crutch will grab for the nearest one. To suggest that it's Powerpoint's fault for making it easy to create a presentation is silly, and Aaron Swartz demonstrates this in a lovely roundabout way.

Where Are We Stuck?

I have just realized that I have been thinking about (for at least the past several years) issues around "what are we doing just because we've always done it (and are used to it), and what are we doing because it actually gives us true leverage?" Many of these questions have come up from working with Python, which has a very different perspective on many issues, and so I often find myself surprised about the way something actually works vs. my perspective on it.

For example, how valuable is "private," really? It sounds good on paper, but in practice how often do things really get violated? At some level (such as the whole Windows API being exposed and the repercussions of that) access control becomes important, but perhaps the class level isn't the place for that, because often we end up working around access control when trying to use another class. I don't have the final answer on this -- I'm just asking the question.

I've also questioned the efficacy of checked exceptions in the past (not exceptions themselves, which are a clear win as the single form of error reporting, but the enforcement of checked exceptions). I ask questions like this because my real interest is in how we as programmers, development teams and companies can become more productive.

Sunday, December 12, 2004

Java Slipping?

I received a question from Paul Jansen at Tiobe Software, which maintains a site that tracks the popularity of programming languages via search engine statistics. Paul noted that the popularity of Java seems to have fallen in the last 12 months, and wondered if I had any thoughts about why.

Although it is interesting to note that search engines are reporting less queries, I don't know if I would take that one data source as definitive. I note that this month, C is the most popular language on the Tiobe index. Although there are certainly plenty of C programmers out there I have a little bit of a hard time believing that is the case, especially since C++ is broken out from C in that analysis -- in my experience it has been very hard to tell if someone is a C++ programmer still programming in C.

It's certainly possible that Java is falling in popularity. However, I'm not going to draw a conclusion based on search engine feedback.

There are a number of possibilities that might explain lowered search engine stats:

  1. There is an awful lot of noise on the web about Java, and so if you do a search your results may also be very noisy. I know that I do a web search as a last resort, anymore, because it's so much work and so often it's fruitless. So perhaps people are just giving up on web searches and going to other sources.

  2. The aforementioned other sources have been getting better. Sun's own Javadocs are far better than what we traditionally had in C or C++, so those programmers may be compelled to hunt the web while Java programmers can hunt through Javadocs on their local machines. There are a fair number of other electronic resources, such as my own Thinking in Java.

  3. Java programmers may be going to specific web sites such as JavaRanch, JavaLobby, Artima, TheServerSide, etc. to do their searching, in order to produce better results because of point #1. Thus, you will not see this searching on

I'm not saying that it isn't possible that Java has "slipped in the ratings." Just that I won't draw that conclusion based on Google/Yahoo searches alone.


Someone pointed out that this blog had only allowed members to post comments. I've changed this so that anyone can comment. This should make discussions easier, although I'm hoping it doesn't impact the noise ratio, which has been good so far (there's also an option to restrict commenting to "members of this blog" only, although I haven't explored what that means).

Saturday, December 11, 2004

Language influence

From a reply to an email query:

It's always difficult to know when code clarity/maintenance problems arise from the language vs. the people programming in it. The success of Java is partly due to getting rid of many of the difficult language aspects of C++, but I think it also "encourages" a stricter form of programming which helps less experienced programmers to write somewhat better code. At least in theory; I've seen horrible Java code written by master's and Ph.D. students. However, I'm not yet convinced that a more constraining language really helps when being used by less experienced programmers. In the end I think it's the team culture and the desire of the individual programmer towards self-improvement and clarity of expression that will make the difference.

Thursday, December 09, 2004

XML Odyssey

I've posted a new article about some experiences creating XML with Python.

Monday, December 06, 2004

Multiple Return Statements

Ted Hill writes:

Hi Bruce,

I attended your design seminar in Crested Butte this summer. Thanks for hosting a great seminar, I thoroughly enjoyed the entire experience.

On my current job we work in Java and are putting together a list of "best practices" for our company.

The idea is that we will run the PMD inspection tool on our Java code.

One inspection that some of our developers favor is:
"There must only be a single return statement within each method"

PMD classifies this as a "controversial" inspection. They do not comment on why it is considered controversial.

I notice that in your book "Thinking in Java" you have several examples of multiple returns within a method.

I personally favor using it for 'breaking' out of loops as you do on the top of pg 490 (Thinking in Java 2nd Edition) in the code for demonstration hashed Map.

Here is the method:

public Object get(Object key) {
int index = key.hashCode() % SZ;
if(index < 0) index = -index;
if(bucket[index] == null) return null;
LinkedList pairs = bucket[index];
MPair match = new MPair(key, null);
ListIterator it = pairs.listIterator();
while(it.hasNext()) {
Object iPair =;
return ((MPair)iPair).getValue();
return null;

So I am wondering:

1. What is your personal feeling about the "single return rule"?

2. Do you know anything about the history/background of this rule/inspection?

I happened to be thinking about this recently when refactoring some code, noticing that taking some kinds of inline code and turning it into a method with multiple return statements can really clean things up. It is definitely an idiom that I find valuable for that very thing.

I believe the history of this may come from Dijkstra's famous "goto considered harmful" statement, which has been massively misunderstood, in my opinion. I think the problem that Dijkstra was talking about was wild jumps from any part of the code to any other part, without constraint. The closest thing we have in Java is the labeled break and labeled continue, which you'll notice are jumps, but are very constrained.

I think that multiple return statements only seem to be jumps. But they all have to go through the "return chute" and they must return the specified type, the stack gets cleaned up, finally clauses are executed, etc. So not only do I find them completely safe, but their benefits in terms of clearer code are significant.

The counter-argument to this may be that it could be hard to see all the places where you exit a method if they are distributed throughout the method. My feeling is that if this is the case then your method is probably too large and complex and that you should probably refactor it to make it cleaner. Or you should choose not to use multiple returns for that method. Enforcing "no multiple returns" because you might end up creating a confusing method is a bad policy, I think. If someone is going to create a confusing method, preventing them from using multiple returns probably won't do any good, and it will certainly harm the clarity of other methods.

Guidelines and tools to point them out are helpful, but at some point programmers need to develop a sense of good code. I don't think there's any way around that. The only way to enforce it, I believe, is code reviews, ideally in a group so that everyone can learn from them (as noted in a previous entry, this can be tricky because you want to focus on improvement rather than making people feel bad).

Friday, December 03, 2004

Java 5 Class File Format Puzzle

I've posted a New article about the changes in the Java 5 class file format (which I can't seem to figure out). Please add a comment on that article's wiki page if you know the answer -- thanks. (Later: got the answer from a reader. The web works.)