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.)