Raible Designs

GWT and REST

I've posted two message to the GWT Google Group in the last couple of days. However, new member messages are moderated and neither has shown up yet. I'm reposting my questions here in hopes of getting some answers.

{"response":"Hello World!"}

Thanks in advance for any advice.

Should we change AppFuse to be Struts 2-specific?

Dusty recently posted an interesting idea to the AppFuse developers mailing list:

After thinking/coding/reading for a while I think the more interesting task is: Retool AppFuse to be one or more Struts2 plugins based on various higher level app patterns. (AppFuse Facebook, AppFuse Employee DB, AppFuse Blog, AppFuse Basic LDAP, AppFuse Basic Crowd).

This all comes from the fact, that I have been wanting to refactor the AppFuse web layer for Struts. One of the interesting aspects of AppFuse is that it works pretty much the same across all its web frameworks. It does so with some lowest common denominator abstractions that can be ported and look and work the same across frameworks. I have picked my tool(s): Struts 2 and Ruby On Rails when I want to pretend I am young again. I know Spring MVC, JSF, etc. but I have no desire to build significant apps on those platforms. It's not because they suck and Struts2 rules, it is because I know Struts 2 the best, I am most efficient there and it provides everything I need to build great webapps (Let's not devolve to a framework debate). So, I would rather have a more Struts 2-specific web stack, that really leverages conventions born and raised there. The nice thing about the Struts 2 web stack is that it is complemented nicely by AppFuse's data/service layer, since unlike Grails or Rails, Struts 2 has no data or service layer. [Read More »]

Seems like a good idea to me. What do you think?

Someday I'd like to come up with a "compatibility test" that allows others to improve upon the ideas in AppFuse and develop their stacks independently. A suite of Selenium tests that require extensionless URLs might be a good start.

I Got Lucky

Earlier this evening, I decided to upgrade my work laptop to Safari 3.1. Shortly after restarting, I was greeted with the Gray Screen of Death. To fix, I rebooted. Same result. 3rd time is a charm, right? Nope.

/me this is really going to suck, I'm going to have to give up my laptop for several days to get it fixed. Furthermore, this is my only machine authorized to VPN into LinkedIn's network. Looks like I'm going on vacation for the rest of the week.

Rather than trying to rescue the OS or upgrade it to Leopard, I decided to watch TV for an hour instead. When I came back, I disconnected the machine from its monitor and tried rebooting on battery power. Voila - it worked!

Now I'm in the process of using my old friend SuperDuper!.

I got lucky... when was the last time you backed up?

David Sachdev on Web Framework Proliferation

David Sachdev left the following comment in my post about the Java Web Framework Smackdown at TSSJS in Vegas:

Wow - that's quite a mouthful David. Well written!

P.S. The Early Bird Deadline for TSSJS is today.

Don Brown Makes Maven 2 Not Suck

Don Brown spent some time over the weekend Making Maven 2 not suck:

While there are a few (very important, I might add) things Maven 2 gets right, there are a bunch that just suck, yet I use it at my day job (Atlassian) and in Open Source work, so in true Open Source tradition, rather than continue bitching, I'm doing something about it. I'm embarking on a quest to fix all the bits of Maven 2 that really annoy me and waste my time. I hope to get most, if not all, of the changes back into the codebase, but my personal deliverable is a build of Maven 2 that doesn't suck.

On his blog, Don lists a number of improvements he hopes to make. This weekend, he implemented the first three, which concentrates on speeding up remote repository access and downloading of artifacts.

First up, tasks #1-3. I implemented these changes in a bored Sunday afternoon and saw a example build (Struts 2 core) go from 3 minutes, 26 seconds to 2 minutes even, so a little over 40% performance improvement.

Interested, I decided to try Don's improvements on AppFuse. Since it fetches seemingly hundreds of artifacts from Maven's central repository, it seemed like a good testing ground. With a clean repository (rm -r ~/.m2/repository), a 8 MB/sec internet connection and "mvn -Dmaven.test.skip", I achieved the following results with the stock version of Maven 2.0.8:

[INFO] Total time: 7 minutes 40 seconds
[INFO] Finished at: Mon Jan 28 09:02:11 MST 2008
[INFO] Final Memory: 55M/508M

With Don's improved uber-jar, I received the following results:

[INFO] Total time: 5 minutes 17 seconds
[INFO] Finished at: Mon Jan 28 09:10:56 MST 2008
[INFO] Final Memory: 56M/508M

460 vs. 317 seconds = a 31.1% improvement -- Nice work Don!

When he implements #4 (Should support artifacts checked into the SCM in the lib/ directory so no external repository needed), I'll be a much happier Maven consumer. I've always wanted the ability to bundle all of AppFuse's dependencies for offline use like we did in 1.9.x.

Don - I'll buy you numerous beverages in Vegas if you add the ability to run a Maven command to put all a project's dependencies in its lib directory too.

The future is now -- Java development in 2008

In The future is now -- Java development in 2008, Andy Glover writes:

The year 2007 was full of exciting plot twists, punctuated by growing excitement about dynamic languages, the open source evolution of the JVM, and the rise of Google as a strategic contributor to the Java community. The question is, what does all that tell us about the year ahead?
...
And so, despite some rumors to the contrary, I would argue that Java isn't going anywhere but up in 2008. Rather than peer into a crystal ball and try to divine the future, let's reflect on the major events and trends of the past year. Taken together, they reveal all we need to know about what's ahead in 2008.

He concludes the article with:

An African proverb states that Tomorrow belongs to the people who prepare for it today. Thus, the future of Java (at least for the next year) has already been brewing for some time. The events of 2008 will largely be shaped by the JVM itself, as languages like JRuby and Groovy grow in popularity and eventually gain enterprise-wide adoption. The promise of using Java to develop consumer mobile applications also seems more accessible than it has for some time, given Google's foray with Android and Sun's with JavaFX Mobile. Most of us will also be concerned with leveraging the emerging multicore systems and looking to Java 7's java.util.concurrent packages for answers. Lastly, open source Java and the business model surrounding it will continue to grow.

I agree that learning about JRuby and Groovy is a good way to be prepared for the future. Reading Ola Bini's Practical JRuby on Rails Web 2.0 Projects and/or Stuart Halloway and Justin Gehtland's Rails for Java Developers seem like good ways to get started with JRuby. With Groovy, Groovy in Action has received a lot of good reviews. For Grails, it's a bit more difficult as it's evolved so quickly w/o any updated books. I like the look of Scott Davis's Groovy Recipes, but that won't be released until March.

One thing to note: just because you learn these languages and frameworks doesn't necessarily mean you'll find a new job doing them. In my experience, there's still way more Java jobs than there is Rails or Grails jobs. I sat on a Consulting Panel last night at Denver's Ruby on Rails user group (DeRailed) and this was confirmed (at least for Ruby) by the recruiters on the panel. There were three recruiters and combined they've only seen 2 Rails positions in the last 6 months.

So if you're looking for a new job, I doubt you're going to find one that allows you to leverage your new-found JRuby/Groovy skills out of the gate. However, I do believe you can leverage these tools in your existing jobs and hopefully make your development life more efficient.

Java Web Framework Smackdown at TSSJS in Vegas

This year's TSSJS is starting to look like an excellent conference. I'm particularly excited to be moderating the following Expert Panel.

Java Web Framework Smackdown: Struts 2, Spring MVC, Grails, Seam/JSF and Wicket
The leading advocates of today's popular Web frameworks will duel under the Vegas Lights. Come and learn when to use your favorite framework and to see if it can live up to its hype.

We're talking about productivity, scalability and maintainability of Java-based Web applications. The emerging trend is that simplicity is better and productivity matters. Furthermore, if maintainability is the most costly part of any application -- how do these frameworks perform?

Attend if you're a Java Web developer, or if you simply like good entertainment. A working knowledge of the popular Java Web framework options will make this session more fun. If you haven't worked with any framework, come and learn who has the best spokesman.

I plan on bringing the boxing bell from OSCON 2005 to make this session one of the best in the show. I'll be coming up with a list of questions for these experts in the next couple of months. In the meantime, if you have any suggestions, please let me know.

With a venue like The Venetian, why wouldn't you go?

Does Struts 2 suck?

As far as I can tell, Struts 2 sucks. To be fair, so does Stripes. Why? Because there's no developer feedback for invalid properties or OGNL Expressions. What does this mean? It means if you fat-finger a property name, nothing happens. The OGNL exception is swallowed and you never know you did anything wrong. Furthermore, no one seems to care. The XWork folks will help you build, but not solve the problem. This seems like a major deal-breaker to me, However, I also believe it can be fixed - so maybe there's hope.

To demonstrate the problem, I did an experiment. I used the "user details" page in AppFuse Light to fat-finger a property name for the following frameworks: Struts 1, WebWork, Struts 2, JSF, Spring MVC, Stripes, Tapestry and Wicket. First, I tried changing the "lastName" property to "LastName" to see if the framework's property evaluation was case-sensitive. I found that with WebWork/Struts 2, Stripes and Tapestry, the property is not case-sensitive. I prefer case-sensitivity, but maybe that's because I prefer Unix over Windows.

The 2nd thing I tried was changing "lastName" to "pastName" to see if I'd get an error. An error occurred for all the frameworks mentioned, except for WebWork/Struts 2 and Stripes. This makes me believe these frameworks suck. The both use OGNL, so they could blame it on that, but Tapestry uses OGNL and it presents an error message. After this small experiment, my conclusion is the following frameworks have the best developer feedback:

• Struts 1
• JSF
• Spring MVC
• Tapestry
• Wicket*

* Wicket seems like it needs some work as all it presents is "Internal Error" and makes you dig through your log files to find the problem.

Without good developer feedback, how can you have good productivity?

Dear Struts 2 and Stripes Developers,

What do you think about improving your error messages for invalid properties and expressions? Is this a feature you think you could add? We'd love it if you did.

Sincerely,

Your Users

Click here for some screenshots of how a fat-fingered property looks in various frameworks:

JSF

Struts 1

WebWork

Struts 2

Spring MVC

Tapestry

Stripes

Wicket

Update: Stripes doesn't suck and Wicket has excellent error reporting. See my comment below for more details.

Update 2: I've created a patch to (hopefully) solve this issue in XWork. If you have any feedback on ways to improve this patch, I'd love to hear about it.

Choosing a JVM Web Framework: Stories Wanted

My last post on choosing a web framework got quite a few comments. Some seemed to like the application categorization technique as a means to narrow the choices. However, others seemed to disagree. So if application categorization is not a good methodology for narrowing the choices, what is?

I think one of the best ways to figure out a good methodology is to find out what people have done to choose their web framework. I'm looking for stories from developers who have evaluated 2-3+ frameworks for a project. I'd like to come up with 3-5 stories as part of my talk to highlight how some teams have chosen their web framework. What were your important criteria? What made you choose the one you did? Was it a tight race between a few of them? Did industry buzz or application categorization play a part in your decision?

Please send any stories you'd like to share to [email protected]. Of course, you can also post your story in the comments - but an e-mail gives it a bit more validity. If you'd like to share your company name, that'd be great, but it's by no means required. I haven't decided if I'm going to prevent all cases as anonymous companies or not. If you do send a story, I'll make sure and ask your permission before I share any of your personal/company information. Thanks!

Do we even need web frameworks?

On the Struts mailing list, Ted Husted writes:

IMHO, if we had today's JavaScript/CSS/HTML environment available to us in 1998, then JSP, ASP, JSF, PHP, and all the rest of it, would not exist. We did all these things to make up for the shortcomings of the client-side environment, and, since then, the key shortcomings have been addressed.

I believe Ted has a good point. However, today's Ajax development toolkits don't help those applications that require Section 508 compliance. Of course, if your toolkit embraces 508 compliance, I'd love to hear about it.