Monday Sep 26, 2005

iTunes link is up

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

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

Thursday Sep 22, 2005

Java Posse - the JavaCast reincarnated

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

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

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

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

P.S. If you want, you can subscribe to the podcast manually now; in iTunes, go to the Advanced menu, select "Subscribe to Podcast" and paste in

Wednesday Sep 21, 2005

Code Advice #4: Don't capitalize acronyms!

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

Remember how your ${NATIVE_LANGUAGE} teacher taught you to capitalize your acronyms? Please unlearn it. Thanks.

Seriously though... when you're writing code, you're not writing English. It makes perfect sense to choose symbol names that read well in your preferred human language. But CamelCase, the preferred capitalization scheme in Java code, is not proper English capitalization either. So don't carry over the acronym habit from English.

For example, use HtmlDocument instead of HTMLDocument. Use CssParser, not CSSParser. Unfortunately, many existing APIs violate this rule. Even the JDK has many violations - acronyms like IO, UTF, EOF, XML, SQL, HTTP, URL and URI abound. However, I think the trend is towards uncapitalized acronyms in newer classes going through the JSR process.

So why precisely should acronyms not be capitalized? For readability reasons. The acronyms are treated as words, not as individual letters, so when you're scanning a CamelCase word you can quickly see that HtmlDocument contains the words "Html" and "Document". So it's easier to visually scan, and I think it just looks better.

Unfortunately, it may be tricky to rename existing classes in your code. If you use CVS, changing class names that vary only in capitalization will confuse CVS on some platforms. On Windows two filenames are considered identical if they only vary in case.


Sunday Sep 11, 2005

Code Advice #3: No Tabs! Ever!

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

Should you use spaces or tab characters when indenting your code? This question has been debated at length in the past, with a fervor similar to the "emacs versus vi" editor debate. But unlike "emacs versus vi", we cannot just agree to disagree. We can each choose to use a different IDE. But the source code is often shared, and if there's one thing that's worse than a source file indented with tabs, it's a source file partially indented with tabs and spaces. This is typically the result of a file edited by multiple users.

My advice is simple: Always use spaces to indent. That doesn't mean you can't use the Tab key in your keyboard to indent - most tools will automatically do the right thing with spaces instead. In other words, the Tab key is the Indent key, not the Tab character key.

So why is it bad to use tabs instead of spaces?

There are several reasons. Obviously, there's the reason I started out with: that we really need to pick one convention. Spaces for indentation is the most common scheme used to today, so it's a reasonable choice on that basis alone.

One of the problems with tabs is that a tab character needs to be converted into whitespace by the editor when displaying the file. How much whitespace should each tab character be replaced with? In an ideal world, the old typewriter functionality could be used, where each tabstop had a certain pixel position. That way people could even use proportional width fonts in their editors (instead of the blocky monospace fonts used by practically all code editors today), and the code would still indent nicely. However, no editor that I'm aware of supports this, so that's not a practical venue. Instead, editors typically make an assumption that a tab is either 8 characters (common in ye old days) or 4 characters (common in Java editors today). Some editors will stick with the 8 character assumption, but support 4-character indents in Java (which is common), so when indenting to level 3, they will insert a tab, followed by 4 characters, to get a 12 character indent using an 8-character tab.

Why is this bad? Because code is viewed in more than one tool. In the presence of tabs, code often gets misaligned. Code integration e-mail diffs, code viewed in other editors, code edited by other tools which treats tabs in a different way will easily get "mangled" (e.g. start getting mixed spaces and tabs).

(Sidenote: In the old days, source files sometimes included a comment at the top of the file, with special "tokens" (-\*-) intended for Emacs. These tokens would identify the language mode as well as the intended tab size for the file. When loading the file, emacs would use the specified tab size. Thus, the source files actually carried the tab information needed to edit the file as intended. However, this solution doesn't really solve the problem since all other tools which process and display the file would also need to be aware of this metadata.)

I've heard people put forward two arguments in favor of using the tab character:

  1. If a file uses ONLY tab characters for indentation, it is easy for users to read code at their own favorite indentation level. In other words, I can read your source file with tabs=4, you can read it with tabs=2
  2. It's easier to move back and forth indentation levels, since a single left/right keystroke will jump across tab characters, e.g. whole indentation levels.

Regarding argument 1: There are lots of other things I want to customize when I read other people's code too. You see, people don't all agree with my code rules that I'm putting forth in these blog entries :-) So if I read code that is indented poorly, or worse yet put spaces between function calls and the parenthesis, or other horrible coding sins, I hit Shift-F10 to reformat the source properly first anyway. This solution is more comprehensive than simply adjusting the indentation depth.

Regarding argument 2: I don't see a big usecase for being able to move the caret up and down indentation levels. These only apply at the beginning of the code line, and the Home key should alternate between jumping to the beginning of the line and the first nonspace character on the line. Why would you ever need to go somewhere else? Perhaps you want to move some code up an indentation level. That's what the Reformat feature is for. Just reformat the buffer instead.

(Minor sidenote: In Emacs, and I believe in JBuilder, the Tab key was bound to a reindent action, NOT inserting indentation. This is a much better use of the Tab key. When you're on a new line, pressing Tab should move the tab to the correct indentation level (reindent), NOT inserting say 4 characters. If you're on a line with existing code, hitting Tab should NOT insert 4 characters where the caret is located, it should adjust the line indentation such that it's correctly indented. Thus, if I put an if block around a piece of code, I can just hit Tab, Arrow Down a couple of times to indent the block correctly. I submitted a patch for NetBeans to do this a while ago but this behavior is apparently a bit controversial. For a previous XEmacs user like myself it's indispensable.)

Therefore, in my opinion, these potential advantages do not make up for the massive problems and ugly code that result. Let's all use the same convention - no tabs.

All IDEs let you do this. (I even believe most IDEs default to using spaces. Please double check in your own.) Here's the option in the new NetBeans 5.0 options dialog:

The people who seem to rely the most on Tabs today are people using old-style editors where Tab characters are still the default. If you're using Emacs, add the following to your .emacs file:

 '(indent-tabs-mode nil)
 '(tab-width 4))
Here's how you do the same thing in Vim.

Saturday Sep 10, 2005

JavaCast - will be baakk

Brandon Werner, one of the two guys who started the JavaCast, and apparently the one guy who owns the JavaCast name and web site, decided Java is soooooo boring. As is programming. As is the entire tech industry.

So even though the JavaCast has over 30,000 descriptions and a large number of separate downloads (perhaps by people who haven't seen the light with iTunes), not only did he quit -- he took the web site down with him. Not even a postscript telling people what happened.

I just talked to Dick Wall, the other JavaCast guy. He's about as confused and disappointed as I am, and definitely wants to continue the broadcasts. He's working on finding bandwidth etc. So good news - the JavaCast will be back in some form, but probably with a different name.

Here's a suggestion: JavaCats?

P.S. Dick has described the situation himself here.

Tuesday Sep 06, 2005

Code Advice #2: No Vanity Tokens

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

Some programmers like to tag their code modifications with their own initials:

  //!FB Shouldn't we compare with MIME type?

I've been told the format shown here, using the explamation point in front of the initials, is/was the preferred format at Borland. They even had a tool to go and strip these types of comments out before releasing source code to customers.

Having people "sign" their comments doesn't contribute to make the comment more readable. Real projects should be using some kind of version control system, and information about which line was written by whom (as well as when) belongs in the version control system, not inline in the source. The comment should be able to stand on its own feet.

There are some standard tokens that should be used. TODO, FIXME, and XXX are standard tokens used to mark code that needs to be revisited. They are "standard" in the sense that many editors and IDEs automatically highlight and search for these tokens. In fact, they are even documented in section 10.5.4 of the standard Java code style document:

Use XXX in a comment to flag something that is bogus but works. Use FIXME to flag something that is bogus and broken.
They left out TODO, which should be used where something hasn't been implemented in the first place.

By the way, @todo is a reserved javadoc tag and means the same as TODO in comments. (Speaking of javadoc tags, @author is obviously okay and does not fall under the no-vanity-tokens guideline.)

In addition to these, I use some additional tokens to mark code for other purposes:

  • JDK15 is a token I attach next to code or comments which should be revisited when we drop JDK 1.4 support and can start using JDK 5.0 APIs. For example, I have code in the designer which tracks the current mouse position (such that pressing Ctrl-V to paste a component from the clipboard places it under the mouse position). In JDK 5.0 there is a new API which lets me look up the mouse pointer position directly (yay!! Thanks!) so I can rip out the old-style code.
  • NOI18N is a code marker which indicates that any String literals on the same code line are deliberately not internationalized. This is used for Strings which not be localized, such as the name of a Java class used in Reflection-related code for example.

I'm sure there are other useful tokens too. What makes these different from "author signatures" in comments is that they are added specifically to facilitate locating this code fragment in the future (when looking for JDK 5.0 migration possibilities for example) or for processing by tools (such as the String localization checker).

Including bug ids in comments falls in roughly the same category. Code segments full of bug database numbers are hard to read. It's much better if the various corner cases that were exposed by bugs are explained inline in the code. This is less of an absolute however in cases where there truly is a lot of value for a developer to be able to look up associated bug reports and history. And of course, code which was added as a specific workaround for a bug elsewhere (such as a OS or JDK bug) should have the associated bug id included, such that future developers can look up the status of the bug and easily determine if the code is still necessary.

Saturday Sep 03, 2005

Code Advice #1: Don't Log, Debug!

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

Rule number one: Don't Log, Debug!

One of my pet peeves in code is gratuitous logging. Gratuitous logging is where every little thing happening in your code is also sent as a log message. In other words, logging is used to record program events, rather than program errors!

The rationale for this is usually that logging is inserted to help find bugs later. "Just turn on logging and comb through the output to trace execution and discover the problem."

I don't buy the above argument, but before I go into that, let me state why I think logging is bad: It reduces code readability. You've probably heard that you shouldn't sprinkle your code with comments that are obvious (and therefore redundant). Sprinkling your code with logging calls describing what's going on is essentially the same thing, only it's even harder to mentally filter these out while reading the code, since they don't have the visual "I can ignore this" property that comments have in syntax highlighting.

There's a much better way to find bugs than by using logging: Use a debugger! I will admit that I used to rely on logging myself, since in the early days restarting the application, and even single stepping the debugger, was frustratingly slow. But with the introduction of Hotswap, and general improvement in features and speed of Java debuggers, there's no good excuse for not using a debugger to track down program bugs today.

The argument that's usually thrown out in defense of logging is that you need it to track down bugs in a deployed environment, for example at a customer's site, where you don't have physical access and cannot debug it yourself. You want to enable logging and use the log from the customer to figure out what's going on.

In my experience, that sounds good in theory but never works in practice. The logging never has all the information you need. To track down a specific bug you typically need fine grained information that you hadn't thought you needed when you wrote the code.

Let me also point out that this is a really rare scenario. Usually, if a customer reports a bug, they can tell you how to reproduce it, and once you can reproduce it locally you don't need to debug it via logs on their system - use a debugger locally.

The scenario has come up once for me. In Creator 1.0, some customers reported that after using the IDE for a while, the IDE would suddenly stop updating the source files even though components were added and properties changed. There were no direct instructions to reproduce, and it was rare - nobody internally had ever seen it. Finally a case for customer site logging! What I did was add a number of targeted logging calls; anything having to do with buffer manipulation was heavily "instrumented". I also developed a couple of hypotheses about what the problem might be, and added special code for checking these hypotheses, adding log messages if they succeeded. I then provided a custom jar to two customers who had reported seeing this problem regularly - and a few days later I had confirmation of one hypothesis.

The key point I want to make here is that even though this actually is a scenario which called for logging, it didn't have to be put in the product a priori. The logging calls were only added temporarily in one of my source trees. And furthermore, to get useful logging data I added a lot more tracking than would have been feasible to do in a product version.

So when should you use logging? To record errors and unexpected conditions - especially non-fatal ones where you don't want to get the user's attention, you simply want to know about it yourself such that you can check your assumptions and improve your program quality later.

If you're not convinced and still want to use logging, here's a tip for how to do it efficiently. There's always the option of statically compiling out all logging:

   private static final boolean LOGGING_ENABLED = false;

       log("foo = " + bar);

By using a final boolean here which is false, the compiler knows that everything, including the if block, can never be executed, so it will be completely eliminated - the class file will not contain any of the byte code; the class String table will not include the string in the log call, etc. This is zero-overhead logging, when logging is disabled. The disadvantage of this approach of course is that it cannot be enabled by the customer, so it's only useful internally. And for that of course, use a debugger!

A modification to this scheme which works well, is to use the assertion facility. This is what I used before I finally removed all non-error-related logging from my code. Create a log function like this:

    public boolean log(String message) {
        // log calls here - perhaps delegate to a logging library

        return true;

Now you can use logging as follows in your code:

    assert log("foo = " + bar);

This is using assertions for a side effect: the assertion will always be true (since the logging call unconditionally returns true) so no AssertionError will be thrown. However, the logging method parameters get evaluated and the logging method called.

This solution gets the best of both worlds: When turned off it has nearly zero overhead (because the class loader will throw away the assertion statements when loading the class), but it can still be turned on in those rare scenarios where you need a customer to provide you with logging calls. (It does however increase the size of your String pools etc. so there is a small cost.)

But again,

  • In practice this scenario comes up very rarely
  • Even when it does your existing logging calls probably aren't sufficient anyway
  • You can get the data you need by providing the customer with a special enhanced logging build
  • Logging calls makes your code less readable
  • Logging calls makes your source files, and class files, larger
  • Without any significant pros, and a significant con, the choice should be easy!

Don't forget - logging is appropriate for logging errors! Don't start writing empty catch blocks and blaming me! For example, in an application built on top of the NetBeans RCP (see a tutorial of the new RCP support), a catch block that doesn't do anything else should at least call

   } catch (WhateverException ex) {

Code Advice "Column"

I've discussed coding style a couple of times before in this blog, and it invariably generates a lot of interest and discussion. It seems I'm not the only one who cares a lot about these issues.

I recently tried to explain the coding style I've used in the Creator designer source base, to somebody else on the team. When I tried to provide references I came up short. There are several coding style guidelines - and I tend to follow the JDK one - but the problem with the official coding style document is that it leaves out a lot! For example, it does not address the Tabs versus Spaces issue (cowards!). I found some other good ones, but I disagree vehemently with some of their rules (like open braces on a separate line, and underscore suffixes and fields, and indentation level 2).

So, I intend to start blogging my opinions on how to write good code. Some will be controversial - especially my first "rule" regarding logging! Note that no rule is absolute - there are always exceptions and you need go consider the tradeoffs and apply good judgement.

I also shouldn't take "full credit". I have not invented most of these practices. Some I have learned from developers whose style I admire. Others have come about as the result of (sometimes heated) discussions with other programmers. And finally, some have I have learned from my own past mistakes.

Take everything with a grain of salt - but I hope you will find these entries, at least some of them, helpful.

Update 10/15/06: Here are the entries as of today:

Friday Aug 05, 2005

NetBeans versus Eclipse!!

There's no better way to get attention than with a subject like that! There's a new JavaCast podcast out. This is a new "weekly radio program" on Java and what's happening in the Java world. If you have iTunes, or other podcasting software, it's trivial to subscribe to the weekly feek - just follow the links from the JavaCast page. Of course, you can just listen to the MP3 file directly.

So why did I use such a controversial subject for this blog entry?

In this week's JavaCast, I'm the interview subject. One of the things I talk about is the "IDE war" - addressing why I don't think NetBeans should give up just because Eclipse have signed up so many partner companies. Other things I address is Class Library Development versus Component Based Development, I talk about my observation that many server-side framework pundits seem to have tools phobia, and of course I talk a bit about AJAX and about Creator.

Monday Aug 01, 2005

Remove duplicate and unused entries from your property files

Three years ago or so I realized the code I was working on had lots of "stale" entries. These are bad because not only do they create more work for localizers who translate these files to other languages, but unused keys also incur more runtime overhead.

It's easy to end up with unused key entries. Perhaps you first comment out some code which is referencing a bundle key - but you don't comment out the bundle key. Later the commented out code is removed, but the key in the property file is still there.

To find these I wrote a really hairy Unix command; something like this:

 find . -name -exec cat {} \\; | /bin/grep "=" | sed
'/\^#/d' | sed '/\^OpenIDE-Module-/d' | nawk 'BEGIN { FS="=" } {print $1}'
| sort | uniq | nawk '{system("/bin/fgrep " $0 " `find . -name
\\"\*.class\\" -o -name \\"\*.xml\\"` \\| nawk \\"BEGIN \\{i=0\\} \\{ i++ \\} END \\{
if \\(i==0\\) print key \\}\\" key=" $0)}' | /bin/xargs -n 1 -I @ grep @
`find . -name` 

I recently figured it was time to check my Bundle files in my current code - so I used a tool I had seen Tim Boudreau commit into NetBeans CVS. It's a standalone tool, not integrated as part of the IDE. But it's quite useful.

The tool is called "Bundlizer", and is found in NetBeans CVS under contrib/bundlizer. Just load it as a project in NetBeans and run it and you'll get the GUI (see screenshot below). Or, use the executable jar I just uploaded here. Use at your own risk.

The program does a couple of useful things:

  • It looks for duplicates: the same key used more than once. You are alerted to this specifically since you'll need to decide which value to keep.
  • It looks for unused keys. These are removed from the file.
  • It cleans up formatting in the file, removing empty lines etc.
When you're done it saves the resulting file.

You'll definitely want to check its results. Discovering if a key is unused is not something which can be done accurately. Obviously, if your code is doing something fancy, like computing keys rather than looking them up directly, the program will not figure that out and will think the keys are unused. One common case of that in my own code had to do with keys that are referenced from XML files. For example, NetBeans plugin code declares menu items in an XML file, and these pull keys out from a bundle. There are other ways the program can be tricked too.

Consider yourself warned. However, the program is extremely useful at identifying candidates for removal. You'll probably see some keys in your own files and go "oooooh yeah.... that's still there? Guess I forgot to remove it!".

Here's a screenshot of the utility in action (click on it for full size):

I suspect the reason the utility has not been "finished" and moved into the IDE as part of the Resource Bundle support, is precisely because discovering unused keys is such an inaccurate science. If anyone would like to take a closer look at the code and try to make it smarter, please do! I made a couple of tweaks for my own purposes before running the tool. Here's the patch I applied - the first diff makes it look in XML files for key references; the second makes the tool less unhappy when it encounters non-comment lines that don't contain and = sign:

Index: contrib/bundlizer/src/org/netbeans/modules/bundlizer/
RCS file: /cvs/contrib/bundlizer/src/org/netbeans/modules/bundlizer/,v
retrieving revision 1.3
diff -u -r1.3
--- contrib/bundlizer/src/org/netbeans/modules/bundlizer/   7 May 2004 23:48:40 -0000        1.3
+++ contrib/bundlizer/src/org/netbeans/modules/bundlizer/   2 Aug 2005 05:45:46 -0000
@@ -449,7 +449,7 @@
     private class JavaFilenameFilter implements {
         public boolean accept( file, String str) {
-            return str.endsWith ("java");
+            return str.endsWith ("java") || str.endsWith("xml");
Index: contrib/bundlizer/src/org/netbeans/modules/bundlizer/
RCS file: /cvs/contrib/bundlizer/src/org/netbeans/modules/bundlizer/,v
retrieving revision 1.2
diff -u -r1.2
--- contrib/bundlizer/src/org/netbeans/modules/bundlizer/       1 May 2004 13:52:24 -0000        1.2
+++ contrib/bundlizer/src/org/netbeans/modules/bundlizer/       2 Aug 2005 05:45:46 -0000
@@ -115,6 +115,10 @@
                 String keyValuePair = line;
                 int equals = keyValuePair.indexOf ("=");
+                if (equals == -1) {
+                    continue;
+                }
                 assert equals != -1;
                 String key = keyValuePair.substring (0, equals).trim();
@@ -203,6 +207,9 @@
     private boolean isKeyValuePair (String line) {
         int equals = line.indexOf("=");
+        if (equals == -1) {
+            return false;
+        }
         int cmt = line.indexOf ("#");
         return (cmt > 0 && equals < cmt) || (cmt < 0 && equals >= 0);

Wednesday Jul 13, 2005

Don't Code Like This!

I was trying an open source web framework yesterday, and couldn't get it to work so I stepped through some of the code on the server with a debugger, and came across some code fragments that I thought I would submit to the Hall of Shame.

Besides, it's fun to blog about this, because each time I mention coding style I invariably get passionate responses from people defending their beloved style.

In the following, the class and method names have been changed to protect the guilty.

At first, I simply got a generic JspException. The code was doing this:

    } catch (ConfigNotFoundException ex) {
        throw new JspException(msg);
The original stack trace is not chained to the new exception! Please pass it in - JspException has a constructor which takes both a message and the root cause exception, ex in the above. If you're using some Exception class which is older and doesn't let you pass in the root cause, such as DOMException, then first create the exception, then call the initCause method on it, and finally throw the exception object.

The second code fragment I came across was this:

    try {
        return findConfig(servletContext).getResult(foo, servletContext);
    } catch (NullPointerException ex) {
        throw new ConfigNotFoundException("Can't find configuration");
The above code is using exceptions for flow control. Rather than first calling findConfig, then checking if it is null, it just goes ahead and tries calling it anyway, relying on the NullPointerException to handle this case.

The code also has the bad effect of catching all unintended null pointer exceptions in the subsequent getResult method call. These are unrelated to the ability to find the configuration, so the error message would be misleading. (And again the original exception is not chained).

Thursday Jul 07, 2005

Generics Considered Harmful? Nope.

I just came across this blog entry by Ken Arnold (who's writing a book on the Java language) where the author argues that generics should not have been included in JDK 5.0:

I don't know how to ease into this gently. So I'll just spit it out.

Generics are a mistake.

This is not a problem based on technical disagreements. It's a fundamental language design problem.
and then the concluding remarks:
... it feels like the JSR process ran far ahead, without a step back to ask “Is this feature really necessary”. It seemed to just be understood that it was necessary.

It was understood wrong.

I disagree with Ken. The big point of adding generics is allowing people to use type checked collections and so on. Nearly all Java programmers use the Collections API. Using the genericized collections in JDK 5.0 is not hard - it's really easy, makes the code cleaner, and detects programmer errors. The fact that creating generic collections classes is hard is besides the point - most programmers don't have to. Yes, there's a price for having more flexible libraries: they're harder to write. That is nothing new. Developers can continue to write JDK 1.4-style APIs and libraries if they want to.

Perhaps the comparison is a bit unfair, but take EJBs. Prior to EJB3, developers had to work really hard to write an EJB. With EJB3, all they have to do is add some metadata annotations to their simple Java code, and everything else is handled automatically. Did this make writing an app server harder? You bet. But that's a fair trade-off - there will be a lot more programmers using EJBs than programmers writing app servers. While not a perfect analogy, I think the same principles apply here. For a few library designers, who now want to create generic types (they still have the option of creating old style types), life just got more complicated. However, for all their clients, life got easier. Easier is good.

Wednesday Jun 29, 2005

Another JavaOne Trip Report

Greg Murray and I gave a talk on AJAX yesterday. They're tracking the attendance numbers for all technical sessions at JavaOne and as of this morning it was in the top 10! It has probably dropped down a couple of notches by now though... The talk went well and I've only received positive feedback, so I think this is a technology a lot of people are excited about.

A couple of people have already tried the AJAX component library for Creator and have asked where the other AJAX components are. The component library only contains my auto completion textfield so far; the other components written by Greg (Murray), Ed Burns, Roger Kitain etc. have not yet been adapted for Creator - we really should do that ASAP but we've all been too tied up with JavaOne. I'll post something once it's ready. And we desperately need that JSR for component metadata, so we can directly embed designtime metadata in the same files already used to generate component classes!

I had a fun challenge this morning. During the launch of the new Ultra 20 computer, I was challenged to code up an application using our tools as fast as possible. I had roughly an hour. While I was coding away, there was a panel discussion followed by some presentations. I was listening to my own music so I wouldn't get distracted. A couple of times I caught myself tapping with my feet - hope I didn't distract the nearby journalists! My screen was visible though so they could see that I wasn't "cheating" (e.g. just pulling up previously created content). I had planned in advance roughly what to build, but hadn't tried it - after all what fun is a challenge if it isn't actually challenging? However, thanks to this I got to get pretty stressed! My plan was to build a translation web service, by first pulling down a free dictionary word map (English to Spanish and vice versa), then read the words into a map, then build a Creator web app which takes pasted text, splits it into words and calls the web service to generate a translated text segment. Plus various web controls to convert the translation direction etc.

Well, I started out with NetBeans to create the web service. I knew this would be most of the job. I looked at the format of the data file - a perfect job for the new JDK 5.0 Scanner API, so I wrote some methods to parse the data files using it, storing it all in typed Maps (using generics). Ah, what a delight it is to use the new JDK 5.0 features - the code is so much cleaner. By now it was definitely time to deploy the web service - I had used up half of my time already (but I knew I could do the Creator part really quickly). So I hit Deploy, and .... disaster!! I got an error message from the ant file responsible for deploying the web service. What's going on??? And at this point they stopped the briefing and asked me for status... uh oh... "I have another half hour, right? Right? Phew". I've done a web service before - a couple of weeks ago I did a simple dictionary lookup one (the one shown in the AJAX keynote), so I thought this should work. The only significantly different thing is that I had used JDK 5.0 apis this time - the format of the datafiles, maps etc. couldn't matter - so I decided to cut my losses, not try to debug it and just rip out the generics and rewrite the scanner portion to just do simple String iteration instead (e.g. iterate over the String, look for the first tab, that's the English/Spanish delimiter, then look for the first comma or newline, that's the first translation word, etc.)

Done... ahh....

That strategy worked - another ten minutes I had a working web service, and twenty minutes later I had built a Creator web app with dropdowns for choosing Spanish to English, English to Spanish, and English to Spanish to English. I also modified the output to be HTML for the text such that I could mark up any nonmatched words (which I left untranslated) in a light red background color. When it came time to report what I had done, I opened the browser, cut & pasted Sun's mission statement (from our web site), and translated it from English to Spanish and back to English. With the poor dictionary and complete lack of heuristics, the result was a pretty interesting Mission Statement - one I hope we won't adopt!

I realized right after the demo what the problem with deploying my original web service had been: Even though App Server 8.1 is capable of running JDK 5.0 code, I had started it from Creator (so it was using Creator's VM, JDK 1.4!) instead of NetBeans' (JDK 5.0). Doh!!

By the way, those new Ultra 20's are just fantastic. Deploying my app takes just a couple of seconds! I thought my existing W2100z opteron workstation was fast, but my, I want one of these!

Later this morning I went and attended the vendor panel on JSF components. That was really interesting - I got to see great demos of JSF components. ESRI and SoftwareFX showed components tightly integrated into Creator, which is always a proud moment since I wrote the code which renders their components on the screen :) Otrix showed some really powerful components - but only in the browser, which surprised me a bit since I'm sure they work in Creator (Stephane, Otrix' CEO who gave the talk, has provided a lot of great feedback to us over the last year). Craig McClanahan showed the new Creator builtin components. The Theme Switch feature appeared not to work but what had happened was that there were multiple projects open, and the theme switch was applied to a different project than the one for the current page!

I have a lot more to say about JavaOne, but I'm running out of time - I have some more people to meet this evening, and tomorrow morning I go on vacation! Just for 4-5 days but it's going to be great - I haven't taken much vacation the last 2-3 years and after the Early Access milestones followed by the JavaOne buildup followed by the JavaOne events I'm quite ready for it.

I've met several people at JavaOne who stopped by and said they read my blog and encouraged me to keep it up (a few even said to blog more). I appreciate that. It's very hard to get any kind of reliable statistics on blog readership - the page counts could be almost entirely due to search engine crawlers, and on the other hand RSS news aggregators completely hide the true number of readers. So getting actual thumbs up from people is great encouragement. And now that Creator 2 is out I have a lot of new things to talk about so once I'm back I'll get back into it!

Tuesday Jun 28, 2005

Confessions of a Demo Dollie

As promised, here's my "trip report" from my keynote demo yesterday - click on the images to view larger versions.

Preparations started on Sunday with an afternoon rehearsal. Here's most of the Creator crew involved - Val Lipman, me, and from marketing David Folk, Shar Chander, and Dan Roberts. Keynote demos are serious marketing vehicles! The keynote demo was limited to three minutes, and I needed to show both the new Creator 2 highlights as well as the new AJAX work - and fitting that into the time slot required quite a bit of planning; boiling down everything you need to say into a couple of essential messages to get across, and ensuring that the demo has broad appeal to the audience.

The rehearsal took several hours. On the left you can see a crane in operation; on the right is Chris Webster and Charles Beckham from the Enterprise tool team setting up their machine. My machine is the one to their left. The machine is one of the new Ultra 20's Sun announced during the opening keynote. I had played with the system on Friday, installing the demo bits and testing them out - and wow, I've never seen Creator deploy a project so quickly. So I was shocked to hear the price - $900! Granted, the system I was demoing on was a higher configuration, but the technical specs aren't all that different.

Here's Adam Leventhal from the Solaris kernel group preparing for his DTrace + Java demo. I got some great tips from him afterwards on how to be able to connect into the Sun intranet using Solaris 10 on x86, so I'll be checking that out after the show.

This picture also gives you a sense of the size of the stage, and the giant projection screen!

Here's the action backstage. The giant center screen is just amazing - it's huge yet is also extremely sharp. Notice how the image is reverse - this is where there are giant projectors sitting on towers projecting onto the screen that the audience is seeing from the other side. There's also an unbelievable amount of hardware here - computers driving all kinds of effects, slides, video clips and audio shown on the projector, and all kinds of other stuff that I don't know anything about. Backstage is generally dark except from the glow of the monitors (all facing away from the projection screen). Thus it would be easy to trip on a wire and cause what can only be described as a career limiting move. However, that's solved by having various "paths" through the jungle carved out by white tape indicating the routes - including little arrows guiding you out to the stage.

And now it's suddenly Monday morning, and time for the keynote. I needed to check in at 7am. Luckily I have one of the "All Access" passes which can get you anywhere in the conference. Gets you right past that long lineup outside of Moscone in the morning! However, they're very hard to get - unless you're crew or part of the keynote you can't get one because obviously if you're part of the rehearsals you'll hear announcements before they're ready to be made public.

It's time to get anxious... the picture shows the countdown counter on the stage monitors that are visible from the stage. 20 minutes to go... time to get some coffee! The buildup to the keynote is really fun. They play great music and combined with the adrenaline and excitement it's just a very good feeling. I didn't even realize that this time, it was a live band -- Magnetic Poetry! I walked up and snapped the picture on the right.

I then ran out and got a coffee -- there's a Peet's Coffee stand outside that had a double shot latte. Eight packs of sugar and I'm all set! You can see Tim Cramer's back, Bob Brewin next to me, and Jeff Jackson's leather jacket!

When the show started, John Gage listed some statistics. They did not exactly make me calmer... 8,000 people in the audience, plus several overflow rooms. A quarter of a million viewers tuned in to the simultaneous web cast. You can see a recording of the web cast yourself here.

And finally, the moment is here -- the Creator demo!! I got up on stage, talked a little bit about Creator 2, showed some of the new rich components I had just mentioned, and then showed the new AJAX autocompletion component. I'll blog about that separately since people have asked for more details, so stay tuned.

After the software demos, there was a Happy Birthday to Java segment, since Java is 10 years old this year. After the band had played they dropped confetti. Seated near the front I was actually under the confetti being dropped, so it was unreal - confetti raining all around me. I shot another picture - note how there are large blocks of confetti falling right in front of the lens!

I'm going to end this photo blog with a picture from New Energy's theater presentation that I mentioned yesterday. In this picture Neal is describing his Shrek architecture model: layers and layers and layers!

Monday Jun 27, 2005

Live From the Show Floor

Hi there - I'm posting this from one of the SunRay terminals on the show floor at JavaOne in the pavillion. It's been a great show so far. It started with NetBeans day yesterday. The event was packed - in fact hotel staff was getting concerned (and got involved) when they thought we'd exceed the allowed limit (for safety issues). I thought the keynote addresses by Tim Cramer, Jonathan Schwartz and Rick Ross were very good as well. We then broke into individual sessions, and I gave an hour demo of Creator. Since less than half of the audience had seen Creator I did a lot of Creator 1.0 things, such as showing the basic JSF web event driven programming model. I showed some of the new powerful components, such as the table, and the file upload component. I was working up to a REALLY cool demo with the file upload component, but unfortunately I ran into a bug - and couldn't get file upload to work. It turns out that the component doesn't work right when you both have installed the app server in a directory with spaces AND you're using Internet Explorer to do the upload! Unfortunately we didn't discover that that was the problem until the demo was over. All in all though I think the attendees got a feel for what WYSIWYG web development with Creator is like.

This morning I demoed Creator in Jonathan Schwartz' keynote, in Jonny Loiacano's software segment. I started out showing Creator 2, and then showed the new AJAX component. You can find this component library on the Creator Early Access site. I will blog about that demo separately - and I have LOTS of pictures from the show and backstage that I want to share with you. When I get to a place where I can upload my pictures I'll post another entry.

I JUST went to a really fabulous presentation in the pavillion theater by Neal Tisdale from New Energy, and his lead engineer, Dick Wall. They were presenting their experiences using Creator (1.0) on a time crunched project and their experiences. The presentation was really great, especially because it made use of humor. And after a while there was a whole crowd gathered behind the theater listening in.

It's time to head over the the Ask The Experts tables where I'll be fielding Creator questions. Check back tomorrow for event pictures!


Tor Norbye


« July 2016