Another NetBeans+Ruby Preview

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

There have been several great releases lately, and I'm remiss in covering them. However, they've been covered in great detail elsewhere. First, NetBeans Visual Web Pack shipped on schedule, bringing Creator functionality to NetBeans, along with new support for Java EE 5. Second, Mustan... ^H^H^H^H Java SE 6 shipped today. It's a great release. The number one reason I install it whenever I get to a new system is that I need the improved font aliasing built into Java2D - and of course, the gray-rect-fix. However, there's another reason I crave the release even when I'm on OSX: @Override. Yes, @Override has been there since Java SE 5, but in Mus... Java SE 6, you can use it to indicate that a method should implement an interface method, not only a method inherited from a super class. (Which arguably @Override should have meant all along.) Now if only Apple could ship an update to its dated September pre-release...

Anyway, I have an excuse for being late to blog. In addition to some work on JSR 273 which is coming along nicely, I've been coding away to get more Ruby tools support for NetBeans.
Charles and Tom will be demoing JRuby 0.9.2 (which just shipped, congratulations!) at JavaPolis this week, and showing the NetBeans tooling in the process.

I thought I would share another screenshot with you at this point. This shows the new language embedding. Notice how there's Ruby inside string literals, rdoc tags inside comments, string escape codes highlighted specially, and so on.

This is all made possible by the new Lexer API in NetBeans. It's really nice to build on top of it; writing incremental
lexers is a snap. This is part of NetBeans 6. If you've been using recent milestones, you might have noticed that all our javadoc is highlighted in your Java files. This is not done through hacks in the Java lexer - it's done through embedded sections where the Java comment tokens are then sub-tokenized by a Javadoc lexer. It's not just done for javadoc - if you look at your String literals you'll notice the same String-sequence highlighting that I'm showing for Ruby above. It only changes the font to bold, so it's a bit subtle. Perhaps something we should tweak before the release.

In Charles' pre-review of the Ruby support,
he wrote some very nice things about me ("Tor Norbye is a programming machine", etc.) Thanks Charles! While it's nice to get all the credit, I really want to point out that this is all made possible
because of the tremendous work on the editing infrastructure for NetBeans 6, by a number of
great NetBeans engineers. Not just the Lexer, which I've described above, but all the other things I've relied on, such as the
infrastructure for semantic highlighting, asynchronous parser task scheduling, and so on. I would love
to give individual credit here, but I'm not sure exactly who to attribute all the work to, so I'd rather credit
all of you rather than snub anybody. Not to mention the fact that I have an excellent Ruby AST to work with, thanks to JRuby!

Several of you asked after my last screenshot where or when you can download the code for this. It will show up in NetBeans soon, but since the work started in closed source, I have to follow the established open-sourcing process. It's in progress, but I can't make specific predictions about when it will be done.

Posse Night

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

We had a fun in-person recording session for the Java Posse last night over at Joe's house. This was hopefully the first of many to come, since Dick started working at Google yesterday, and is in the process of moving from Georgia to California. Since we're all swamped with work and life it was definitely an unprepared podcast, but we eventually got into some technical discussions. And we accumulated more clips for the outtakes reel.

Here's the crew, from right to left: Dick, Carl, Joe, me.

(Other sizes at Joe's flickr page).

Semplice Is Dead. Long Live Semplice!

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

My co-conspirators on Project Semplice, John Kline and
Herbert Czymontek, have both recently left Sun. Rest assured, I'm not going anywhere. But where does that leave Project Semplice?

Well, the spirit of the project was to support scripting on the VM. We started our research with BASIC, but the vision all along was to design things in such a way that we could support multiple scripting languages, without starting from scratch each time. The tooling aspect was my responsibility, and I'm happy to say it has not been in vain. With the hiring of the JRuby developers, I've been focusing on how to adapt everything to support Ruby, and it's going really well.

I'll post a second blog entry on that shortly.

Back to BASIC. Like most software at Sun, open source is the obvious strategy and we have started the process. On the other hand, just "dumping code on the community" is not likely to be successful, so we're looking for interest and support to decide how to proceed.

In any case, as the blog title suggests, the project is not dead. It was a research project, we've learned a lot, and the technology is now forming the basis for some great new scripting tools coming your way very soon. Rising out of the ashes, so to speak! We'll have more to show at JavaPolis in a few weeks, so keep your eyes peeled!

NetBeans + Ruby = True

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Click on image for full size. Some things to notice: semantic highlighting (for example, parameters are shown in different colors than local variables), code completion, mark occurrences (other uses of the length method under the caret is highlighted), ...

You'll see more at JavaPolis... and on this blog!

Java Open Sourced - Podcast Special

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

It seems I'm late to join the blogging party; just about everybody has covered the news already. In the unlikely
case that you haven't read about GPL'ed Java, read just about any blog on blogs.sun.com (and many on java.net). The main resource page is http://www.sun.com/software/opensource/java/.

We've got a special episode dedicated
to this on the Java Posse. It's an hour interview with
Mark Reinhold,
Rich Sands and
Eric Chu
discussing just about everything related to this. Please check it out
(and digg it).

Using JDK 5 language features in Creator

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

As you're probably well aware of, there were several important releases this week. First, NetBeans 5.5 was
released. This has been covered extensively by other Sun bloggers
so I won't repeat the highlights here - just check it out if you haven't already.

Second, a number of add-on packs for NetBeans 5.5 were released. A pack is a cluster of plugins.
One of these is the

Visual Web Pack, which basically bundles all the visual web page design functionality from Creator into NetBeans. With this, you can create pages Creator style alongside other NetBeans features, such as the profiler, or the UML tool, or the enterprise XML support.

There's another big reason why even Creator users should try the visual web pack (which is in technology preview state, not a final release like NetBeans 5.5.). It offers new support for Java 5 language features, as well as Java EE 5 support. I took it for a quick testspin and thought I would show it in action here.

If you download NetBeans 5.5, and then the Visual Web Pack installer, you can create Visual Web Projects. Unfortunately, out of the box, it will only offer to create J2EE 3 and J2EE 4 projects. The reason for this is that NetBeans is only bundled with the Tomcat web container, and Tomcat is not adequate for Java EE 5 projects. Thus, the trick is to also download a Java EE 5 capable app server such as Glassfish or its cousin, the Sun Application Server. Once you've done that, and you select it as the target in the new project dialog, you are able to create a Java EE 5 project. Hopefully we'll have everything ready as a single bundle so that out of the box, you're defaulting to Java EE 5 projects and Java 5 source. Here's the configuration portion of the New Project wizard (click Manage to register additional web servers).

Let's create a simple web app which utilizes Java 5 features. It will be a simple page which lets you provide the name of a Java class, and then the methods (possibly generic) of the class are displayed. Here's what the web app looks like in the designer:

Here's the button click event handler:

Note that we simply use the error method to log messages for the page; these are all displayed in the group message component. This is a very simple way to log messages for ourself during debugging. You should always have a Message Group component, on every single page of your application, during development. This will make it immediately obvious if you have validation errors or other problems that might otherwise silently occur and leave you scratching your head.

When we run and try it with some sample data, here's the result which shows Java 5 language features in action:

The next step is to play with Java EE 5 features mixed with JSF. That will have to wait for another day; I've gotta get back to my day job, which I'll blog about soon.

Code Advice #14: Don't initialize fields to default values

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

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

If you've been coding in C, you've probably picked up the habit of initializing all your fields:

char *foo = NULL;
int bar = 0;

This is necessary, because in C, memory can be left uninitialized, so there's no telling what value foo will have before it is assigned something.

In Java, however, the language specification clearly defines default values, so virtual machines will for example always initialize reference fields to null.

Specifically, this means that code like the following is redundant:

private int foo = 0;
private Bar bar = null;
private boolean baz = false;

The alternative form of initializing the fields explicitly in the constructor, is the same:

private int foo;
private Bar bar;
private boolean baz;

public Foo() {
foo = 0;
Bar bar = null;
baz = false;
}

You can leave out the above initializations, and the program will behave the same way. Carl Quinn once convinced me that this was more readable, so I picked up the habit, and I now swear by it. On the one hand, you can argue that leaving the explicit initializations in is more readable because you're making it really clear what it is you are intending. On the other hand, Java programmers quickly learn what the default values are and understand that an uninitialized field is the same as a nulled out field.

It turns out that the two forms are not exactly identical! If you disassemble the above code, you'll find the following bytecode is generated:

4:   aload_0
5:   iconst_0
6:   putfield        #2; //Field foo:I
9:   aload_0
10:  aconst_null
11:  putfield        #3; //Field bar:LBar;
14:  aload_0
15:  iconst_0
16:  putfield        #4; //Field baz:Z

If you leave out the initializations, none of the above bytecode is generated. In a simple microbenchmark there was a measurable time difference (about 10%) for the case where a handful of fields were initialized versus leaving them uninitialized, so it's clear that Hotspot doesn't completely eradicate the differences here. (<speculation>Perhaps it just zeroes out the whole object memory block when allocating a new object, relying on the default values to all be represented as zeroes natively, and this is done even when all fields are later initialized?</speculation>)

Obviously, speed considerations is not what should be the deciding factor here. This was a microbenchmark doing nothing other than construct objects with and without initialization - it's unlikely that you'll find a measurable difference on a real program. What really matters is readability. I should also point out that Findbugs will treat these two scenarios differently. If you print out a field value in the constructor, it will warn about an uninitialized field if the field was not explicitly initialized in the field declaration.

I can see arguments both for and against explicit field initialization, but I think this is one of those cases where convention wins. I personally find code cleaner and more readable when you leave your fields with implicit rather than explicit initialization.

P.S. Remember that null fields are often a bad idea and should be initialized to null-objects!

NetBeans Plugins I Use, Part 5: Build Monitor

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

(Parts
1,
2,
3, and
4.)

The Build Monitor plugin for NetBeans allows you to see the status of continuous builds, right from within the IDE. The Build Monitor works with several continuous build systems - CruiseControl,
Hudson,
and of course the NetBeans continous build.
You can monitor multiple build sources - all you do is name your build and point to an RSS feed where the plugin can fetch the build status. Each build is then displayed right in the IDE status bar. You can set the polling frequency yourself; I've set mine to check every minute! Here's what this looks like:

This is obviously what you don't want to see - while the NetBeans continuous build is fine, the second continuous build is currently failing, as indicated by the red ball. In this case, just click on it to open the browser for the corresponding build status page - where you can for example click on the Console Log to see the build script output.

You can grab the Build Monitor plugin from the Beta Update Center, or from nbextras.org.

Yesterday, I set up a continuous build for the project I'm working on. It was really simple. All I had to do was download
glassfish, run its setup script, download Hudson, and drop the hudson.war file into the autodeploy directory in Glassfish. Then I just went to localhost:8080/hudson and from there I could set up a build using a simple web interface. I just needed to point to my CVS server (Subversion is supported too) and my ant scripts, and voila - continuous builds. If you want to take a look at what Hudson looks like in action, visit this page where you can see Glassfish itself being built in a Hudson setup.

Tips:

1. It's a bit tricky to configure the build monitor. The trick is to open the options, then go to the Advanced Options, locate the Build Monitor item, right click on it, choose new build monitor. Then set the RSS feed to the build failure (or all builds) feed you want to use - Hudson displays it right in the status page.


2. I had to restart the IDE before the build monitors showed up in the Status Line. We should set the needs-restart property of the auto update bundle.


3. I had problems using the most recent snapshot of Hudson so I grabbed a slightly older version and things were fine.

Thanks to Tom Ball and Jesse Glick for this plugin.

Working with classes that (unfortunately) call overridden methods from their constructors

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

I was struggling with a problem today, and I found a pretty decent workaround. Since initial googling hadn't turned anything useful up, I figured this writeup might help others who search for it in the future.

In essence, the problem boils down to "How can you initialize your own object before the superclass constructor has run?"

Let's express this in code - I've changed the example to a simple domain to make the intent obvious:

/** Represents a building, such as a house, a garage, etc. */
public class Building {
public Building() {
// Do something with the result of getColor(), such as
reservePaint(getColor());
}

protected abstract Color getColor();
}

The above class is the "framework" class I'm trying to extend. I do not have the option of changing it or extending something else; this is the integration point.

Note the error above: the constructor is calling an overridden method. This is a
well
documented problem. Previous uses of the above class had probably not run into it, because most usages would be something like the following:

public class Skyscraper extends Building {
protected Color getColor() {
return Color.LIGHT_GRAY;
}
}

Since the overridden method typically returns a constant that is independent of the subclass object being properly constructed, calls from the superclass constructor did not cause problems.
The problem was that in my case, I'm dynamically constructing many different types of Buildings, so I want to parameterize the getColor() method:

public class PaintedGarage extends Building {
private Color color;

public PaintedGarage(Color color) {
this.color = color;
}

public Color getColor() {
return color;
}

Unsurprisingly, this fails at runtime.
(When you construct the PaintedGarage object, the superclass constructor, Building(), will be called before the PaintedGarage constructor is called, and when it
calls the getColor() method, it will read the color field which has not yet
been initialized.)

With that long motivation: What can we do about this? Following the Effective Java practice of not calling overridden methods from the constructor is not an option. Remember, that is done in the superclass, and that is a class we have no control over - it's part of the framework we are plugging into.

In an earlier version of this, I was already computing classes on the fly (using a byte code generator library), so it was simple for me to simply inline the literal return value in an overridden version of getColor.

However, I no longer need to do that for other purposes, so is there a way for me to ensure that getColor gets initialized by the time the super class constructor calls it?

Yes!

The trick is to use an inner class. The process is as follows.
First, file a bug against the framework you are using to get the constructor behavior changed.
Second, try something like this:

public class PaintedGarageFactory {
private Color color; // Moved out of PaintedGarage and into enclosing (not super!) class

private PaintedGarageFactory(Color color) { // Use factory method below
this.color = color;
}

class PaintedGarage extends Building {
public PaintedGarage() {
}

public Color getColor() {
return color;
}
}

public static PaintedGarage create(Color color) {
PaintedGarageFactory factory = new PaintedGarageFactory(color);
// Notice how the outer class is fully constructed before the
// inner class (and its superclass constructor) is built.
// Each factory instance constructs PaintedGarages of a particular
// color (and could be reused etc.)
return factory.create();
}

private PaintedGarage create() {
return PaintedGarage();
}

}

What this has done is move the parameters that need to be initialized before the superclass
constructor is run, out to the outer class. These are obviously initialized before the innerclass
is constructed.

This is not a good way to write code, but it solves the immediate need: You've
provided an implementation of the super class that is properly constructed as far as the
superclass constructor is concerned.

Don't forget to get the framework fixed.

Tabs Are Evil, Part 3

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

For part 2, see here.

We've got a new

forum set up for the Java Posse. There's quite a bit of activity there already. One entry in this thread argues once again that there is nothing wrong with tabs and that they are a good way to express indentation.
(We keep mentioning that Tabs Are Bad on the show). I've gotten similar feedback from my previous anti-tab blog entries.

A couple of weeks ago I was taking a look at the findbugs source code, and here's what I saw:

Findbugs follows a coding style where it uses tabs for indentation. In the above you can see that the tabs are really standing out since I have them highlighted with the NetBeans fixtabs module.

The thing to notice is that there are lines where spaces are (probably accidentally) used for indentation. For example, line 2, the beginning of the method signature. And also on line 3, where there is first a tab, then eight spaces, to indent the throws clause.

If this source file is interpreted with tabs expanded to anything other than 8, the code will not be aligned properly. And this is precisely what is problematic about Tabs. Tabs, in most editors, are visually indistinguishable from spaces. Thus, when you're editing, you can't tell that you've accidentally just indented a line with spaces. Obviously, developers might do this by accident, since they already hit the spacebar to insert whitespace between symbols. You can't have the IDE automatically insert tabs instead of spaces. But you can certainly do the opposite. And if you do, you'll avoid problems like these.

Welcome JRuby

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Sun has hired the two primary JRuby developers,
Charles Nutter and
Thomas Enebo.
This is great news for JRuby, because it will now be their full time job to work on it.
(JRuby is an implementation of the Ruby language that runs on top of the Java platform.)

This obviously fits well with our strategy to support multiple languages on the JVM, and in particular,
dynamic and scripting languages. In fact,
Charles and Thomas is joining the group I'm in, so hopefully a lot of the tool support we have built to support BASIC will also benefit JRuby. Going forward there will probably be a lot of cross pollination.

Welcome to Sun, Charles and Thomas! Charles has already blogged about joining Sun.

Creator On Speed, Serious Speed

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Hotfix 2 has been released for Creator. The focus of this patch release has been performance, and there are some significant gains.
Here's
one testimonial from the Creator forum after the bits were released this morning:

This is awesome. I have experienced orders of magnitude improvement in performance - specially building and deploying the apps. It used to take 3 mins., now it takes less than 10 secs.

The main performance fixes were in the source modeller, so project open and editing is where the speedups are to be found.
Sakhti Gopal in Creator QA has done a lot of analysis of the performance improvements and provides further details on the improvements. Opening pages, switching from source to design view etc. is at least twice as fast, and in many cases several times faster.

The Tutorial Divas on the Creator team also provide coverage; they've measured various tasks on a moderate project, and as you can see the performance improvements are dramatic. They are using percentages rather than speedup factors. What is a 97% improvement? Some people think of "100%" improvement as doubling something (or when appropriate, halving something). But here it means that it was reduced by 97% of the original amount; thus it is the same as a 32x speedup!! Adding a table to the first page for example used to take 16 seconds, it now takes 4 seconds - a 4x speedup.

If you've been using Creator 2 and have been dissatisfied with the performance (you were not alone), hopefully this will make you much happier. If the earlier performance turned you off from Creator 2, give it another chance. This is not the end of the performance work for Creator; a larger rearchitecting of the Java source model in our tools is being performed as a foundataion for NetBeans 6.0 (to also accomodate a lot of new cool Java source editing features). In the next Creator generation, this will allow Creator to be a lot more efficient both in CPU and memory usage. Today, Creator does not use NetBeans' source model; it has its own, which means there are two source models that need to be kept in sync. What Hotfix 2 did was ensure that this syncs are only done when necessary. And what a difference it makes!

How do you get it? Use the Update Center in Creator. If you don't have direct internet access from your Creator installation, you should be able to download the update by following links from the Creator site.

More on Nullness

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

The other day I
wrote about using annotations to state your intent regarding null for fields, parameters and return values. This can help static checkers like
findbugs find flaws in your code, where you fail to check return values for null where that is known to be risky. (In fact, findbugs does not only base knowledge of nullness on your use of annotations; it also has a builtin database of system API null behaviors, since these classes have not been "instrumented" with nullness annotations yet.)

I did however mention one big problem: These annotations are not (yet) standard - so you'll need to choose to use them from somewhere - and add third party imports to all your source files, add a foreign jar to your build, etc. Findbugs' set of annotations is probably as good a candidate as any. But while the annotations are licensed under LGPL, which should be fine for most of us, some companies (or at least their lawyers) are weary of mixing GPL anything with proprietary code.

Our lawyers are generally fine with LGPL usage, but I was still wondering if there was a way I could "isolate" myself by using an annotation from my own project, and then somehow tie that to a standard annotation in a single place. If annotations were like classes this would be easy - I could simply extend the findbugs one and I'd be done. But annotations don't work that way. So I thought I'd take a look at findbugs internals and see what's going on.

And I was surprised, and happily surprised at that, to discover that findbugs is very tolerant in how it deals with nullability annotations. It is not favoring its own annotations. In fact, all it checks for is whether the annotation base name matches the name findbugs has chosen. This was probably done deliberately, to ensure that findbugs works with code annotated for other tools, such as IntelliJ. This is really a great idea - and it doesn't seem risky to me; I can't think of many other uses for an annotation named "CheckForNull" or "NonNull". Of course, if a problem ever arises they can always update findbugs to be more discriminating for users who want to use home grown annotations where those names mean something else.

So, you can simply define your own project wide nullability annotations (they are simple marker annotations with no members), and then findbugs will happily do its magic. Worked like a charm for me:

Null Handling: Much ado about nothing, literally.

P.S. For more about the built-in set of null knowledge of Java standard APIs, see the class NullnessAnnotationDatabase in the findbugs source distribution (which handily comes distributed as a NetBeans ant-based project - thanks!)

Writing internationalized web applications with Creator

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

This is just quick a pointer to a great blog entry I came across written by Gregory Murphy (from the Creator team) which tells you how to work with resource bundles in Creator. Until now, writing a web application with proper resource bundle lookups has meant giving up some WYSIWYG aspects, because the <f:loadBundle> tag is not interpreted at designtime. But with Gregory's solution, we finally have a simple way to get designtime display of the localized text.

Code Advice #13: Don't spot-fix null pointer exceptions

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

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

One pattern I've seen some developers use is to respond to NPE (NullPointerException) bugs by inserting a null pointer check at the location of the NPE. Frequently this will be accompanied by some sort of comment like "Why is this null?".

My advice is simple: Leave the NPE until you've investigated the root cause. You need to have a null-policy. Decide which references can be null, and which can't. The problem with spot fixing an NPE is that in many cases, you've only moved the bug from one place to another. And in particular, you've moved the symptom further from the cause.

First, decide whether for your own methods, you ever allow null as a return value. Instead of returning null for an empty or uninitialized list for example, always return an empty list. That doesn't mean you have to create an "unnecessary" object to indicate null; you can call Collections.emptyList(). This will return a shared object which is used for all empty lists - and through generics you still get to keep type checks:

public static final <T> List<T> emptyList() { ... }

You also need to make sure that you handle nulls properly at the boundaries of your own code. If you're calling a library, make sure that the return values are only null if your program universally allows null for the particular piece of data being passed around. If you're providing an API, make sure that you either handle null parameters (if you want to be lenient), or throw IllegalArgumentExceptions if you expect clients to be well behaved. (I don't throw NullPointerException.)

This is clearly asking a lot of you. You need to keep track of which parameters and fields are allowed to be null. For that reason, it's smart to pick a simple policy. However, with tools we should be able to do better. Annotations are ideal for this. You can annotate parameters and fields to indicate whether or not they are allowed to be null. With that information, tools can check whether your code is correct (and even without tools, when you're calling an API, these annotations help document what is expected of you in a more accurate way than English javadoc descriptions, which frequently say nothing on the subject.) For example, if the static checker discovers that you are calling a method with a null parameter where that parameter is known to not be nullable, it can complain and alert you to the potential problem.

Annotations for nullability will probably find their way into the standard set of annotations. For now, you'll need to use some third party libraries and sprinkle your code with third party class names. That may be a bitter pill to swallow.
(Update two days later: See this entry for a solution.)
On the other hand, it may pay off. These annotations allow you to state your intent, and without that additional information from the programmer, tools cannot easily help you track down NPE problems.

Here's findbugs' set of annotations related to null checking - CheckForNull, Nullable, NonNull. Obviously, findbugs can also do the static analysis to alert you to errors in your program where you are violating the constraints. IntelliJ has support for this built in. It would be nice if NetBeans would do the same, but on the other hand, NetBeans tries hard to follow the JSR standards closely, so perhaps this will have to wait until we have java.lang.Nullable. In the mean time you can use the findbugs NetBeans plugin, available from nbextras.org. Just grab the annnotations.jar and add it to your project, and then code completion will find the annotations and handle imports for you.

End of summer

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

I apologize for the lack of activity on this blog the last couple of weeks. I've been spending a lot of vacation days this summer. Unfortunately I came down with a stomach flu, so that has put a damper on the festivities. I'm finally starting to feel better so I'll take a stab at another blog entry.

Code Advice #12: Use final on constructor and setter parameters

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

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

In my previous
code style entry I recommended a setter pattern where the parameter is identical to the field name, as in the following:

void setTemperature(int temperature) {
this.temperature = temperature;
}

I mentioned that there is the potential of a bug here if the parameter name has a typo; the code will compile just fine but not work as expected since you will be assigning the field back to itself.

There is another problem that can occur when you are "masking" the field with a parameter name. What if you add some code where you don't realize that the name is referring to a parameter, not the field? If you try to update the field, you will update the parameter instead:

void setTemperature(int temperature) {
this.temperature = temperature;
...
... // Other code here
...
if (temperature < -273) {
temperature = -273;
}
}

Ooops!

This motivates another good pattern (besides validating before assigning): Use the final modifier on parameters in constructors and setter methods:

void setTemperature(final int temperature) {
this.temperature = temperature;
...
... // Other code here
...
if (temperature < -273) {
temperature = -273; // Won't compile
}
}

The final modifier can be used in many other contexts as well. You can place it on fields to indicate that they are constants, not variables. You can place it on classes to indicate that they cannot be subclassed. You can place it on methods to indicate (and enforce!) that they cannot be overridden. In the old days, some programmers used to sprinkle final all over their code to get a performance benefit.
Be careful here - the performance benefit is typically not significant, and you can introduce some tricky bugs into your code. final should only be used on fields that truly are constant in a logical sense, not just on fields that happen to not be written to yet. This is especially true for public fields, because final fields get copied into clients that access the field. That's right - if you change the value of a constant, any clients that have already been compiled against a previous version of your class will continue to use the old value of the constants, until they are recompiled.

Using final on your method parameters on the other hand has few if any disadvantages. It does not show up in the signatures for your methods. It has no impact on anyone overriding your methods. It does not show up in the javadoc. It simply allows you to state the intent of parameters. And in constructors and in setter methods, parameters should reference state that is to be copied into the object. The references themselves should not be modified, and any attempts to do so will typically be bugs of the form shown above.

Static analysis tools can find the above bug too. PMD will flag cases where you are reassigning any of your parameters. Thus, it is making the assumption that all parameters are final. I've found that to be a bit too restrictive (for example, I sometimes want to adjust a parameter to a method based on some initial validation), so I don't like to run with that rule. Clearly it's easy to work with that assumption - rather than ever reassigning the parameter, copy it and work with the copy. However, marking parameters as final feels right - it's stating the intent of the parameter in setters and constructors, and stating intent is a good thing.

I'd like to get NetBeans to automatically use this pattern when encapsulating fields for me... Anybody listening?

P.S. Thanks to Rick for the inspiration for this entry.

(Confession: This pattern is a recent habit for me. We'll see if it stands the test of time.)

My first BASIC compiler

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

I started my programming "career" on a
Dragon 32
microcomputer in 6th grade. It had 32K of RAM, although once you turned the computer on it would launch a Microsoft BASIC interpreter which left 24K for your own programs. I spent countless hours on that computer in 1984, 85 and 86, writing a lot of BASIC code.

It's fun to have looped around in my career and to suddenly be working with BASIC again - in the Semplice project. If you missed it, my coworker Herbert was interviewed on the Java Posse. In addition to talking about supporting BASIC on the Java platform, he talks about supporting other VM languages in general. It's a good, meaty technical talk.

Anyway, back to BASICs. I have moved recently, and as part of the large cleanup, I had to decide what to keep. I found a stack of old computer magazines that I had held onto. These were British computer magazines I subscribed to - and were largely responsible for teaching me English. Understanding the articles in those magazines were a lot more inspiring than the stories we were encouraged to read in English class!

I realized I can't drag these magazines with me forever, so I decided to thumb through them one last time before throwing them in the recycling bin. And in one of the magazines I noticed a part of a page had been cut out. Major flashback! This was the advertisement for the first piece of software I ever purchased! The missing piece was the order form I had cut out and mailed in. And what was this product? A BASIC compiler! (I've scanned in a portion of the ad on the right.)

Yep, I was programming BASIC, but performance was slow, and I realized (from all those computer magazines) machine code was where I wanted to be. I thought a compiler would do the trick - so I bought it. My programs did execute faster - but I didn't end up learning assembly code until I got a Commodore 128, and later a Commodore Amiga. Ah the memories. The advertisement has a picture of the tape cover (I didn't have a floppy drive until the Amiga), just the way I remember it.

Code Advice #11: Initialize fields using the property name

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

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

How do you initialize fields in a constructor? And how do you initialize fields in a JavaBean setter method?

Here's the, in my opinion, correct way to do it:

void setTemperature(int temperature) {
this.temperature = temperature;
}

The same scheme is used in constructors.

There are various other ways to do this. Dave Yost
argues that you should use the following pattern:

void setTemperature(int newTemperature) {
temperature = newTemperature;
}

Another coding style guide recommends that you
"consider using the prefix a or an with parameter names. This helps make the parameter distinguishable from local and instance variables":

void setTemperature(int aTemperature) {
temperature = aTemperature;
}

A third scheme I've seen quite frequently is choosing a parameter name that is an abbreviation for the property name being set:

void setTemperature(int temp) {
temperature = temp;
}

A fourth suggestion is to use underscores as suffixes
on the field names themselves:

void setTemperature(int temperature) {
temperature_ = temperature;
}

So, why do I think my way is the right way to do it, and not the other alternatives shown?
As always, the first reason is that the this.x=x pattern is the most common way to do it - and as a consequence more developers will find your code clear and pleasant to read.

However, there are logical reasons to do it this way too. The primary reason is that the signature of your method is part of its API! If this is a public method, the parameter should be included in the javadoc with a @param tag. With the first three alternatives, the parameter names are newTemperature, aTemperature and temp. I think temperature is a better parameter description. Yes, it's true that for a setter method like setTemperature, it's not that important what the parameter name is since it's obvious what it's for. But when you're dealing with a constructor, you do need to be descriptive. And newTemperature is not a proper name for an initial state. You could switch to using initial instead of new as a prefix, but in addition to being wordy you now have different schemes for constructors and setters. Having one approach to both is beneficial since it keeps things simple.

The last alternative does let you use a good parameter name - the same one that I'm proposing, temperature. However, it has another disadvantage in that it's using an underscore_ as a suffix for the field name. This to me smacks of Hungarian notation, although rather than describing the object type with a prefix it describes the symbol class with a suffix. I don't like it since it makes the code less readable, but I suppose that's a topic for a whole other discussion. In short though, most Java programmers avoid underscores in all symbols but constants (such as public static final int WATER_BOILING = 100;).

The proposed style does however have one problem. It relies on "polluting" the namespace in the constructor or setter with a parameter which hides the field name. In the following code, temperature refers to the parameter, not the field:

void setTemperature(int temperature) {
this.temperature = temperature;
}

What happens if you accidentally write the wrong parameter name - either by a typo, or by writing a similar name and not noticing that the parameter name is a different variation of the field name?

void setTemperature(int temp) {
this.temperature = temperature;
}

The above code will compile just fine. However, it is probably not what is intended. If you call this method, the temperature field will not be updated - you are simply assigning the current value of the field to itself.

Luckily, your programming tools will find these errors for you. Obviously, a tool could warn you that the temp parameter is unused, and that would clue you in. But most people do not want warnings on unused parameters, since they occur frequently in a lot of code - especially when you implement interfaces.

However, the code above has a "self assignment" - the left hand side of the assignment is identical to the right hand side. This code is obviously redundant and can be removed - but more importantly, it usually points to an error of the above form. Therefore, if you run findbugs (NetBeans plugin here), it will clue you right in to the problem:

Jackpot can find self assignments as well. The following code is
courtesy of Tom Ball and will be part of the Examples shipped with Jackpot (and hopefully be built in as well).

import org.netbeans.jackpot.query.Query;
import javax.lang.model.element.Element;
import com.sun.source.tree.AssignmentTree;

public class SelfAssignmentQuery extends Query {

public Void visitAssignment(AssignmentTree tree, Object p) {
Element lhs = model.getElement(tree.getVariable());
Element rhs = model.getElement(tree.getExpression());
if (lhs == rhs) { // Elements are unique so == is okay
addResult(getCurrentElement(), tree, "self-assignment found");
}
return super.visitAssignment(tree, p);
}
}

Armed with the right tools, the this.x=x pattern works because you get to use the "right" parameter name, and the tools will catch your mistakes.

Hot hot hot!

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

It's unbelievably hot where I live! 111 degrees Fahrenheit in the shade - that's 44 degrees Celsius. My thermometer said 115 F, and I can believe that since I live in a part of town that is hotter than downtown where the official temperature is taken.

This of course is not conducive to working! Unfortunately, there is nothing good on TV - and I've seen all the movies in the movie theaters that according to critics are worth seeing. Not a large percentage might I add.

At least we get cool nights in California, so I can spend the morning hours web surfing a bit until it gets unbearable.
Oliver Widder has posted a cartoon related to coding styles (a frequent topic on my blog). A number of people have expressed an interested in this, so it will probably be the topic of an upcoming Java Posse episode.

P.S. My favorite drink to consume in the heat is the Mojito. It's made with ice, mint, rum, lime, and sugar. Unlike the original recipe (google it), I actually blend all the ingredients in a blender such that you get pureed mint leaves in the drink. This gives it a stronger mint flavor - which is a good thing!

Code Advice #10: Place brackets with the declaration type, not the name

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

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

The most important code style rule is that when you modify somebody else's code, you preserve the coding style in that file. Even when it hurts. The only thing worse than an "incorrectly" styled source file is an inconsistently styled one!

One of my coworkers writes Java code in a very C-inspired way. One of the habits I have difficulty with is the bracket placement for arrays. I thought I would dedicate a blog entry to this, because it occurs in many other code bases. A quick scan revealed a couple thousand matches in the JDK source code (which, granted, is a tiny fraction of the overall codebase).

Briefly stated, the correct way (as far as I'm concerned) to place brackets in an array declaration is with the type, not with the variable name. Therefore, this is okay:

int[] scores;

and this is not:

int scores[];

Here's a real-world example, from String.java:

@Deprecated
public String(byte ascii[], int hibyte, int offset, int count) {
checkBounds(ascii, offset, count);
char value[] = new char[count];
...

As you can see, there are two violations here - both in the parameter usage, and in the declaration
of local variable "value".

Most of you will probably just nod at this and move on, since it's what you're already doing. But if there's one thing I've noticed, it's that coding style blog posts always generate controversy - and that especially those of you doing it the Other Way are reluctant to change.

So, let me spend a couple of paragraphs arguing why you should place the brackets with the type name, not the variable name. The most obvious answer is that brackets-with-type is what by far most Java developers are using, so you should simply do it to make your code consistent with the accepted practice.

However, it does have some logical reasons too.

First, let's take a look at a method declaration that returns an array - this is java.util.Arrays.copyOf:

public static int[] copyOf(int[] original, int newLength) {

Notice how the brackets appear with the type declaration. You do not have the luxury of moving them to the end of the line, or even just past the variable name:

public static int copyOf[](int[] original, int newLength) { // WRONG!

Note that if you have code like this:

int[] a, b;

Here both a and b will be integer arrays. This is different than in C
where the similar

int* a, b;

would leave only a an array, and b a scalar!

Let me anticipate the objections. I can think of two advantages for placing brackets with variable names.
First, it's your only option if you want to mix and match plain and array declarations of a type in the
same statement:

int a, b[], c, d[];

However, we can dispense with this quickly: you should not compress declarations this way. Use a separate
statement for each.

The second objection, which I have some sympathy for, is that placing brackets with variable names
is consistent with the way array instances are used:

int foo[];
...
foo[i] = -1;

However, between declaration and usage we have the initialization, and the initialization uses the
typename with brackets:

int[] foo = new int[50];
foo[i] = -1;

An easy way to find violations of this coding style is to use Checkstyle. Note that while javac will
happily compile both declaration styles, the error message from checkstyle is:

Array brackets at illegal position.

I guess that's stretching the definition of "illegal" a bit (since the
Java Language Specification defines what is legal and what is not, and both forms are allowed). However, in my opinion it is good practice to place the brackets where most Java developers place them - with the typename in declarations.

The Trouble With Password Entry Pads...

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

The problem with password entry pads is this:

Gee, do you think my password has any 2's in it? How about 9's?

I've had my digital token card for nearly ten years now. Amazingly, I've never had to change the battery. Anyway, while having token cards is an important part of security,
this Slashdot story shows that even these
schemes are becoming targets for phishing scams.

JavaOne talks available online

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

The JavaOne 2006 talks are now available online. Not only do you get the slides - you get the audio, and even a written transcript! All synchronized on auto play. Sit back and enjoy all the talks you missed! Especially those of you who couldn't make it to the conference this year. This resource is available free of charge for anyone - you just need a SDN (Sun Developer Network) login (also free).

It's pretty cool that written transcripts are provided. That lets you cruise through the talks if you're a fast reader and you don't want to sit and listen to the speakers. Somebody must have gone to a lot of trouble creating the transcripts - actually listening to all the talks and typing them in. In the case of our
Visual Basic talk, it's a bit entertaining though. John was joking that while Herbert is German, he would identify himself as Bavarian. The transcript says Liberian rather than Bavarian...

Not all talks (specifically, BOFs) are included. The Java Posse BOF for example. However, I recently got a link from a Java user group with Google video extracts from the show. See it
here - thanks to Peter Pilgrim. You can obviously get the full audio from the show at the Java Posse website.

You can find all the online sessions here.

An Inconvenient Truth

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

I decided to go see a movie tonight. Things have been really hectic lately, so I was in the mood for mindless entertainment – and there were plenty of choices to choose from. But on impulse I decided to go and see An Inconvenient Truth instead. If you haven't heard about it, it is essentially a documentary from Al Gore regarding global warming.

Okay, I will admit that it sounded a bit boring. And if there's one impression the Republicans were able to hammer home to the public in 2000, it's that Al Gore is boring.

However, I found the movie energizing – I highly recommend it. (And don't just take my word for it – check out what the critics are
saying
). It was engaging, as well as compelling. Even those of you happy with the current U.S. administration should not dismiss this movie as political propaganda, or place it in the
Fahrenheit 9/11 category - it's not.

One of the points made in the movie is that a lot of people think global warming is simply a theory, and a controversial one at that. That's not surprising given media reporting on the topic. However, scientific publications on the topic universally agree on the global warming trend: it's not just a natural cycle as in past ice ages and subsequent melts. In media reporting, however, more than half(!) of the reports are sceptical. Sure, it's possible that this reporting imbalance is simply due to lobbyists at work. However, I suspect people want to hear that there's no problem. That absolves all of us of any responsibility. "An Inconvenient Truth" is a fitting title - it's a truth nobody would like to hear.

However, the movie presents irrefutable evidence of the trend. One thing is the temperature and CO2 graphs, but the side-by-side pictures of glaciers, evaporated lakes etc. over very short time intervals are hard to argue with.

In the U.S. we now have an ad campaign against the conclusions in this movie, touting the benefits of carbon dioxide! That's right boys and girls, never mind the connection between CO2 and global temperatures. Carbon dioxide is good! It's natural. It comes from trees. Without it, life wouldn't exist! Thankfully, John Stewart on The Daily Show made fun of these ads. But the problem with comedy is that we laugh, then move on to the next show (in my case, The Colbert Report!) and fail to act.

This movie is pretty effective in trying to inspire people to take some action. Not only is it specific in what you can do, but it also has a pretty positive message. You might think global warming is all gloom and doom – and if we don't do anything, you wouldn't be all that wrong. But it makes a point I was not aware of: that we have averted a global environmental crisis in the past, so we can do it again.

Remember the ozone layer problem? I sure do. To this day I still use deodorant sticks because I remember the environmental campaign to avoid ozone-layer hazardous CFCs used in among other things, deodorant aerosol sprays that were popular at the time. What I had not heard until I saw this movie, is that this effort was successful and things are well within control today.

I was heartened to see that the movie was well attended. But then this is northern California, which politically is "out of touch" with the rest of the U.S. And, I suspect the people least likely to see this movie are the ones who need it the most, and vice versa.

It's very easy to ignore global warming. That's right. Click on the next blog story in your reader, perhaps something regarding Web 2.0, and forget all about it. But if you're reading this, chances are good you're in one of the top CO2 emissions countries causing the problems – and that makes you part of the problem. Ignorance is not an acceptable excuse. Watching the new Superman movie may be entertaining, but please consider assisting Superman in saving the world yourself! Watching this movie will make you think, and perhaps inspire you to do your part.

P.S. After posting this, I watched tonight's Daily Show and they announced that Al Gore will be the guest tomorrow night!

Happy 10

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Today is my 10 year anniversary at Sun Microsystems. When I joined June 26th 1996 I started working on Sun WorkShop, Sun's C, C++ and Fortran IDE. It's been IDEs ever since, most recently Creator and now, Semplice.

Here's to another exciting 10!

When it rains it pours

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

I actually have pretty good reasons for my low blogging rate recently, although they're personal so I won't get into it here. But on top of everything, I've been moving to a new place, and with six years worth of accumulated stuff packing and cleaning was quite an effort. Not to mention all the small annoying things I have to deal with, like no internet service for a week (my brother who is visiting is going crazy! Especially when the cable TV hookup is going to take another full week, during the all-important soccer world cup!). Just yesterday I found out that the garbage company is refusing to establish service for me because they claim the previous tenant has not paid his bill. I still don't understand how that's my problem. Garbage company, indeed!

Here are some quickies you might find interesting.

• 
  
  There is a "Developing Rich Web Applications Visually using JavaTM technology" class in San Francisco on June 20,21,22. This is being taught by the authors of the Creator Field Guide - Paul and Gail Anderson. There are just a few more seats left in this class. More information about this class can be found
  
  here.
  
  



• 
  There's a webcast on Ajax with Java, DWR and NetBeans tomorrow (6/14) with
  Dave Johnson, CTO at eBusiness Applications. More information
  here.
  



• Oliver Widder did a
  small cartoon on the Java Posse hat mystery...
  

Keynote Demo Explained

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

As mentioned previously, Project Semplice (Visual Basic for the Java platform) was unveiled at JavaOne, both with a technical session, as well as a keynote demo during the technical keynote. The video stream of the broadcast is available - choose
high bandwidth or
low bandwidth.
This is the third part of the keynote, and the Semplice segment begins at around 10:40, where Graham presents the intro slide, and lasts until about 14:40. If you have time, you should check out all the keynotes.

The audio comes through well, but it's hard to see the screen in the video. So let me show you the code in more detail.

I built a temperature converter application, converting Fahrenheit degrees into Celsius. To do that, I dropped three components: a textfield, named fahrenheit, a button, and a label, named celsius.

I then added an event handler to the button click event, which will convert temperatures according to the standard formula:

celsius = (fahrenheit - 32) * 5/9

To motivate why BASIC can be attractive, especially to new programmers, I showed what we'd write in a standard Java application utilizing the above JSF components:

celsius.setText(""+(Integer.parseInt(fahrenheit.getText())-32)*5/9);

I agonized over what code to write here. I personally don't like to use the trick with ""+ to cause integer to String conversion; the code I would have written is using Integer.toString(int):

celsius.setText(Integer.toString((Integer.parseInt(fahrenheit.getText())-32)*5/9));

But I'm not out to try to make Java look bad! And given that many people do use ""+, I went for the shorter solution. There is of course another possibility I could have used, which may be more true to the spirit of JSF. I could have dropped an IntegerConverter on the textfield. I could then have written code like this:

celsius.setText(""+((Integer)(fahrenheit.getValue())).intValue()-32)*5/9);

but as you can see this is not simpler than calling Integer.parseInt() directly - and it adds more complexity to the demo. (auto-unboxing might eliminate the need for the .intValue() call but you'd still need the cast, and that alone is a showstopper for "newbies".)

So the next step was to write what the equivalent code looks like in BASIC. Here it is:

celsius.text = (fahrenheit.text - 32) * 5/9

Notice that this looks a LOT like the original formula. In fact, at the end of the demo I actually comment out the above line and uncomment the original line - and that's the code I compile and deploy!

As I mention in the demo, there are several interesting things to note here.

• The BASIC code is extremely simple. In this particular instance, Java looks complicated. There are two reasons why the BASIC code is simpler.
  
  
  
  • First, it performs a lot of automatic type conversions. We're mixing strings and numbers here, and the Right Thing happens. Strings containing numbers get parsed into numbers, computations happen, and when a String is needed it's generated from the numerical result.
    
    
  
  
  • Second, we're able to access Java class properties using simple property syntax. Instead of calling celsius.setText(), we're
    writing celsius = , and the right hand side expression is fed into the setter. Similarly, we can refer to the getText method of the textfield by simply referring to it by its JavaBean property name.
    
    
  
  
  
  Java is more strict in which type conversions it will allow. "Automagic" type conversion can be dangerous. In Java you frequently get compiler
  errors or warnings if you do something that is probably wrong. In BASIC you won't notice until runtime - and hopefully it's not a rare scenario that
  goes undetected until a customer runs into it.
  
  A classic example of this happens in C, where any number is converted to a boolean when
  needed - nonzero is considered true, zero is considered false. If a programmer writes int x = getFoo(); if (x = 50) { ... }, Java would complain, because the if statement evaluates to an integer rather than the expected boolean (notice that it's a single =, not ==). In C, some developers like to
  take advantage of this "expressiveness", but it's usually a sign of a bug.
  
  Even in Java, where typing is pretty strict, you can run into trouble
  with some of the automatic conversions. For some great eye openers, read Java Puzzlers! See Puzzle #1
  in the sample chapter for example.
  
  
  
  


• 
  We're calling into Java classes from BASIC! The celsius and fahrenheit references point to Java objects that are instances of JSF UIComponent classes, written in Java.
  
  
  
  


• 
  We've written an event handler (attached to the button event) in BASIC. This event handler is being invoked from Java code (the JavaServer Faces web framework). Thus, we have Java calling BASIC calling back into Java.
  
  
  
  


• 
  The reason I could uncomment the original line, the one which doesn't specify the text property of the textfield or labels, is that
  the compiler also understands JavaBean default properties. If you leave out the property, it will look at the default property (which these JSF components specify in their BeanInfos) and use that one. text is the default property for both of these. The compiler cannot always do this - in some
  cases it's ambiguous - but when there is no ambiguity, it compiles without complaining.
  
  
  
  

Anyway, at the end of the demo I deploy. This compiles the BASIC file down to a Java bytecode class, which is located and instantiated by the
JSF managed beans machinery at runtime. As a result, the application works and the JSF framework has no idea it's talking to BASIC code.

So that's the keynote. At some point, the technical sessions will be made available online, so you can get all the gory details from TS-3576. Last year's presentations are available here - as you can see, you get both the slides and the synchronized audio track. This year they asked us to reduce the resolution on our laptop, even though it was showing fine on the projector, because some recording equipment needed it, so if we're lucky, the demos will be included in this year's multimedia version. As I mentioned the other day, for now you can see some demo screenshots and descriptions in Herbert's blog.

Java Posse live session

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

We had a Java Posse live session at JavaOne. The room was packed and it was a blast. And I think the audience liked it too. We recorded it, so you can check out the audio here.

I just noticed that in O'Reilly's OnJava writeup, "JavaOne Day One" by Robert Cooper, he not only mentioned the event, but called it the highlight of the day! Thanks! He has a couple of pictures too. Check out the ridiculous hats! A really weird thing happened later that night at the pub. Somebody, nobody knew who, ran into the pub, grabbed the hat right off my hat and ran off! We never knew who took it. Hey, that was one quarter of the Java Posse's marketing budget :)

We've recorded many other interviews too, that will be posted gradually. Not only because it takes time to edit all that audio, but also such that we can be a bit lazy during the next few weeks, as we recover from JavaOne and all the preparations for it!

Project Semplice (Visual Basic for the Java platform) launched

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

As promised,
I was planning on writing a full report from our TS-3576 talk at JavaOne, but my teammate Herbert has already done a great and thorough job. Read his entry for all the juicy details! Here's a teaser screenshot:

JavaOne So Far

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

JavaOne is well underway. It's been great so far. We had our demo in the technical keynote this afternoon. It was short, but everything worked smoothly. I'll have a lot more to say about it later. Perhaps I'll throw in some screenshots and a narrative, similar to the keynote demo I did
last year.

So by now it's no longer a secret: I don't work on Creator anymore, and haven't for about nine months. I'm on a new project, Project Semplice (pronounce that in Italian, by the way). This does not mean that Creator is in any way losing momentum - there are two new developers working on the page designer for example. But having been on Creator through two full releases, it was time to try something new. And the new project works on adding a new language to the VM. That seems like a major theme of JavaOne this year. We can accomodate multiple languages on the platform - both in interpreted mode ala JSR 223 Scripting Engines as supported in Mustang, as well as languages that compile down to class files just like .java files. Saying that I work on a "new language" may be a bit misleading: we're trying to target a language inspired by Visual Basic. There's no suitable marketing name for it yet, so in our slides, we're just referring to it as BASIC. Or, for a real mouthful, Project Semplice BASIC. We're going to have a technical session on Thursday at 9:45 (note the time! It changed from its original 1:30 timeslot). We'll have a lot more demos and in-depth coverage of aspects of the language.

Tonight we're having a session for the Java Posse. We're going to record a live session. The session is packed (according to pre-registration numbers). We've been promising on the podcast that we'll have a keg. That was the plan. Two-three years ago, when we launched Creator, we had a "Meet the Creator Team" session, and we brought a keg. We thought we'd just do that for our Posse BOF as well. But we discovered today that the BOF is going to be held in a nearby hotel, not Moscone center, and they have a no-keg policy!! They -do- allow us to have beer served - but we'd have to pay for each and every bottle of beer served, at $7 per bottle! With a couple hundred people attending that's going to be quite expensive. After all, this is just a hobby project for the four of us, un-affiliated with our jobs. We have no sponsors (which is why the podcasts have no commercials in them), so especially with some recent recording gear expenses, it's just not within our budget. So a big apology to those of you who are planning to attend the session purely based on the free beer we had promised :(

NetBeans Day yesterday went well. I was particularly impressed with some of the new demos I hadn't seen before -- like the new Subversion integration. I can't wait to get away from CVS! I also really liked the XML tools support. The platform development and the Java EE 5 demos were impressive as well, but I had seen that before and new stuff always has more appeal. I spent the evening with people I met randomly at the end of the event along with the Java Posse. We recorded several great interviews that we will publish as soon as we get time to edit them. One of the interviews were with findbugs founder Bill Pugh, and author and consultant Brian Goetz. It was a great interview covering subjects I think all developers find interesting -- bugs, tricky bugs, detecting bugs, concurrency issues, and so on. We also interviewed Steve Northover, the SWT lead at IBM. We've also got plans to interview the Swing guys this week (who did a fantastic keynote demo!), so that should be a nice pair of compare and contrast episodes.

I'm having a blast. So much fun that I can tell I'm losing my voice. I did this at the Java Polis conference back in December too. Hopefully I'll still have some speech left for the Posse recording session tonight.

Anyway, the big thing I want to get across with this blog entry is that you should NOT miss our technical session on Thursday, TS-3576, covering the new project - BASIC for the java platform! The other two speakers are the other two guys on the Semplice team: Herbert Czymontek and John "Get a blog" Kline .

Phew!! Ready for JavaOne.

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

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.

NetBeans Plugins I Use, part 4: Auto Spell Check

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

I went to the Update Center and went checking for new features. On the nbextras site I found a new feature I instantly fell in love with.

This is a spell checker which lets you register dictionaries (the English ispell one is bundled), and then your javadoc comments are checked for spelling errors while you're editing, much like the java code is checked for parse errors. Any errors found are underlined - and there's even a quick tip which lets you instantly (Alt-Enter) replace the word with similar words in the dictionary.

After installing this, I opened a couple of files from the JSR 273 project (under development), and it instantly pointed me to several typos I then fixed! Here's one of them:

The plugin is also smart enough to not report typos for names following an @author tag, and so on. And the options panel lets you register additional dictionaries. It's easy to find many free ones for ispell on the web.

Very nice! Thanks Jan Lahoda. Now where's your blog? Actually never mind, don't let anything distract you from writing plugins in your spare time...

Tabs Are Evil, Part 2: The Remedy

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

A while ago I argued that you should completely avoid Tab characters in your Java source files. Use spaces for indentation. I won't repeat those arguments here. But even those arguing in favor of tab-indented source files agree that mixing spaces and tabs is evil.

The problem is that sometimes you're not aware that you're working on source with mixed tabs and spaces. This can happen easily if you edit the source files with an editor that has the wrong (as far as you're concerned) handling of Tabs.

To help avoid this you can use a simple NetBeans module I just committed into CVS, under contrib/fixtabs. You can grab the NBM file here and install via Tools | Update Center. I'll submit it to nbextras.org soon so you can get it there later.

Here's what the module looks like in action. If you for example open the JDK JTable class and look at the constructor, you'll see something like this (click for full size):

Ewwww!

When you encounter files like this, you can go to the edit menu and select the action to convert the tabs to spaces. You can also turn off Tab highlighting here.

(Update 4/28/06: I changed this such that the "checkbox" toggle is now in the View menu, along with other view states you can enable and disable, and I moved the Convert action to the Source menu along with other source transformation actions.)

The module is similar to one of my favorite modules (which I guess I haven't described yet) - the "stripwhitespace" module. That module highlights trailing whitespace in the current source file, and lets you remove these. Not only is the fixtabs module similar - it's heavily based on the same source code.

Let me know if you encounter any bugs.

Learn Twice As Much With Same Effort

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

You may be familiar with the
Universal Law of Gravitation.
And in schools and other auditorium settings, you may have observed the "Second Law Of Gravitation":

Students will gravitate towards the back of the class room. The seats in front
fill up last.

Perhaps students are afraid to be picked out by the teacher to answer questions. Or perhaps they are afraid to be seen as eager to learn.

However, at some point in college I discovered that actually picking those undesirable seats up in front
was a good idea. I've stuck by it ever since. In presentations at work I always beeline to
the seats up in the front. Why? I discovered that lectures actually seemed more interesting that way.
Perhaps there were fewer distractions between me and the instructor. Perhaps being up close
let me see and hear everything clearly, and perhaps occasional eye contact with the instructor
kept me from pulling out alternative reading material (e.g. computer books) if I got bored.

It turns out that if you sit in the center front, you will actually retain more
of the material. Research shows that if people are placed randomly and then
presented with information, people in the front, and people in the center,
can recall a lot more of the presented information than listeners to the sides
and back. And we're not talking 10% more. We're talking twice as much.

Retention in a class room based on seating positions [Source]

	Instructor
57%	61%	57%
37%	54%	37%
41%	51%	41%
31%	48%	31%

This has been called the "Attention Zone" by some, and the "Action Zone" by others. (Information retention is just one aspect we can measure; verbal interaction is another.) This has been studied in depth because it has implications for
class room design and student seating assignments.

Taking a seat in the front is a simple tip you can use to start enjoying lectures more. And you'll probably learn more. It's not exactly one of my
coding tips, but potentially much more useful.