Raible Designs

MacBook Pro: Kicking ass and taking names

I received my MacBook Pro this morning, and I've spent the day setting it up, doing some development and running some performance comparisons. The setup was easy: I just booted my PowerBook into Firewire mode and copied over all the files I needed. Everything works for the most part. I did have some issues with IDEA and Eclipse, but got both working after doing a few try and try-again shenanigans. Eclipse was crashing when I'd browse to set my workspace; typing it in manually fixed the problem. IDEA hung the first time I opened it; killing it and restarting fixed the problem.

As far as performance, this thing fricken' rocks! Safari launches in under a second and you're browsing before the dock icons hits the top of its first bounce. Firefox is a different story (likely b/c it hasn't been compiled for x86) - it takes 10 seconds to launch. The good news is once it's up, there doesn't seem to be any performance issues. Safari is amazing though - the speed does wonders for GMail and it actually feels like a desktop application.

When I mentioned yesterday that I was going to compare the MacBook to my desktop, Rob Williams said it wasn't a fair comparison. I agree - but I really wanted this machine to be the best machine I could possibly buy. With my (very unofficial) performance tests, it appears like it is. It's faster than my dual-core AMD 64 desktop machine that has 3 GB of RAM. Now, I have had the desktop for a couple months, so it's possible I'm suffering from OS Rot, but still - it's impressive it keeps up. Here are the numbers from my Performance Comparisons page:

For the tests below, I used Java version "1.5.0_06" and had the following variables set: JAVA_OPTS=Xms256M -Xmx384M, $ANT_OPTS=-Xmx256m. I used the CVS version of AppFuse (1.9.1-dev).

A couple of interesting things to note:

• When I first got my desktop, it's numbers were 00:14 for "ant clean package-web" and 01:29 for "ant setup test-all". The MacBook Pro? 00:12 and 01:28. The Windows box had 1 GB of RAM when I ran those tests, but no matter how I tweaked the memory settings once I put 3 GB of RAM in, I've never gotten better numbers.
• My PowerBook has been dog slow for several months now. When looking up the OS X version on it - I noticed it lists the memory as 512 MB. WTF?! I've had 1 GB in it every since I first bought it! What happened? Did half my RAM go bad or did someone steal half of it during a repair? Oh well, at least I now know the reason it was so damn slow.

Conclusion: The MacBook Pro is one of the best machines you can buy (laptop or desktop) for Java development. As for the battery life? I'm still doing the "calibration", so I'm not quite sure. Nor do I care - I plan on having this thing hooked up to my 20" cinema display that Virtuas was kind enough to get for me. The display combined with a mouse, keyboard and iCurve is a very nice setup.

Update: I pulled out the memory from my PowerBook and put it back in. Upon reboot, it resulted in the correct (1 GB) memory setting. The numbers above appear to be accurate regardless. I ran some tests again and times were actually slower (maybe because I'm on battery power).

New AppFuse Tutorials: Cobertura, EasyMock, Laszlo and Acegi ACLs

Peter Schneider-Manzell has been busy lately. He's written a bunch of new AppFuse tutorials:

• How to integrate the code coverage tool Cobertura
• How to integrate EasyMock for mock testing
• How to use AppFuse + XFire with OpenLaszlo
• How to integrate Acegi Security's ACLs in AppFuse

Great stuff Peter - thanks for taking the time to put these together!

In related news, we've started an AppFuse Frappr group - if you're an AppFuse user, make sure and sign up.

RE: Usability problems in JSF

Adam Winer:

JSF is not perfect, nor the greatest thing since sliced bread. There, I said it!

What bugs me most (and remember, I'm still a big fan) is that JSF was supposed to be really easy-to-use. But the reality isn't quite so sweet.

Adam goes on to explain a few of his pet peeves with JSF. He also asks "What are your biggest JSF usability concerns?" If you're using JSF and experiencing usability issues, now's the time to speak up.

[ANN] Equinox 1.6 Released

For a good story of how Equinox helps, see Wayland Chan's Equinox to the rescue blog post.

This release's major new features are Tapestry 4.0 and WebWork 2.2.1 upgrades. In addition, I changed to use Maven's Standard Directory Layout. It makes IDE and using Maven plugins much easier, so it's a natural progression.

This release does not contain Maven support for running the integration tests with Cargo. This is because Cargo still seems a lot more complicated with Maven than with Ant. Hopefully I'll be able to figure out an easy way to get test-all functionality with Maven and Cargo in the next release.

All of the frameworks used in Equinox, as well as its build/test system is explained in Spring Live. A summary of the changes are below (detailed release notes can be found in JIRA):

• Added custom exception page for Tapestry, as well as tapestry-flash.
• Changed birthday date input to use WebWork's DatePicker component.
• Added support for pre-compiling JSPs when building with Maven (on by default).
• Added createDatabaseIfNotExist=true to jdbc.properties.mysql to auto-create the database when using MySQL.
• Changed classes that extend *SpringContextTests to use AUTOWIRE_BY_NAME so more than one instance of an interface is supported.
• Dependent packages upgraded:
  • Cargo 0.7
  • DisplayTag 1.1
  • Hibernate 3.1.2
  • Scriptaculous 1.5.2
  • Tapestry 4.0
  • WebTest build 1168
  • WebWork 2.2.1

Download. For more information about installing the various options, see the README.txt file.

Demos:

• Spring
• JSF
• Struts
• Tapestry
• WebWork

Known Issues: The Tapestry-Flash JAR was built with JDK 1.5 - so you'll need JDK 5 to run the Tapestry version. Howard Lewis Ship said he'd fix this tonight or tomorrow. Also, if you're on Unix, you'll need to run "ant fixcrlf" before you install anything. Finally, downloading dependencies might not work the first time. Running the "ant" or "mvn" command multiple times usually solves the problem.

See the roadmap for what's coming in the next release.

Upgrading Equinox to WebWork 2.2.1

In addition to upgrading Tapestry last week, I also upgraded Equinox to WebWork 2.2.1 (from 2.1.5). The commit log can be found on Fisheye. The changes I had to make were pretty minor:

• WebWork 2.2.1 easily integrates with Spring - you just need to add webwork.objectFactory=spring to your webwork.properties file. This isn't a whole lot different from 2.1.5, except that you can get rid of the SpringObjectFactoryListener from web.xml.
• ServletDispatcher has been deprecated in favor of FilterDispatcher - which should map to <url-pattern>/*</url-pattern>. Using a filter for the controller is an obvious improvement, and it's pretty slick how WebWork can now add CSS and JavaScript to your pages on-the-fly.
• WebWork now has a <ww:datepicker> component which makes it possible to do easily do popup calendars like you can with Tapestry and JSF. Unfortunately, it seems you still can't set a global date format using a ResourceBundle.
• AltSyntax is on my default, which means you'll need to change "'literal string'" to "literal string" and "variable" to "%{variable}". This is much easier to read and a welcome change. It's unfortunate that ${} can't be used, but that's JSP's fault, not WebWork's.
• FreeMarker is required, even if you're just using JSP. This is because the JSP tags' HTML is generated using FreeMarker templates (I think).
• The taglib URI has changed from "webwork" to "/webwork". I wonder why they don't use the full URL like most tag libraries?
• Exception mappings have been added so you can easily map a particular exception to a specific view. This allowed me to remove a custom interceptor I'd previously wrote.
• The DTD for xwork.xml has changed from xwork-1.0.dtd to xwork-1.1.1.dtd.
• The only issues I found were that the validator interceptor makes it difficult to override "excludeMethods" and client-side validation renders duplicate messages when you click submit multiple times.
• When I deployed the latest Equinox demo to Contegix, we had some issues with the stylesheet the datepicker stuffs in the <head>. Basically, mod_caucho 3.0.14 wasn't returning the proper content-type for the stylesheet (even though it was for the rest). Upgrading to Resin 3.0.17 with mod_proxy fixed the problem.

Hopefully this helps you upgrade to WebWork 2.2.1.

Upgrading Equinox to Tapestry 4.0

Last week, I upgraded Equinox from Tapestry 3.0.3 to Tapestry 4.0. The commit log can be found on Fisheye. Here are some details that might help you upgrade.

• Tapestry 4.0 doesn't support Spring out of the box. This was surprising to me b/c one of the advertised features of Tapestry 4.0 (or Hivemind actually) was native Spring support. Luckily, Howard released the tapestry-spring project which solves this problem. Dropping the JAR in your classpath is enough to get built-in integration. It'd be nice to see this library become part of tapestry (possibly in the tapestry-contrib.jar).
• Tapestry-Flash makes it easy to do success messages when redirecting. Furthermore, it's nice to see how to do redirecting w/o throwing a PageRedirectException.
• PageRenderListener has changed to PageBeginRenderListener.
• When using <inject> for a property, I had to remove any public abstract void setXXX methods as I got an error otherwise. Luckily, the error message told me exactly what to do.
• Injecting dependencies during testing is fairly simple using the Creator class. Equinox's UserFormTest.java has a good example of this. I did have to create a MockRequestCycle and a MockPageService, but both were pretty easy to write.
• Friendly URLs are much easier to implement in Tapestry 4.0. However, Tapestry still doesn't allow you to use the same extension for everything - so I ended up with .html, .direct, .sdirect and .svc extensions. I'd prefer a single extension, but oh well.
• You'll need to change all your *.page files to use the new 4.0 DTD. I don't think this is absolutely necessary, but it does simplify things.
• As part of the 4.0 DTD, <property-specification> has changed to <property> and the "type" attribute is not allowed (b/c it's inferred using reflection I assume). In addition, <binding name="foo" expression="bar"> has changed to <binding name="foo" value="bar"> and <context-asset> has changed to <asset>. Also, <message-binding> has been removed in favor of <binding>. The userForm.page diff shows detailed changes.
• @Conditional has changed to @If.
• The issue where Tapestry sets the focus on the first required field still occurs. An easy workaround is to make the first field required.
• The @DatePicker component has changed from using the "format" attribute to using the "translator" attribute for formatting dates. The popup calendar also seems to have changed - I had to add new CSS rule to colorize the header properly.

Hopefully this simplifies your Tapestry 4.0 upgrade.

What do we need to do to make WebWork/Action 2 the best framework for *everything*?

From Ted Husted on the Struts mailing list:

Seriously, hype aside, engineer to engineer, if we can use the new standalone Tiles with WebWork, and use Ajax to store the state of UI controls, what else do we need to do to make WebWork/Action 2 the best framework for *everything*?

My reply:

The tag documentation (and documentation in general) for WebWork is difficult to navigate. Struts' documentation has generally made it easier to find stuff.

I think the hardest part of WebWork/Action 2 is providing the path for migration. If Struts 1.x applications can run in Struts Action 2.x, and users can create new Actions following WW's APIs - that will be truly awesome.

Another that would be cool is smart defaults. For example, having Actions that end with "Action" be available at the "everythingbeforeAction" URL. Spring has something similar coming in 2.0 - and it's mainly just done by extending a certain class.

http://jroller.com/page/raible?anchor=an_example_of_smart_defaults

So if I have UserAction, it's automatically available at /users, /user/edit, /user/save, etc. Default CRUD in a sense. No xwork.xml required by default. But users can override. Default everything w/o requiring annotations, but allow overriding. Or maybe there's different default schemas - a CRUD one, store front, etc.

Ajax stuff that I think WW already has: in-page updates, sortable/pageable lists with something like the displaytag - but with Ajax. There's a lot of these components already available for this stuff, so it might just be a matter of documenting how to integrate them.

Promoting Maven 2 for building might be an easy way of promoting inclusion of 3rd party libraries. Add 3 lines of XML, use this code in your JSP/template, boom - you're good to go. Those that don't like Maven can use the Ant tasks and pom.xml.

Archetypes could be pretty big too - create starter applications that users can use. Even better, provide a means to upgrade the archetypes. Of course, that might be a Maven thing - and editing pom.xml to change versions really isn't that hard.

Above all else - to become the best MVC framework for Java - documentation and easy migration are essential.

Just my $0.02 of course.

What's your opinion?

[CSS Fundraiser] Brrrrrrrr

At 14°F, it was definitely a cold ride to work this morning. It took about a mile and a half before my face when numb. Then I stopped to snap some pictures, which made my fingers go numb. However, the sun was out and it is a beautiful morning in Denver.

Why am I doing this? To raise money for a CSS Design contest.

Tuesday Morning Update: Last night's ride home was pretty warm - 35°F. This morning's ride was fairly nice too (31°F). Here's proof from last night.

RIFE: Which template syntax looks best to you?

Geert Bevin of the RIFE project asks:

Many times I have wondered why people are so reluctant to investigate RIFE. After having asked around a bit, the most recurring critique was that our template syntax is too arcane at the initial glance. Somehow the look of the tags syntax pushes people away without them ever checking out any of the features of our framework.

Ironically, none of the users consider the syntax to be a problem. Many even love how it stands out while still being totally invisible to a browser or an XHTML editor.

Still, initial adoption seems to be all about appearances, so I think this issue needs to be addressed. That's why I'm asking you, the non-rife users which alternate syntax looks best to you. [Read More »]

I'm one of those folks that thinks RIFE's current template syntax is difficult to understand. I was scared away from RIFE for this reason alone. It's good to see them asking the community for a better formula.

There's one thing I've learned from leading an open source project: your users aren't always right. Just because they like the way things are done, it doesn't make it the best way to do it. Often, developers merely like something because they've learned it, and would rather not learn something new. Look at all the folks that prefer Struts, yet have never tried another web framework.

Personally, I like Velocity's variable style, which is now used by JSP 2.0. Most new Java web developers are going to learn JSP. If you can make the transition from JSP to your template syntax easier, you'll likely get more users.

Redirect-after-Post in Tapestry 4.0

I just noticed a good Tapestry nugget on Howard's blog. With Tapestry 3.0, one of the things I complained about was the need to throw an exception when redirecting. With 4.0, it looks like you can plug-in this flash component and get exactly the flash message functionality I try to put in all the web frameworks that AppFuse supports. Now I just need to figure out how to do @InjectObject("engine-service:page") without using annotations.

I'm hoping to upgrade AppFuse to WebWork 2.2 and Tapestry 4.0 in the next few days.