Saturday, December 31, 2005

Kids Nowadays...

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.


Joel Spolsky recently blogged about the perils of Java schools. The introduction goes like this:


...When I was a kid, I learned to program on punched cards. If you made a mistake, you didn't have any of these modern features like a backspace key to correct it. You threw away the card and started over.



That instantly reminded me of my favorite Dilbert - one I have handy now because I used it in one of the first few slides in my JavaPolis presentation. I think it portrays a pretty common attitude in the programming world - "it was hard and we liked it that way!"





Thursday, December 29, 2005

Real 3D Graphics

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



I've been on vacation this week - and I took last week off too. One of the things I did was to take my kids to a movie called
Polar Express.
We saw it last year - but this year it has been re-released in IMAX theaters in full 3D.



Lots of games claim to be in 3D - but what you're really seeing is a projection of 3D onto a 2D surface like your monitor. Cues like perspective and occlusion lets your brain figure out (through educated guessing) the spatial relationships. However, we can do better than that. If you look around, you can actually perceive depth around you. If you look with just one eye, the depth perception disappears (and you're back to the two dimensional view again where you guess things based on size, appearance, occlusion, etc.).



The trick to presenting a real 3D view, is to project two different images to the viewer - one for the left eye, and one for the right eye. Objects far away appear in the same place in the two pictures, but objects closer will appear in different places. A finger held right in front of your face obviously looks different from the left eye than from the right eye, even though the distant background stays roughly the same.



A number of things have been tried. One way is with color glasses - usually one red lens, and one blue lens (anaglyph stereo). The whole trick here is that the 3D image can be presented as a mixture of red and blue. Since these colors are complementary, the overlaid red and blue images blended together will be split apart again by the red and blue eyeglass lenses. (The red lens will see only the blue colored image, and vice versa). The problem with this approach is that you can only do "grayscale" images - the red and blue lenses obviously warp any attempts to do full color images. Here's an example of such an image. I created this with a raytracer I wrote ten years ago, back when I was really into graphics and real 3D in particular. It's a simple model of some screenshots from the product I was working on at the time (Sun's Workshop debugger) along with a 3D model of the signature green "Run" debugging arrow:








Another approach is to use 3D shutter glasses. Here you're using a special headset which very rapidly opens and closes the left and right eye lenses in succession. This is synchronized with a computer, which shows the left image followed by the right image. This allows full color 3D, since you're using time rather than color to do the image separation. I've never tried this technology so I don't know how well it works but I believe it's been used in games.



Another approach is the original, historical approach to viewing 3D images - "free" viewing. Here you simply show the two images, right next to each other. With a little training, it's easy to view this image and visually fuse the two together in your head (by changing your eye focus to be behind the screen) and suddenly see a 3D picture in the middle. Try it.






In the Polar Express IMAX version, however, they were using another technique which relies upon light polarization. The trick here is to use two movie projectors, projecting through perpendicular polarizing filters. Viewers then also view through glasses with perpendicular polarization lenses. The net result is that you get to view beautiful (full color, no time lapse) stereo images. I assume it was fairly easy for the creators of the Polar Express to create a 3D version - they already had the full 3D models; they "simply" had to render all the scenes over again - twice, one from each eye location. Hope they had good rendering hardware.



I had heard a lot about the polarization technique - but this was the first time I actually saw it. It looked fantastic - and of course the "screen resolution" in IMAX films is fabulous. But there is one remaining problem. I discovered that I tend to lean my head to one side or the other during a long (two hour) movie - and as soon as you do, you start seeing visual artifacts. Your head had better be completely aligned with the polarization axes! (And the images also were rendered assuming a horizontal pair of eyes).



All in all it was definitely the movie experience of the year - yes, there have been movies I enjoyed more, but the combination of cool technology and seeing a movie that the kids loved so much and really put them in the mood for Santa was ..... priceless.



(P.S. That's a good thing since the tickets were nearly twice what I'm used to - $15 for adults and $10 for kids!)


Tuesday, December 13, 2005

Spoona Sutra - another Java conference trip report

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'm spending this week in Europe. Yesterday I was in Antwerp for
JavaPolis - an annual Java conference in Belgium hosted by the local
(and very active) user group. I did a talk on Creator. I basically
lost my voice the previous night through heated and interesting
discussion... so talking for two hours the following afternoon
was pretty tough. And not good for voice recovery - so I'm not
sure I can do a remote podcast with
the guys
this week. Too bad, since I had dinner with
Romain Guy
last night and can finally pronounce his name correctly!






The conference was held in a really interesting venue: a modern
movie theater (which perhaps explains the name - the movie
theater is named Metropolis).
That meant the seating was unbelievably comfortable -
soft seats, tall backs (tall enough that you can rest your head),
and best of all - a giant projection screen - the movie
screen itself. It's pretty amazing to see your tool running on
a giant movie screen! No need to worry about small fonts... The
picture on the right shows
Ludo in action.



To combat the jetlag I went and grabbed some coffee. I added
sugar, but couldn't find spoons anywhere. So I had to stir with my
finger. Then I noticed

where all the spoons had gone - and what they're doing!

(Yes, that's the official artwork used by the
conference - on slide templates, on publicity posters, on T-shirts, etc!)



Unfortunately I could only stay in Antwerp one day. I'm spending the
rest of the week in Prague, where we're having many important
planning meetings. I'm sure I will miss many interesting presentations.
During Ludo's presentation yesterday morning he demoed
a new AJAX-ified version of PetStore. It looked fabulous. He also
mentioned the high performant "Grizzly" engine in Glassfish, which
uses java.nio to get extremely high performance. I'm going to find
out more!




Thursday, December 1, 2005

Performance profiler - now for the Mac!

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.





Milestone 11
of the NetBeans Performance Profiler
was released today. It's mostly a bug fix release, but it sports one big new feature: Support for Apple OSX!
This is a big deal. The NetBeans Profiler is based on
JFluid, a new
approach to performance profiling. Rather than using the standard JVM performance interface, it used
a special modification of the VM to do its profiling more accurately. Because of this, you had to download
special VMs to run your application - and of course, those modified VMs did not include OSX (where the VM
is provided by Apple rather than Sun).



The JFluid hotspot modifications have been integrated into the JDK. As of JDK 5 update 4 (or thereabouts)
you can use a standard JDK with the profiler and everything works beautifully. And I guess Apple's recent
update to JDK 5 must have synced up to the codebase which includes the JFluid modifications, since the profiler now works.



The "What's New" document describes this feature as experimental - so of course I had to try it! It seemed to work well on my test case. I created a sample project (the Anagram sample that ships with NetBeans), then invoked the Profiler. After calibrating the timers I needed to restart profiling. From there everything went smoothly; I hit the GUI button a bunch of times, then clicked on the Take Snapshot button in the profiling panel. Voila! The result screen pops up letting me drill into both the hotspots and the overall cumulative time view.



Click on the screenshot for full size. And check out the Profiler Screenshots off the profiler main page; as you can see there are various telemetry views and other goodies there.



Very promising. If you're a Mac Java user, be sure to try it out and provide feedback and bug reports to the profiler team such that this feature is stabilized as quickly as possible!




Wednesday, November 30, 2005

ClariFREEcation

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



A 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 blogs.sun.com (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.

Here's
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 blogs.sun.com (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 blogs.sun.com (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
Community
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 blogs.sun.com (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 Foo.java. To see what the file looked like before that, simply do


tor:2% cvs annotate -r 1.42 Foo.java

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 foo.bar;
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 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 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 blogs.sun.com (which used different blogging software), so formatting and links may not be correct.


The
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 blogs.sun.com (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 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.)



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
this
technical article enum constants are in all lower case, in
this
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.



So:


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 blogs.sun.com (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 blogs.sun.com (which used different blogging software), so formatting and links may not be correct.


The JavaOne demo has been turned into a
tutorial.


CSS Style Sleuthing

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.


"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
CSS.
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
attribute.
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
etc.



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!


Tuesday, October 25, 2005

"I still love Java after all these years"

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.



Be sure not to miss the latest Java Posse interview: #9 - Joshua Bloch. In case you don't know, he's behind java.math, the Java Collections framework, annotations, and my personal favorite book on programming: Effective Java.



In the interview you'll hear what he would like changed in the Java libraries, you'll hear about his plans for an update to the Effective Java book, his thoughts on Ruby and Python, and of course we cover his feelings about Java. The title of this blog entry is a direct quote.



I won't, and haven't, posted a note every time there is a new Java Posse episode. (There is a blog on the javaposse page you can subscribe to for that.) But I really didn't want you to miss this one!



One note on the audio quality. You may notice that the interview episodes have lower quality audio then our news programs. That's because when we interview people, we need to use either the phone, or some kind of voice over ip solution like Skype, which means we can't use the better quality (but harder to set up) rig we have for our own recording sessions. Bear with us. We're looking into better solutions for the future.



If anybody would like to create transcripts of some of the interviews (people have requested them) we don't have time to do that ourselves but would happily post contributed transcripts.









Wednesday, October 19, 2005

Security: Block worms from your abusing your web apps

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 fascinating piece about a worm that spread quickly through the MySpace web site.
What's remarkable is that the web site had pretty good security. The person who did it used some pretty clever techniques to make it work.
I highly recommend reading the write-up, and especially his detailed explanation for how he worked around each security measure.



Briefly, since the site lets you enter HTML in your profile, he wrote very clever HTML that would get executed in other people's browsers whenever they viewed his profile. The executed HTML would automatically do various background posts (using ajax techniques) to automatically execute a requests and confirmation responses on their behalf. It would have the author added as a "friend" to the account, and then it would add the same html code to the new user's profile such that anyone viewing this profile would become "infected" in the same way. The worm spread to a million users in a matter of hours!


Myspace already had various security measures in place, such as blocking out dangerous tags, and removing strings such as "javascript" and "onreadystate" completely. He got around that by taking advantage of browser bugs. For example, even though myspace removed references to javascript, it would not remove java\nscript, and it turns out IE will still recognize this as a javascript URL, even with embedded newlines in the name! As another example, even though onreadystate is blocked out, he could use his ability to execute JavaScript to reconstruct it with string concatenation:



eval('xmlhttp.onread' + 'ystatechange = callback');


Fascinating. This got me thinking. What if you wanted to have a Comments feature on your web app written with Creator.
You want to allow the user to enter some HTML, such that they can add emphasis, use paragraphs etc. But how do you prevent
HTML that compromises your web site?



It seems like a really safe way would be to prevent any HTML attributes from being entered! As long as you don't allow attributes, and you don't allow the style or script tags, you should be safe. This may be overly restrictive, especially for a site like MySpace which tries to let users customize their pages visually. But at least for a comments feature it should be viable.



I took a quick stab at this with Creator. What we'll do is this: Use a TextArea component for the comment. We'll add a Validation event on the text area, and the validation will check the string for suspicious text. If it sees a problem, it will raise a validation error, and the messsage will be displayed in the Message component associated with the text area. I drop the components, then right click on the
text area and choose Add Event Handler | validate, as shown below (click for full size):








Now we'll just need to write the code. Once you add the event handler, you're placed in the source editor and get to edit your code.
By default you get a simple comment telling you roughly how to write a validate event handler:


public void textField2_validate(FacesContext context, UIComponent component, Object value) {
// TODO: Check the value parameter here, and if not valid, do something like this:
// throw new ValidatorException(new FacesMessage("Not a valid value!"));

}



Here's a simple implementation - pretty naive. It doesn't try to properly parse the HTML,
it just looks for occurrences of <, and when found makes sure that it's properly matched
with nothing other than an approved tag and an optional / at the front or end.
Am I forgetting to handle some other tricks worm developers can take advantage of?



Here's
the event handler - shown as an image since many news readers completely butcher formatted
text in attempts to make blog entries comply to their site style; click link for text version.






Here's how this looks at runtime:






(No, the error text didn't magically move from the top of the text area to the bottom;
I moved it between taking the first screenshot and taking the deployment screenshot.)



P.S. Don't forget to hook up the Message component to the text area, such that it displays
errors raised in the text area's validator. Do that by dropping it, then follow the advise
listed in the default message area on screen text: Ctrl-Shift Drag from the message area
to the text area (or vice versa). If you use a Message Group component, you don't have
to "bind" it to any components; it will display error messages from any and all components
on the page. It's a good habit
to always have one during development.


Saturday, October 15, 2005

New Toys: Hot workstation and nice fonts!

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





I've got a new toy: a brand new Sun Ultra 20 workstation. It's for home use. It's a great system, and very fast. I used one of these to do my coding challenge back in June. Now I've got my own!



(If you're looking for a new home computer, check these out. They're using AMD 64 bit Opteron processors - mine is 2.6 Ghz - so you can run many different operating systems on it. Here's a very enthusiastic review of it, and
here's another. I just wish
the fan could have been a little quieter.)



I decided to put Ubuntu linux on this one. It was straightforward. (I had first tried putting Fedora Core 4 on it, including the various java tools. But those systems do all kinds of weird things to support Java (some kind of GCJ variant plus various "smart" scripts which essentially prevented ant from running). For Ubuntu I didn't install any of the Java development tools, and instead downloaded them directly myself and put the latest Ant and Tiger on there.



I then decided I wanted smooth fonts; after looking at nicely rendered fonts on an Apple laptop it sure hurts the eyes to look at the default configuration of a Linux desktop! Luckily I could enable subpixel antialiasing in one of the configuration screens. Much better. But my IDE still didn't look good. That reminded me that Mustang, the next generation JDK, will support LCD subpixel rendering. So I downloaded Mustang, restarted NetBeans with it, and lo and behold - it works very nicely. The following screenshot shows the before & after effect but will only look right on LCDs:






Here's some more indepth analysis of the rendering changes.


Friday, October 14, 2005

AJAX+Java FAQ

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.


Greg Murray has posted a comprehensive FAQ on AJAX as it relates to Java. If you want to dip your toes in Web 2.0,
this looks like a great resource and starting point.


Monday, October 10, 2005

Code Advice #6: Write debuggable code!

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



It's important to write readable code. But that's not the whole story. Your code should be easy to debug too. In this blog entry, I'm pointing to some Bad code patterns that makes your code hard to debug.



The first, and most evil practice is to write a conditional on the same line as the if:



if (foo) bar();


Yes, this already violates other rules of good coding style in that it's missing braces. But even the cleaned up version is no better in terms of debugging:



if (foo) { bar(); }


This is Bad for debugging because as you're stepping through code, the whole if block becomes a single step! While you're debugging, you typically want to know if the conditional branch was taken or not. With the "correct" three line version this is not a problem; you step once over the if, and you can then separately decide if you want to step into the conditional method call for example.



if (foo) {
bar();
}


You may not realize you're guilty of the above problem, but if you use the ternary operator, a?b:c, you might be. The ternary operator is really an if-then-else block in disguise. Don't write code like this:



x = foo ? bar() : baz();


for the same reason as above: this is now a single debug statement so it's hard to decide if you want to step into or not (if you for example are only interested in stepping into if the target is baz().)



This frequently comes up in conjunction with return statements. I've seen coding styles recommend you to use ternary operators instead of if blocks. This is where code simplicity (for those who feel that a terse ternary statement is more readable) goes squarely against debuggability. I recommend you stick with the if block. I feel if blocks are more readable too. The argument for collapsing statements is usually that it makes the code more dense, so you can "fit more on the screen", but the same argument could be used against whitespace between logical code blocks and methods etc., and I think we all agree that optimizing for code density is not optimizing for code readability.



Another bad code pattern for debuggability is



getFoo().getBar().getBaz().doit();


or even the slightly less evil, but still bad



getFoo().doit();


What's wrong with this? Convenient SteppabilityTM. In this pattern, all the method calls before the last one are simply getter calls. The doit() method is the interesting code we want to step into. However, since all the preceeding accessors are called in the same statement, we have to Step Into, then back out of, each method in the call chain up until we finally get to the interesting method!



Overshooting (the technique
of Stepping Over, then Undoing when you've gone too far
) doesn't work here.
There are some simple workarounds; for example, some debuggers let you put the caret on the last method, and then invoke a different stepping action to step into the desired method. But this is clearly inconvenient; you don't want to force users who are rapidly stepping with F7 and F8 to have to click to step into interesting code.



Thus, you should write the above code like this instead:


Foo foo = getFoo().getBar().getBaz();
foo.doit();


Obviously, if any of getFoo(), getBar() or getBaz() were interesting too, you could break
this up further, but the whole point here is that you typically don't want to step into accessors (which I'm assuming the above are) so get those into their own statement. Now you can step right over the first line and into the second.




Tools can help this situation. In Sun's C++ development environment, there is a fourth Stepping action: Run Into Last Statement Call. This stepping action "magically" achieves precisely what you want: It analyzes all the method calls in the current statement, and steps into the last such statement. The net result in that the code example above (before we broke it up) you could click on the Run Into Last Statement Call button, and it would step right into doit() ! I really really want that action in the NetBeans debugger. I guess it will require some fancy bytecode analysis. The screenshot on the right shows the Stepping action part of the menu in Sun Studio - the last action is the magical one...






Thursday, September 29, 2005

Mixing JSF and HTML

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


A subject that comes up regularly is how to mix HTML with JSF. There are several gotchas and limitations you need to be aware of.


  1. The "content inter-weaving problem". The issue here is that if you mix and match JSF components and normal "plaintext", these are processed separately, and it's possible for the text to appear out-of-sync with the component. See this article for more information. However, the good news is that this issue is fixed in JSF 1.2! (Creator however is still using JSF 1.1; JSF 1.2 is not out yet.) You need to be aware of this issue, and obviously test your application thoroughly. The problem does not show up
    at designtime in Creator because we don't process the page using the normal JSP engine.

    • You can use a <f:verbatim> tag around your markup to make it "JSF friendly". This will force the embedded text to be processed by JSF rather than the JSP handler, so the right thing will happen.

    • In Creator 2 you can also use the <ui:markup> component. It's easier to use than <f:verbatim> for some use cases. It's in the Advanced palette.




  2. Components that render their own children frequently don't handle HTML child content. (Examples of these are the Data Table, and the Panel Grid components.) These are the UIComponents that return true from getRendersChildren.
    These components specifically state that they want to handle rendering of their children themselves, and unless they
    are really careful, they won't pick up the HTML markup children nodes (whereas the standard child iteration used for
    most components does get this right.)
    Thus, for these components you need to resort to the <f:verbatim> technique again.




  3. By now you may wonder why you wouldn't ALWAYS just put <f:verbatim> around your HTML tags - and all your problems would be solved. The problem is that what verbatim does what its name suggests - it renders its child content verbatim. That means you don't get to put other JSF components inside of it! You'll see your JSF tags emitted as text. In other words, you can't freely insert <div> tags around your JSF content to do normal HTML page layouts.




  4. Your HTML needs to be well formed XHTML. This isn't necessarily a JSF requirement, although it should be noted JSF emits XHTML, not HTML. However, Creator requires this. Specifically this means that you need to remember to close your tags - I've often seen people write <br> which is invalid XHTML. It needs to be <br/>. As another example, remember that your tags need to be lowercase - don't insert <STYLE>color:blue</STYLE>.




  5. The way you actually add HTML to your web pages is to switch to the JSP view and edit away.
    However, note that you don't get to write plain HTML there, because you're actually editing an XML-formatted JSP
    file. Tags work the same way as in HTML - you can for example add <hr> to add a horizontal ruler.
    But entities are different. They need to be "XML escaped". If you want to write the HTML entity for the Spanish n for example,
    ñ, you cannot simply write &ntilde;. You have to replace the & with &amp;. Thus, if you want the page to render in the browser as Piña Colada, in HTML you would have had to type, Pi&ntilde;na Colada, but in the JSP file you need to escape the & such that you end up with Pi&amp;ntilde;a Colada.




With all those potential problems, you may wonder why you should bother with HTML at all?
It would be ideal if you didn't have to.
However, if you restrict yourself to standard JSF components there is simply too much markup you cannot get to. For example, you cannot add a horizontal ruler since there's no component for that. In Creator 2 we have a new component library which adds a wide array of new components.






However, there are two remaining areas where you might find yourself resorting to HTML.


  • Flexible layouts. If you want to achieve a really advanced layout that offers good resize behavior etc. you may need to resort to old-school HTML tables with rowspans and colspans. However, I urge you to consider using CSS for your layouts instead. It may be a bit harder at first, but it will pay off. True, CSS is not supported well in older browsers, but many of these older browsers aren't supported for similar reasons in the existing markup rendered for many components already.



  • Pre-existing content. You may have existing HTML that you want to reuse directly - perhaps it was crafted by a web designer and you want the same look in your JSF app with no rewrite effort. You can import these into Creator using File | Add Existing Item. The screenshot on the right for example shows the java.net page imported into Creator. The import mechanism will not catch all the gotchas above however so you need to Test, Test, Test.




As should be evident from the gotchas list however, you need to consider this carefully.


Java Posse Episode #1, I mean #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.


A new
episode
of the Java Posse podcast is available. Episode #1 was an interview recorded a while back by Dick, so this episode is actually our first joint recording. It was a fun start.



Let me apologize in advance for using the phrase "you know" way too much. It's, you know, totally subconscious. Next time I'll try to slow down and reduce the you-knows. And Carl is getting a new microphone :-)



iTunes link


Wednesday, September 28, 2005

NetBeans 5.0 Beta

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.





NetBeans 5.0 Beta is now
out. In my
blog entry
yesterday I wrote how easy the new plugin support made it to add
my own favorite debugging function to the debugger.
There's a long list of big improvements over 4.1. Click on the image to go to the "What's New"
page and see descriptions with screenshots of the new goodies!






Tuesday, September 27, 2005

Suggestion #5: Debugging with Undo

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.






Until now in this "column"
I've written about source code itself:
Don't use vanity tokens,
don't capitalize acronyms,
don't use tabs, and
don't (over)use logging.
Today I'd like to talk process instead: debugging.



The process of debugging usually involves mental verification:
you step through the code, and compare what you think
should be happening with what is actually happening.
As you do this, you frequently have to decide if you should
Step Into or Step Over method calls.
On the one hand, you don't want to step over a method in case
the bug is occurring within the method call. On the other hand,
if you don't know where the bug is yet, you can waste a lot of
time stepping through methods before the bug is triggered.



With the following technique however you get the best of both
worlds. The approach is as follows:
Always step over. If you detect
that the bug has happened (e.g. some return value from a method
is wrong, or a class field is changed into the bad value you're
looking for, etc. etc.) then simply Retry the method.
By retry, I mean pop the current stack frame and step back
into the method! This gives you a primitive "Undo" function.
Without restarting your program, you get to step through the method
again.



Many debuggers offer actions to pop the stack, so you can use this
technique today. What I really want however is a convenient action
which does both of these operations (pop followed by step into), and have
it located in a convenient place such as the debugging toolbar.



So I decided to try out the new NetBeans 5.0 module plugin
development support. Holy cow! - It was unbelievably easy!
In 25 minutes, I wrote a plugin (which adds a debugger toolbar action
which pops the stack and steps into in one step), I generated a plugin
bundle, installed it in the IDE and tested that it works on a simple
test program. And this was as
a first time user of the plugin support! I especially liked the "New | Action" wizard
which automatically handled everything from icon and displayname to positioning
the action in the menus and toolbars.



I'm not exaggerating - it
took just 25 minutes. And I'm not bragging either; doing all this in 25
minutes says something about the productivity of the tool, not about my programming
skills.
There's a quick-start
document
available with more information on how to build plugins in 5.0. But I
wrote the plugin while on the train commuting to work, and without a network connection
I figured it out anyway on my own.






You can download and install
the plugin yourself in
NetBeans 5.0.
As you can see, the main source file is
very trivial.



The screenshot on the right (click for full size) shows the IDE in action; notice the new action in the toolbar
(easily spottable by the ugly icon I supplied) as well as the plugin project in the navigator.



Anyway, you can use this retry technique as long as your IDE supports
Pop Topmost Stackframe. It sometimes requires a little work on your
part. If you're stepping through a method that has side effects
(such as initializing fields), you may have to account for
these. By "account for" I mean undo the side effect. Usually I handle it
by clearing out the fields in the watch window after popping the stack.
You did realize you can change values in the Value column and cause
assignment in the debugged process, right?






Monday, September 26, 2005

iTunes link is up

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 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, September 22, 2005

Java Posse - the JavaCast reincarnated

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 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 http://javaposse.com.



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 http://feeds.feedburner.com/javaposse






Better radio

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 morning commute. The San Francisco bay area has lots of radio stations to help you through it - provided of course you enjoy listening to commercials or "flipping stations". And despite the large number of software people in the area, the morning show topics are invariably the safe staple of morning shows anywhere: celebrity trash, traffic, and endless banter. Oh, and if there's ever a good segment, you can be sure it's right when you're about to lose reception as you're heading into a tunnel or the train is going underground.



One of my coworkers today asked me what the deal was with "podcasting". It is not named podcasting because people walk around recording their diaries on their iPods. Podcasts are basically radio programs. iTunes and your iPods have special support for podcasts, and treat them quite differently from regular music files. In particular, in any given program, it remembers where you left off. Therefore, if you come back to play the same program later (having played other music other podcasts in the meantime), it continues right where you left off. Podcasts are organized separately from other music, and is listed chronologically automatically. And today I discovered that if you hit pause, and later resume, it will back up a couple of seconds in the soundfile such that you don't miss a single word.



So, podcasting is really the ability to broadcast radio programs to pods - playing devices. This has some advantages. For example, since they don't rely on the airwaves for distribution, they don't have the same restrictions that radioprograms do, where the range is so limited they have to focus on topics of broad population interest. Instead, you can have highly specialized podcasts with listeners spread throughout the world. I've found it a great way to replace my constant radio frustration. Reception is perfect since you're not relying on an antenna. The topics are interesting since I picked them myself. And in addition to the special interest topics, I can get good radio programs like NPR's Nova and Jim Lehrer's Newshour.


Wednesday, September 21, 2005

Code Advice #4: Don't capitalize acronyms!

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



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.



Eof.


Tuesday, September 20, 2005

Page Fragments, Entities and Characters

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.


Switch to your JSP, and inside the body tag, type

One Piña Colada, Please!

If you run, you should see the expected text in the browser.



Now try the same thing, but edit the text inside a page fragment.
If you deploy, you'll see this in the browser:

One Piña Colada, Please!



Uh oh! What happened?



Turns out the app server doesn't realize that the page fragment file, the jspf file,
should be interpreted as an XML-formatted JSP, just like the main document. As
a result, the source fragment file (which is just a static JSP include behind the
scenes) gets, well, mistreated. You can see a very similar thing with entities.
If you go and insert JSPX entities in your fragment, these will not be correctly
expanded and instead of spaces you'll see things like "&nbsp;".



Here's how you can fix this. You basically need to tell the deployment container
that it needs to treat .jspf files as XML formatted JSPs. Unfortunately, you
can only do that using JSP 2.0. That means this won't work on deployment containers
that don't support JSP 2.0. The bundled one, Sun Application Server 8.1, does (as
does 8.0 which we shipped with Creator 1.0, so this solution works for Creator 1.0
as well.)



Switch to the Files view (it's in the same window container as the project navigator),
drill into your project, then open web/WEB-INF/web.xml. Switch to the
XML view. Replace the root <webapp> element with the following:


<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">


And then inside the body, insert the following:

<jsp-config>
<jsp-property-group>
<url-pattern>*.jspf</url-pattern>
<is-xml>true</is-xml>
</jsp-property-group>
</jsp-config>



This is how this should look:






Now when you deploy, the page fragment text should be treated the way it's supposed to - and your Piña Colada will be on the way.



So why don't we just add this configuration info to the default web.xml we ship with Creator? Well, then you would no longer be able to use Creator with any older app servers. We're trying to hard to be compatible. However, we might be able to do something better here. I'll talk to Mr. Deployment to see what we can do.



New Creator Blogger

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.


Say hi to Winston Prakash - another Creator developer who now has a blog.
Winston wrote the new CSS editor in Creator 2 that I described a while back. I
sometimes call the CSS Editor the Winston Editor...


Saturday, September 17, 2005

JSF Refactoring Support

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.


Creator 2 EA2 now supports JSF refactoring. Take a look at this screenshot of the Refactoring window:






You might think supporting Refactoring is a slamdunk since we're built on top of NetBeans 4.1 which supports refactoring.
However, notice that we're doing a lot of JSF specific stuff here.


  • We update value binding expression references

  • We update navigation rules

  • We update managed beans definitions

  • We update web.xml if the start page has been renamed




Eric had to do a lot of work to get our Creator source modeller to play nice with
the NetBeans one. Yes, we're working to resolve this architectural redundancy - that was partly the agenda for the August
trip to Prague.
Here are some of the suspects at our favorite breakfast bistro in Prague:
Robert Brewin,
Tom Ball, and
Eric Arseneau. Yes, the Eric who did the Creator refactoring work.
This particular cafe serves the largest lattés I've ever seen; not quite "Big Gulp" size but certainly
a healthy morning dose to combat jet lag!





Wednesday, September 14, 2005

New Bits Available! New Features!

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.



An update to the early access version of Creator 2 is now available.



The high level changes in the update are described here.



Here's my own list of stuff to look for in the update - heavily skewed towards the changes in the designer and related areas!


  • It now runs on (and in fact, ships with) JDK 5.0.

  • Various memory leaks have been fixed so it doesn't deteriorate over extended use. However,
    performance work is still ongoing.
  • We now have inline editing of buttons, textfields and textareas as well. Note that when you
    drop a button you immediately edit its name. This is to strongly encourage you to provide a
    specific label rather than relying on defaults (which vary from browser to browser, and can interfere
    with your layout.) To enter inline editing mode (which is done by default for buttons, but not
    for text fields), click twice, or hit F2, or use the Edit <Property> context menu item.





    (Tip: When you're editing text in a multi-line text field, enter inserts a newline. To commit
    the text edits, hit Shift+Enter, or as with any other inline editing operation, click outside
    the inline editing component. Press Escape to cancel editing.)


  • Some new designtime behavior has been added for components. Check out the Tab Set for example.
    They now come pre-configured with an associated grid panel for each tab. The components placed in
    this grid panel will show up only when the associated tab is selected. Finally, easy tab panels
    without needing to create multiple pages!
    And in the designer you
    can click on the Tabs at designtime to automatically switch the rendered view so you can easily
    design each tab.

  • The property sheet shows values that are different from the defaults in bold! See screenshot; style and
    text properties have been changed, whereas the columns property, 20, is just an inherited default:





  • Page fragments work better now. I'll probably blog on that separately.


  • Component metadata can now specify the default text for event handlers. These are now more helpful, hopefully
    giving you some specific hints as to what you need to do. For example, if you add a validate event handler for
    a text field, the default method inserted in your page bean is this:





    Note also that the parameter names in the event handlers are much better (they used to be composed by simply
    taking the capital letters from the type name; e.g. a FacesContext parameter would be named fc.)
    As you can see, it's now named context, just like in the interface definition for Validator.

  • Creator now supports JSF refactoring. I'll wait a couple of days and see if Eric blogs
    on it (he did the work); if not I'll talk more about it.




Please take it for a spin and give us feedback.


Monday, September 12, 2005

Performance Tuning: Efficient CSS Handling

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


We have an update to Creator 2 Early Access which should go out any day now. One of the big things we fixed in the update is closing various memory leaks which caused Creator to slowly run out of juice. There are lots of other important improvements too - for example, Creator will finally run on JDK 5.0. But one big thing is still missing before we can ship it: Speed tuning.



I finally got done with my other 2.0 tasks last week, and have now started the performance tuning work in earnest.



It's really fun! I perform various tasks, look for hotspots, study the code and decide if (a) the code is doing something stupid, and (b) if the code is getting called too often. I've found several easy things to fix, so I've integrated a couple of things, sent e-mail to some other people when the bottlenecks are in their code. And in one case filed a NetBeans issue with my analysis.



The right way to performance tune is to measure the code looking for hotspots, rather than using your intuition about code you've written which is probably slow. So that's what I did - and I measured an enormous bottleneck in the CSS handling code.



This bottleneck has been there since 1.0. However, the bottleneck is proportional to the number of rules in your stylesheets as well as the number of elements in your document, so it doesn't show up for most pages created with Creator 1.0. However, in Creator 2, with our new nice themes, we have really large stylesheets which trigger the slowdown. And if your document has a lot of elements, which is pretty easy now with some of our new complex components, the slowdown is significant. As pointed out by the profiler.



This performance bug was really fun to analyze and fix, so I'll explain the gory details to you.



The problem is this: For each element in the document, we need to figure out which rules apply to that element.
This was done by iterating over the rules, checking the selectors in each rule to see if they apply to the current
element, and if so, "apply" the rule to the element.



The problem is that in Creator, the new Theme stylesheet contains nearly 800 rules! And of course, most of those rules
contain multiple selectors, each of which must be checked! Then there's the possibility of additional stylesheets.
There's the builtin user-agent stylesheet (which assigns HTML semantics for the element) as well as the project default
stylesheet, and any stylesheets you've added yourself. Finally, some of the selector checks involved iterating up
node hiearchies (for example, the :link pseudo tag means we need to see if the element is enclosed within an <a> tag.)
To cut to the chase: some of the node iteration and selector check code would get called over a million times for a page render!



Clearly, this needs to be optimized. There is a straightforward technique to handle this which apparently
is used by Mozilla's layout engine. I learned about it from reading David Hyatt's blog.
That's right boys and girls - spending time reading blogs CAN benefit your daytime job!
Give yourself a pat on the shoulder and resolve to return to my blog regularly :)



The technique is as follows: preprocess the stylesheet when it's first loaded, by setting up some
extra datastructures which will make the later (frequently called) "find-rules-for-element" perform faster.



Consider the following sample rules:


.Tab1Div table {border-collapse:collapse}
.WizMst {background:#C6D6DF}

The first rule can obviously only match Elements where the tagname is table, and the
second rule can obviously only match an element that has a class attribute which includes WizMst.



Therefore, when I preprocess the stylesheet I split up the set of rules into four categories.
First, for any rules where I can identify a "tag name requirement", I add the rule to a hashmap
indexed by the tag name. Then, for any rules that have a "class attribute requirement",
I place these in a hashmap indexed by the class attribute. Similarly for the element id condition.
Then I have a list of all the "remaining" rules, which don't have obvious tag/class/id requirements.
These will need to be checked the old way against all elements.
But amazingly, out of the 800 rules in the theme stylesheet, only 5 fit into this last category!



Now, whenever I need to compute matching styles for an element, I first look up its tagname,
check for applicable rules in the hashmap, then do a full selector check on each one of
these rules. Then I check the styleclasses in the class attribute with the class hashmap, and
so on. Finally, I do the old-style iteration of the "remaining" rules. This effectively partitions
the rules up into small buckets, one for each of the tag names, and one for each of the attribute names,
so for each element I get to do a lot less work.



This does however add one complication: cascade order. I cannot simply process all tag-related rules
followed by all class-attribute rules. Later rules in the stylesheet should "overwrite" earlier
rules (modulo various cascade rules etc.). So after matching rules from my hashmaps and
the remainder-list, I need to sort the rules into the right cascade order again.



The first thing to do was to verify that the optimization works - that pages still render correctly.
They appear to. Check. Then I measured the performance differences to make sure I actually get an
improvement and remove the bottleneck. To make it easy to check,
I put the new code path under a global flag I could turn on and off. Then I ran style attribution
with the optimization on, then with the optimization off, and compared the results.
And the effort definitely paid off.
For smallish pages, style attribution got a speedup of 12x. For large pages, I got a speedup of 8x!



Note that these speed improvements are not in EA Update - which has been out of our hands for a while now.


Rejected Ads

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.


Check out

these ads
eventually rejected by "top business publications". clientjava.com claims it was Wall Street Journal -
I have no inside information.













(There are more ads at the marketing site)


Sunday, September 11, 2005

Code Advice #3: No Tabs! Ever!

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



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:


(custom-set-variables
'(indent-tabs-mode nil)
'(tab-width 4))

Here's how you do the same thing in Vim.