The Rave Room

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.

Part of the Rave room, taken on Marco's cell phone yesterday.

Roumen, one of the NetBeans engineers in Prague,
blogged
about his trip
to the U.S. For JavaOne, and mentioned that he's heard about the
infamous Rave room here in Menlo Park:

I've heard that there is some special huge office with 12 Creator developers on one place and it's interesting to see how they work together (I cannot imagine how this works, I need relative silence to be able to work efficiently).

Rave was the project name for the tool that eventually was named
Sun Java Studio Creator. When we started out, we had an extremely
aggressive schedule. (Some things never change...)
The project was unlike any I had worked in, or even heard about,
at Sun before. We had a small, very focused team that worked
like a small startup company. The team has since grown, but
we still hold on to some of the core aspects started two and
a half years ago.

The team is too large to fit in the Rave room now. But I still
spend all my office time there. In fact, I'm one of those Sun
engineers who have given up their regular offices. I figured
it was time to do that when I hadn't been in it for over a year!
I come in to the office twice a week, and on the other two
(actually, four :) I work at home.

My corner. Back off! Hey, who took my good chair?

When I'm in the office,
I sit in my Corner Office. This is a spot I've had since the
very beginning, so nobody dares to challenge me for it...
In the picture, you can see a Viking guarding my corner,
and the Dukie award I got two years ago for my

demo trouble
.

You may wonder how one can get any work done surrounded by
so many people. The key to that is that most of us
only work there twice a week. Those are days when you
schedule meetings, or work out technical issues on one of
the boards, or just get the pulse of the product and find
out what's going on by talking to people or overhearing
conversations. Of course there have been times when I need
to get some coding done at the last minute for a milestone build.
That's when I wear my noise cancelling head phones and
crank up some suitable coding music to drown out the
background conversations. Those who want peace and quiet
tend to disappear, probably to their offices, or for those
like me without one, to one of the flexible offices.

Having a shared space like this makes it easier to have
a team culture. For example, we have various artifacts
spread throughout the room - such as early marketing
posters, or award trophies and diplomas. There's even
a picture on the wall from the JavaOne 2003 keynote demo
when the product was launched. And, when we get near
a code freeze, we write the number of days left until
code freeze on the door.

Speaking of that, let me go see how many days we
have left...

<voice type="panic" pitch="high" volume="high" >AAAAAAARGH!<voice>

How to Write a JSF Component

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 JSF is gaining popularity, more JSF components are being written. In fact
TopCoder
is running a competition on writing components. (Sun is a
sponsor.)

However, some of the components written work, but do not work well in tools
like Creator, or do not work well when used in conjunction with CSS. In this
blog entry I will provide some hints that will make sure your components do
not fall in that category.

How to actually write a JSF component is covered in many places; it's
not hard. You need to write 3-4 classes, plus write a .tld file and
a faces-config file with some information about your component.

Here's a document which takes you through this process.

However, there are some additional Rules You Should Follow when
you write your component.

These rules serve two purposes:

• They ensure that your component will work right when it is
  sized and positioned using CSS properties.
  


• They ensure that your component will work well at designtime
  in a tool like Creator.
  

Here they are:

1. First and foremost, you MUST use the
   ResponseWriter's
   startElement,
   endElement and writeAttribute methods. Do NOT
   write out markup by simply streaming out HTML bytes linearly using the
   write method. There is one minor exception to this rule: some components
   need to emit HTML provided by the user, such as the HtmlOutputText
   component when its Escape property is set to false. In this limited
   scenario you should use write.
   


2. 
   Always pass in a component reference to the startElement method on the
   ResponseWriter. E.g. if your UIComponent is a PanelGrid,
   and you want to emit <table><tr><td>... you would
   use
   

   
   writer.startElement("table", gridpanel);
   writer.startElement("tr", gridpanel);
   writer.startElement("td", gridpanel);
   

   
   



3. 
   Every component should have a style property, which will render
   to a style attribute on the rendered HTML markup.
   This will allow tools like Creator to position and size the component (using CSS).
   It is vital that you remember to replicate this style attribute on your top level
   rendered HTML tag. However, there are some complications...
   
   
   
   1. In the normal case, you render a single top level HTML element (possibly with
      children) from the JSP tag. In this case, simply duplicate the value of the
      JSP tag's style attribute to the top level HTML tag attribute. For example,
      if you have <h:commandButton style="width: 100px"/> in the
      JSP, you would render <input type="submit" style="width: 100px"/>
      
   
   
   2. 
      If you need to render multiple top level HTML tags, but only one of them is visual,
      duplicate the style attribute on the one visual tag. For example, your component
      may want to render a <script> tag before it renders its one visual
      element, <table>, and then perhaps another non visual element, an
      <input> of type hidden.
      In this case, simply emit the <script>, then emit the
      <table> with the style property value from the JSF component,
      and finally emit the hidden <input>.
      
   
   
   3. 
      If you need to render more than one visual element as siblings at the top level, you
      need to wrap these in a single container component, such as a <span>
      or a <div>. (Use span only if all the children being rendered are
      inline elements.) The style property should be placed only on this outer, wrapping
      <span> or <div>.
      
   
   
   
   


4. Don't throw exceptions from your renderer! Even if for example value is a required
   property, don't throw a configuration exception just because it's null when you're rendering!
   If you really want your component to alert the user to the problem, I suppose it's okay to
   throw an exception when the component is used at runtime, but at designtime, it's quite normal
   for a component not to be correctly configured yet - after all, the user may just have dropped
   the component and is about to configure it. If necessary, you can have code in your renderer which
   checks if the component renderer is being used at designtime:
   

   
   if (java.beans.Beans.isDesignTime()) {
   // Designtime - better render error handling here
   ...
   } else {
   // Runtime - throw your exceptions if you must
   ...
   }
   

   
   One thing you might consider doing is having the component render exactly the problem message
   to the user. As an example, in Creator, if you drop the Message component, it will
   tell you if it is not bound to anything (since the for property is null, so the
   component is not yet configured.)
   
   

Once you have written your component you should package it up such that it can easily be
imported into Creator and used out of the box by your users. That is also covered in
the component library article I linked to earlier.

Please let me know if you develop components that work well with Creator!

See you soon?

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 2005 is getting closer. I'm hoping many of you will be able to make it.
One of my favorite things about the conference is meeting people, especially
users, and now with this blog, readers!

If you haven't been able to talk your boss into sending you to JavaOne,
you should still come to
NetBeans Day
the day before - it's free. Check out the list of speakers!
I'll be giving a Creator demo there. Be the first to see Creator, The Next Generation!
(As you can see from the schedule, there are two tracks, and the Creator talk is
track B around one o'clock.)

At JavaOne, I will also be giving a talk on AJAX, with
Greg Murray,
the Servlet specification lead:

TS-7986: Rich Web Applications With the J2EE^TM Platform and AJAX

It's not a Creator talk; we will discuss strategies and implementation
issues for implementing AJAX-based web applications on the J2EE platform.
Be there or be static. (Put it in your schedule now.
Tuesday, June 28, 11am - Esplanade 307/310. Room capacity 1200.)

I might also be involved in some other demos but that's still TBD. And of
course, I'll be hanging around the Creator booth a lot, so if you find it
(which wasn't easy last year - I hope we get a better spot) please stop
by and introduce yourself!

Last but not least - not even CLOSE to least - the parties!
I'm not sure if we're having a Creator party, but if we do, I'm there.
And I definitely don't want to miss the Borland party! And I'll try to
crash as many other events as possible too!

OnlyOneReturn Considered Harmful

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

mentioned PMD
and how it's vital to learn how to customize the ruleset, since by default
it includes some rules that are evil. Evil I tell you!

My favorite rule to hate is the OnlyOneReturn rule. This rule basically
says that

A method should have only one exit point, and that should be the last statement in the method.

Unfortunately, the rule author does not provide supporting documentation
for this point of view, and I personally cannot think of any.
In fact, restricting yourself to a single return statement makes the code
less readable. Take the following method from the JDK's Integer
class for example.

public static String toString(int i) {
if (i == Integer.MIN_VALUE) {
return "-2147483648";
}

int size = (i < 0) ? (stringSize(-i) + 1) : stringSize(i);
char[] buf = new char[size];
getChars(i, size, buf);

return new String(0, size, buf);
}

We have a special case, and it's dealt with right at the beginning of
the method. If we hadn't done that, we would need to slap a big else
block around the remainder of the code, as well as introduce a temporary
variable, e.g. result, to hold the return value that we then
return as the last statement of the method.

The above is a trivial example, but I frequently write code where I have
multiple exit points early in the method that deal with special cases, and
this avoids the need for deeply nested code.

Creator's Visual Page Designer Source Code: Proud OnlyOneReturn Rule Violator
Since 2003.

NetBeans plugins I use, part 2

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.

In my first favorite plugin
entry I described Jalopy. The other external plugin I use is PMD.

PMD is a source code analysis tool which parses java source code, and then
runs a large number of rules over the source code. For example, it checks
for program errors, like double checked locking patterns, or overriding
equals without overriding hashCode. It checks
for potential program errors, like having an equals method
with a single parameter that is not of type Object. And it
checks for a number of coding style "violations", such as for example
failing to use uppercase letters for class constants, or using excessively
long or short variable names.

Here's a screenshot of PMD in action: you select a class or a package and
run PMD on it, and all the rule violations are listed in the output window,
where you can click to bring up the relevant source (or hit F12 and Shift F12 repeatedly
to iterate forwards and backwards in the list.)

Thankfully, the ruleset is configurable. That's important, because I the
default set of rules you get is not particularly good. It includes a rule
I truly hate (and because I disagree with the result, I violate it all
over my code, with the result that unless I customize the ruleset I get
a bajillion rule violations when I run PMD on my code. I might write a rant
about that rule in another blog entry...)

Customizing the ruleset is easy, once you know where to find the
dialog: Tools | Options | IDE Configuration | Server and External Tool Settings | PMD Settings. Open the Rules customizer in the property sheet,
and you get the following dialog:

Here you can move available rules to and from your chosen set of rules.
Try adding all at first, then removing rules that get flagged in your code
that you don't care about, or that you disagree with. More importantly, you
can click on each rule to see a description and example of the kind of code
that triggers the violation. This is really useful if you want to see if this
is a rule you want to check for - and to get the rationale from the person
who contributed the rule.

Note that you cannot get it to be happy if you use all the rules, since
there are contradictory rules. For example, if your bean class has no
constructor, you get the AtLeastOneConstructor violation telling
you your class needs at least one constructor. But once you add one, the
UnnecessaryConstructor rule will tell you
that a constructor is not necessary when it's public and has no arguments!
So learning how to configure the ruleset is essential.

I've been following PMD for quite a while. A couple of years ago
I wrote a plugin that took the PMD integration a bit further in the IDE.
I had written a suggestions window for NetBeans, and I plugged PMD
into it, along with automatic fixers for some of the rules. So for example,
if PMD flagged a method as unused, you could just double click to get
a removal preview dialog, and then click again to nuke the method.
Here's a screenshot of this in action on an unused field:

As you can see, this screenshot is old - look at the old icon style, or the old property sheet,
and the old window manager... I think this was in NetBeans 3.4.
(More suggestions window screenshots here)

Unfortunately, this was a hobby project, and I suddenly got
extremely busy working on
Creator
since we were trying to design
and develop it with a suicidal schedule, so my spare time become occupied
by work instead. I haven't been able to keep it up, and now it looks like
it will take some work to bring it up to speed. However, in the meantime
part of the suggestions framework has been incorporated into standard
NetBeans (specifically the TODO scan portion of it), and I saw some
comments on the dev@tasklist alias that Jan Jancura is going to do some
work in this area so perhaps we can get this going again.

It also looks like the PMD plugin itself on SourceForge is getting some
attention with some recent development, so I think this going to get
even better soon.

To download the plug-in, visit
this link,
download the most recent release, unzip it, and then from the Tools | Update Center choose
to install a locally downloaded nbm file.

Converting an int to a String

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 came across
this tip in a blog referenced from
Eric's linkblog.

The author mentions that you can convert from an int to a String like this:

int one = 1;
String str = one + "";

And he calls that cute!

I disagree - I think that's ugly (and as he points out it's less efficient).

There's a clean way to do this, not listed in his blog:

int one = 1;
String str = Integer.toString(one);

Nice efficient bytecode too:

0:   iconst_1
1:   istore_1
2:   iload_1
3:   invokestatic    #2; //Method java/lang/Integer.toString:(I)Ljava/lang/String;
6:   astore_2
7:   return

and there are variations of the method which lets you convert using another base - so you
can convert to hex using Integer.toString(one, 16) for example.

(String.valueOf(int) will turn around and call the above method by the way.)

Dr. Dobbs Journal Article

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
July issue of Dr. Dobbs Journal
contains an article I've written, covering the combination of
JSF
and
CSS
and the
nice synergy you get from combining these.

You can read the

article online here
. I've covered this material in various blogs before, but in the article I try to tie it
all together nicely. I hope you find it useful!

DDJ has a special place in my heart. In high school and college I was really interested
in computer graphics (and in fact I ended up specializing in it in grad school). DDJ had a regular column
on computer graphics by
Michael Abrash.
I remember pouring over his article on fast
Bresenham line drawing, and another one describing Wu's technique for antialiasing. I tried to
google these articles just now but all I can find are references to them, not the actual
articles. Probably a good thing since I'm really busy with a deadline and can't afford
to get excited about graphics algorithms at the moment!