I expected yet another Java reference article, but Ethan wrote one of the best explanations of phantom vs. weak references I've read.

I wanted to send a trackback today, but Blogger doesn't support them (with good reason, details at the end of this post). Fortunately, a trackback is nothing more than an HTTP post with your blog entry's URL to the other blog's trackback URL. A simple curl command does the trick:

  $ curl -d url=[my entry's URL] [trackback URL]

If successful, the command outputs something like this:

  <?xml version="1.0" encoding="utf-8"?>
  <response>
  <error>0</error>
  </response>

You can also specify the title, excerpt, and blog_name using additional -d parameters.

I guess you can imagine trackbacks are pretty prone to spamming. For example, unlike comments, I don't see any way you can insert a captcha.

Blogger on the other hand supports backlinks. Instead of allowing/requiring users to manually post reverse links, Blogger asks Google Blog Search for links back to an entry. This way you don't have to build trackback functionality into every blog tool, and you can use Blog Search as a giant spam filter.

Until everyone else catches on, we have curl.

The kid just learned to crawl, so I thought I'd take Google Video's new in-browser uploader for a spin. As you can see below, Google Video now enables you to embed videos in your own web page. I can't believe how fast it transcoded and posted my video. I think it beat my quad G5. I uploaded a 320x180 H.264 video encoded by iMovie/QuickTime. I'm a little concerned about the privacy implications (i.e. anyone can see a movie of my bambino), but I think this clip is pretty innocuous. Update: I tweaked the height of the embedded player. The default height was appropriate for 4:3 video while this particular video has a 16:9 (widescreen) aspect ratio. For future reference, 400x252 was the magic width and height. This means the panel at the bottom is 27 pixels high, which in turn means for a given width w, height h = w / ratio + 27.

I subscribe to the java.blogs feed so I can discover new blogs. On the down side, I end up seeing items from feeds I'm already subscribed to twice which makes it harder to pick out new blogs. Do you know of a way to filter out duplicates in NetNewsWire or even better in Bloglines?

Floyd Marinescu, author of EJB Design Patterns and former TSS editor, just launched InfoQ, what I can best describe as a much needed refresh of TSS. InfoQ doesn't limit itself to Java, but you can filter the topics as you see fit. The TSS's broken RSS feeds and non-scalable thread UI has been a thorn in my side for some time, so I'm looking forward to the new stomping ground. Good luck, Floyd!

The conference was a buzz about the Google Web Toolkit (GWT) announcement. GWT converts your Java code into Javascript and runs it all in the browser; this contrasts with some other Java-based AJAX frameworks such as Echo2 which run your Java code on the server and constantly invoke XMLHttpRequests.

The GWT enables you to call back to the server via a simple RPC mechanism. Dust off your DTO and Session Facade patterns, folks. You can even step through your Java code with a debugger while running in the browser!

For the majority of intents and purposes, GWT invalidates JSF. Both frameworks seek to isolate web developers from HTTP, but due to the fact that Google built GWT from the ground up with AJAX in mind, GWT offers a cleaner abstraction, better type safety, and a lower learning curve. When it comes to AJAX and JSF, you're at the mercy of which functionality your JSF components offer. You must write anything beyond that (including your business logic) in Javascript. With GWT, you can stick to 100% Java.

Now, on one end of the spectrum we have request/response, action-based frameworks such as Struts Action 2 and Rails which work great for traditional web applications, and on the other we have GWT which enables you to build rich, component-based AJAX applications. By comparison, JSF seems to awkwardly fall somewhere in the middle. You might argue that JSF is meant for any view technology, not just AJAX, but does anyone really use it for anything else? I don't see myself writing JSF code once and then sharing it between my web site, mobile phone XHTML web site and Swing application. I'm perfectly content to push common functionality down into the service layer.

Disclaimer: If you're a regular reader, you probably already know I work for Google (but, much to my chagrin, not on GWT). I do work on Struts Action 2.

During the Struts Action 2 meetup, we discussed the design of an annotation-based validation framework, which in turn led to questions about overriding annotations with XML. Ideally you would reuse the annotation classes directly, but I can't find a way to instantiate them! That's not very unit test friendly. I suppose a framework could modify the class bytecode at load time based on the XML, but that would only allow one set of overrides per Class instance. I guess it's time to submit a JSR...

All this talk of HTTP session clustering from Tangosol, Terracotta, etc., got me to thinking about a common problem in web applications which use in-memory HttpSession implementations: developers tend to forget that multiple threads can concurrently access objects on the session. From my experience, web developers think even less about session concurrency than security (yes, it's possible).

It's terribly easy to focus on the happy path during development and ignore the edge cases (especially considering how difficult it is to test them). In the past, we web developers only had to worry about users who double clicked links and buttons, but now technologies like AJAX and asynchronous session replication have exacerbated the problem by increasing the likelihood of two threads stepping on each other and resulting in race conditions or deadlocks.

Case in point: I once had a server grind to a halt due to a strange deadlock. The stack dump showed that one thread was waiting for a lock held by another thread which seemed to be mysteriously stuck in Object.hashCode():

  daemon runnable
    at java.lang.Object.hashCode(Native Method)
    at java.util.HashMap$Entry.hashCode(Unknown Source)
    at java.util.AbstractMap.hashCode(Unknown Source)
    ...

How on Earth could a thread block in Object.hashCode()? The call to a non-synchronized HashMap in the stack trace unlocked the mystery. Someone nested a HashMap instance deeply within the session. While one request iterated over the map, another request came in and mutated the map which created a cycle in the HashMap's underlying data structure, and the first thread went into an infinite loop. Object.hashCode() didn't really block, but the loop was so tight, it sure looked that way.

How do you avoid this pitfall? There is no silver bullet. You could synchronize. Synchronizing at the appropriate level is tricky. Too fine grained, you don't really solve the problem. Too coarse, and a long running request can block subsequent requests. Last I checked, Struts Action 1 performed no synchronization on session scoped beans, and it wasn't a problem you could solve at the application level (i.e. how would you get Struts to acquire your lock before mapping request parameters to your session-scoped bean?). I'm not sure how JSF implementations and Spring WebFlow address this problem, but I'd love to hear. My current project manages concurrency quite successfully using an in-house wizard framework.

You could also serialize the session at the beginning and end of each request (each request would have its own copy of the session). I think Rails takes this approach by virute of the fact that each request executes in its own process. I'm not sure how you would handle concurrent requests though; would the second request overwrite the session changes from the first? Does Rails write the problem off as too rare to worry about? I suppose you could mitigate this problem to some degree by storing the session in a hidden field on the client.

Nowadays I think I favor keeping all your state in the database and using one of the aforementioned clustered caching frameworks to scale. Thoughts?

Does JSF's complexity make your head spin? You're in luck. The WebWork and Struts teams have combined efforts to build the next generation web action framework: Struts Action 2.0 (a separate but equal sister sub project to Struts Shale). Pat Lightbody, Jason Carreira, and Don Brown announced the merger in a Wednesday talk to quite a crowd (98% of which uses Struts Action 1), and the Struts team met in person later that day to hammer out the details of the API and project plan. At times like this, meeting face to face trumps collaborating asynchronously via email, and JavaOne provided the perfect opportunity. Based on the meeting and considering how Struts Action 2.0 builds on WebWork 2.2, I think you can look forward to an initial release in late summer or early fall.

I met with Rod Johnson this morning, and he demonstrated Spring's new first class support for custom scopes (no more AOP/proxy hacks!). That alone justifies taking Spring for another spin, but he also showed off their new support for injecting constructor parameters by name, i.e. no more worrying about parameter indices or mixing up parameters of the same type. You can capture the parameter names by compiling in debug mode or using a special tool at compile time. Let's see you do that with plain Java. Last but not least, keep an eye out for Spring's new plain Java bean definitions. The Java definitions play nicely with Spring XML which means you can mix and match Java and XML using the best option for the task at hand. For example you might use plain Java to declare that a given class has a dependency on a data source and XML to configure the data source itself. Thanks, Rod.

I wish IntelliJ provided some basic syntax highlighting, completion, and formatting for code examples in Javadocs. What a pain. I'll bet more developers would write them if it did.