Wednesday, November 30, 2005


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

A month ago or so I blogged about the fact that Creator was offered for free. Unfortunately the wording in the various announcements used phrases like "Sun is currently offering..." which mde it sound like a temporary promotion - get your copy now or miss your chance. A free license is nice, but not the same as knowing you can continue to get the tool for free, including other coworkers in the future and so on.

As today's announcement makes clear (be sure to listen to the podcast audiofile linked from Johnny L's blog), this is no temporary marketing strategy. Sun is strategically moving towards free software. This will help drive volume, and indirectly, revenue. Johnny, and Jonathan, talk about this in many places.
Listen to the JavaPosse interview with Jonathan for example.
John Clingan also chimed in on today's announcement.

Oh... the link - get the software
here. I've only talked about Creator in this blog entry,
but you now get all the Enterprise software for free too.

Tuesday, November 29, 2005

JavaPolis 2005

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

I will be speaking at JavaPolis in Belgium in less than two weeks.
I hope to see some of you there. I'll be doing a Creator talk from
3:30 to 6:30 on Monday Dec 12th. Wow, three hours... Seems like a lot
but I bet time will fly by. It certainly did during my Creator demo
at NetBeans day where I only had one hour.

the agenda:

  • Leveraging Java Studio Creator's JavaServer Faces component library

  • Using simple drag-and-drop data binding procedures

  • Using an AJAX test completion component

  • and much more.

NetBeans has a
strong presence too.

Media Player

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

Marco has developed a JSF component which lets you embed a media
player in your web pages. Given that it's a media player, not a simple
HTML include, you can control the player url etc. from java code in the
page bean. See Marco's blog for more - and note that there's an installable component
library inside the distribution file (which also contains all the source code).

Here's something you can play with that media player:
Sun Developer Network, SDN, has started a monthly
developer TV channel
featuring interviews and topic segments. The first show aired two weeks
ago - but of course you can download and view the video anytime. The
first program was directed at college students and talked about how to
get into the industry. I'm one of the interview subjects.

Thursday, November 17, 2005

A Personal Touch

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

The Creator website has had an extreme makeover. In addition to the new organization of the material, most of the graphics feature members of the Creator team. These images have captions, so you can read more if you're interested. If you click on the
link for example, you'll see (at the bottom) a team picture of most of the team. (The team is actually larger than that; you can find all the names in the
Easter Egg...).

In the Code tab you'll see Joe and I discussing some component metadata. We really needed to talk that day so we didn't have to fake discussion in front of the photographer. The feature we discussed was how to let components specify metadata that allows inline text editing for components that have multiple text related properties. I implemented that portion in the designer the next day, so with the next drop of Creator you'll see improved handling for components like Alert, where you can click and edit either the Detailed message or the Summary. Ditto for Labelled components etc.

I know they have more photos of team members they want to use, so the site will continue to be updated...

Wednesday, November 16, 2005

Source Code Archaeology

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

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

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

I have two responses to that line of thinking:

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

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

    Source formatting typically doesn't rename variables (to wipe out the underscores ( _ ) from variable names) but
    it certainly could put the opening brace back up where it belongs, as well as remove the space between the method name and the opening parenthesis, etc.

    Reading the above code is the common operation. Tracking down line history is the occasional operation.

  • Second, and this is the more important point: You're probably not familiar with, or at least well versed in,
    source code archaeology.

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

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

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

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

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

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

Ok, so that's not really the command, but it's the common name for the cvs annotate method! It lets you figure out who to blame for the ridiculously stupid bug you just found in the code. The real name is cvs annotate.

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

tor:2% cvs annotate -r 1.42

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

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

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

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

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

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

Code Advice #8: Reformat all your code. Yes. Do it.

WARNING: This blog entry was imported from my old blog on (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 entry I covered source code archaeology. That entry was leading up to a coding tip: Reformat your source code.

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

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

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

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

Two final comments:

  • First, make sure that your formatting checkins don't contain any other changes (e.g. code changes); with lots of diffs it will be a lot harder to discover what they are. Future source code archaeologists should be able to read your "source reformat - no semantic change" comment and be able to mostly ignore that delta.

  • Second, if you're dealing with branches, you might think you would have a hard time merging changes back to the (reformatted) trunk, but no - that's easy: just perform a source reformat on the branch code too before diffing!

Monday, November 14, 2005

Podcast inteview with Jonathan

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

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

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

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

Wednesday, November 9, 2005

Cool new Creator demo

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

Check out
this cool new Creator demo. It's a pretty quick yet informative introduction to what Creator is all about.

Monday, November 7, 2005

Code Advice #7: Capitalize your Enum constants

WARNING: This blog entry was imported from my old blog on (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.)

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

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

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


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

Friday, November 4, 2005

Free Creator Licenses

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

Check the NetBeans web page right now - over on the right side. There's a link to a site where you get free access to Creator. No, not the already free Early Access version of Creator 2, but a license to the stable release - Creator 1. My impression is that this license will also be good when Creator 2 is released.

Thursday, November 3, 2005

Creator AJAX tutorial

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

The JavaOne demo has been turned into a

CSS Style Sleuthing

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

"How did that text end up with a blue color?"

"Why doesn't my style rule to add underlines on links work? Is some other rule overriding it?"

"What style class do I need to override to change the font size of my Table headers?"

These are some questions you may ask yourself when you're designing
your web applications using
Whenever you're dealing with CSS, the Mozilla DOM Inspector
is your best friend. It lets you examine the CSS rules and computed styles
for each of the elements in your document.
While it is extremely helpful in answering these questions:

"What CSS style rules apply to this element?" and
"What computed styles apply to this element?"

it is not as helpful with the (in my opinion more important) earlier questions.
For example, to find out how a particular element ended up with a
blue color, you need to start at that element, then look at all the
style rules applying to the element, look through its style declarations,
see if any have anything to do with color, and if not, go up to its parent
element and repeat the search.

Fortunately, there's a trick you can use: Creator's hidden DOM inspector.
This is a tool which is not a supported part of the product;
in fact it's a facility I added to aid debugging the webform layout
engine itself. But it turns out many of the questions I have to ask
are the same ones a page designer will ask: "How did that box end up
that wide", "What HTML did that component render", and so on.
(I have blogged about this
before, but there are new facilities in there for
CSS debugging which now sets it apart from the Mozilla DOM inspector.)

Here's how it works. Control-alt click on a component. The nearest
CSS box computed around the mouse click is selected with a red highlight,
and the property sheet selects a lot of the Box properties corresponding
to the HTML element rendered for the component. (Most components render
multiple elements; the DOM inspector works at the HTML level so you get
to see how rules apply to individual HTML elements.)

A couple of months ago I also added a little window display showing the
box hierarchy, so you can easily walk up and down in the box tree, like
Mozilla's DOM inspector lets you walk through the HTML Element tree.
One important feature here is that ask you click in the displayed page,
it expands nodes and selects the corresponding box. That's a feature I've
always missed in Mozilla's DOM inspector. Anyway, this part may have been
added right after EA2 went out so may not be available in your
version yet. But you can walk the hiearchy by pressing Escape to select
the parent box. Without the box tree window there's no way to descend;
you'll have to click on a box to select the closest leaf and then work
your way back up.

Here are the windows:

In the Layout Info window (on the left), the HTML tag is shown in angle brackets <>, and then the JSF component (if any) id is shown in italic.

The property display displays a number of interesting properties. I
may get back to some other ones later. But for CSS debugging, there
are two that really matter.

First, Computed Style:.
If you open the customizer, you'll see something like this:

This tells you a number of things. First, an asterisk (*) on the
left tells you that the value shown is different from the default
value of the property (e.g. has been overridden by somebody).
You then see the property, and the actual computed value.
The CSS2 properties are listed alphabetically.

Then, and this is the important part, it will try to tell you
where that particular value is coming from! This is shown
as the stylesheet name with a line number. This helps you answer
the initial questions. You can find the rule which is overriding
your intended rule.

(Note: Sometimes the line numbers are wrong - off by a couple.
Sometimes the line numbers are completely wrong. This happens
because I deliberately implemented the code which tracks style
usage to be extremely low overhead (since it's for debugging only),
and in particular, the CSS code tries to share Value objects
when possible. In cases where a single value object is used in
multiple places I cannot attribute different usage references,
so only the last one is recorded. Luckily, this doesn't happen
with attributes you are most likely to be interested in: font size,
color, width, height, etc.)

A second related facility is the "Rules" property. This
property lets you view which CSS rules apply to a particular
element. It is similar to the facility in the Mozilla DOM inspector.

(I added this property when checking my
performance optimization for CSS rule checking,
so it may not yet be in the version you're running.)

Here's a slightly different example. Take a look at the google
page for example. If I click on the word "New" (which is in red) because
I wonder where the Red is coming from, I see this in the Computed Style property editor:

As you can see, the color property is getting its value from an HTML
Indeed, the JSP contains this:

<font color="red">New!</font>

The color is coming from the color attribute. It's not always a
direct mapping; for example, a bgcolor attribute maps to the CSS
background-color property, etc.

Note that since this is a debugging tool, I have packed in a lot of
information, and this information is not cached in any way, so the display
is pretty slow. Also, the window is not tried to be kept up to date
etc. so sometimes you need to close the Layout Info window, and
reselect boxes on the designer surface to see their updated properties

By the way, on the Mac, you need to use Alt-Click instead of
Control-Alt click, because Ctrl-Alt click is "reserved" on the mac.

Happy sleuthing!