Raible Designs

Subversion options for open source projects?

I've been using Subversion on quite a few projects lately and I have a hard time switching back to CVS. I currently use CVS for most open source projects, particularly AppFuse and Equinox - which I work on the most. A discussion started this morning on the AppFuse Mailing List about moving to Subversion. While I'd love to do this, I'd prefer to do it at java.net - so I don't have to completely abandon our hosted environment there. However, I don't think java.net is planning to offer Subversion anytime soon. If we move source control to somewhere else, we're pretty much just using it for the mailing list. Then again, the mailing list archive kinda sucks and you can't get it archived by mail-archive.com.

That being said, it might be nice to host everything ourselves. This might allow us to get something like Jive Forums setup. WebWork uses it and it has a pretty cool feature that the mailing list and forums are integrated (messages go to both). While the idea of self-hosting sounds appealing, it also sounds like it might be a lot of work. For hosted SVN options, it seems that there's JavaForge, Codehaus (which I believe is invite-only) and CVSDude. Any other options you know of?

On the downhill slope

Now that I've completed 4 out of the 5 days of training out here, I'm really starting to enjoy San Francisco. Of course, I miss my family and friends back home - but the students I'm training have been very hospitable and enjoyable to work with. They even invited me to join them at Zebulon last night for a "going away" party for one of the team members. I was happy to go, but got scared and left after the car bombs started flowin'. It was weird being at Zebulon and not seeing any Tangosol or Solarmetric monkeys (case in point).

Last night, I had the pleasure of dining with Crazy Bob and his woman at a very cool restaurant down by the bay. It was fun talking about how WebWork sucks and Google is a horrible place to work. Bob's work life seems to be pretty horrendous, but the new baby in a few weeks should turn things around. Good luck you two - I wish you the best.

The weather here is awesome. It seems to hover between 60 and 75, which is perfect IMO. Denver weather sounds awful right now. A good quote from Jason: "It's like I went to sleep Tuesday night and woke up in Phoenix."

One of the fun parts of class today was sharing IDEA tips. The good ones I learned were 1) use the pin icon on the panels to auto-close them when you're not using them (Command+1 to re-open the Project pane) and 2) install the Rearranger Plugin to control where your getters and setters are generated. The only tips I had to offer were Command+N, Command+Shift+N and Command+E - which most IDEA users already know. A lot of folks didn't know about Command+E (recent files), so that was likely my only contribution. Another good one I learned was Command+Shift+Alt+N (variable search). With all of the shortcuts I'm learning for IDEA, it's going to become harder and harder to keep using Eclipse. Got another useful shortcut? I'd love to hear about it!

Scaling with Rails

Whenever I talk to developers in the Java community about Rails, the first question out of their mouth is usually "But can it scale?" Today, David has written a nice post titled It's boring to scale with Ruby on Rails.

The one thing that I see time and time again is that Java developers don't seem to realize that some of the highest traffic sites on the net are using LAMP stacks similar to what Rails advocates. IMHO, I don't think "Rails can't scale" is a valid argument. In fact, I don't know if there's any argument or way to put down Rails anymore.

As a developer, my guess is the rates for programming in Ruby developer are less than for programming in Java (unless you're a Ruby Superstar of course), so that's one reason not to program in it. However, since Rails is one of those new bright and shiny things, chances are you might be able to get high rates for it. As far as Enterprise Adoption of Rails, unfortunately I think that's still pretty far on the horizon. I think the hardest part is convincing management that they'll be able to find developers to support it. Mind you, I didn't say good developers, just developers. Period. This is information I've gathered from talking to my Java developer friends.

Try convincing a Fortune 500 company to program in Rails vs. Struts and they'll probably choose Struts because there are thousands of Struts Developers. Is this a good decision on their part? I don't think so. I think it's more important to hire smart people that can learn a technology, rather than hiring those that know a technology. Of course, if someone knows a technology really well, there's probably no harm in hiring them.

I think Rails can become a real contender in the Enterprise if managers can be convinced that it'll be easy to maintain Rails application. Remember that most of software cost is maintenance. Because of this, the whole "it's super productive to develop with" doesn't matter so much - does it? Are Rails applications easy to maintain? My guess is yes, but how do you convince CTOs and CIOs? Another thing I think Rails needs for Enterprise Adoption is good tool support. Drag and Drop type of stuff. Why? Because management loves that stuff (because then they can develop apps) and it's a great sales tool. ASP.NET has been successful because of Visual Studio, not because of its ease-of-use and simple syntax.

Will I learn Rails and use it to develop applications? I certainly hope to, but it's hard enough convincing companies to use something other than Struts - so I don't know if I'll have much luck in selling Rails. The one cool thing about my new job at Virtuas is its an open source company, not just a Java open source company. This opens the doors for me to learn about Rails (and others) and compare them to Java Web Frameworks.

Update: Aaron Rustad has written an interesting article for DeveloperWorks that compares Rails to Struts+Hibernate: Ruby on Rails and J2EE: Is there room for both?

[JavaOne] Experiences with the 1.5 Language Features

This is the last session I plan on attending today, and it's titled "Experiences with the 1.5 Language Features: Tips and Techniques" by Tim Hanson and Jess Garms of BEA. Tonight looks to be a good time with the JBoss Party, Java Blogger Meetup (@ Thirsty Bear), the Pavilion Party. Times for the events are 5-9, 6-8 and 6:30-8. This conference is definitely packed, and I expect the parties to be the same. In other words, the best part of this shindig is yet to begin.

This talk is about how to make effective use of the new 1.5 Language Features in your applications.

For Each Loop: Initialization expression is evaluated once (unlike former). Major limitation of using the new for each loop is you don't have access to the index or the iterator.

Annotations: Built-in annotations - i.e. @SuppressWarnings("deprecation"). Possible values: all, deprecation, unchecked, fallthrough, path, serial, finally. This annotation is not supported in the latest version of Java 5, it is supported in Mustang and Eclipse 3.1. @Deprecated is another built-in annotations. If you use this tag, you should use the @deprecated javadoc tag as well. Last one is @Override, which is used to indicate that a method declaration is intended to override a method declaration in a superclass. If the superclass signature changes, this annotation will make sure you change it in child classes.

Annotations are especially useful for frameworks (i.e. EJBs, Web Services, etc.). Not a preprocessor, not a silver bullet.

Enums: Better than static final int. Type-safe. Utility classes: java.util.EnumMap and EnumSet. Public static final int-like behavior: Comparable, statically importable (even as an inner class).

Varargs: Special syntax for cleaning up code. Allows you to use "String... args" instead of a whole slew of methods that take multiple arguments. Use them sparingly - avoid code that casts.

Covariant Returns: Replaces three anti-patterns.

Using Generics: Example from Collections - static List Collections.singletonList(T o). There is a two-pass inferencing process to determine what T is. Other Generified classes: Class (public T newInstance()), Comparable (public int compareTo(T o)), Enum> (public Class getDeclaringClass()). You can also use wildcards with generics, which has a syntax of List instead of List. This allows you to specify subtypes, and not be tied to a strictly typed solution. Wildcards are great to use in APIs and to hide implementations from users.

I give up - this guy has been going on about Generics for far too long. Time to go hunt down some parties.

RE: AppFuse, 'tool' of experts

I'm please to say that I've been biled yet again. The first time wasn't so bad, and this time seems pretty mild too. There's no mention of asshat, chozgobbler or turdburglar in the whole post, which is somewhat disappointing. Nevertheless, it's what I've come to expect from a guy who sallies car bombs and dances like a sissy.

Regardless of the lack of bile in Hani's post, he does bring up some good points. Let's take a look at them individually:

• IzPack and MyJavaPack: the progress bar doesn't work, and the installer downloads everything rather than just including/installing it all.
  • To be honest, I didn't know it was possible to pack up everything and skip the internet download part. I'll definitely look into fixing this.
• You must have Tomcat installed to work with AppFuse.
  • This is true, and I've thought about changing it to be Resin friendly, or possible Orion friendly, but there simply hasn't been any demand. Of course, Orion isn't that attractive to many folks because it doesn't even support Servlet 2.4. Maybe you should crackin' on that Hani! Or maybe you just like living in the dark ages with your affections for EJB 2.1, Servlet 2.3 and WebWork 1.4.
• When creating a new project, you get prompted for the package name twice.
  • This is true, and something we should fix. The major reason we haven't is because I didn't want to distribute a 2MB BeanShell JAR that would support the 3 lines of code to fix the problem. I guess I should bite the bullet and add the bloat, or figure out a more elegant way to fix the problem. Issue #75.
• Project generation auto-detects MySQL when you don't have it installed.
  • MySQL is the default, but it's pretty easy (IMO) to use PostgreSQL or Oracle.
• I'm a web monkey.
  • True, but that's cool now with Ajax and all.
• Half the build targets don't work.
  • I think this is more like a handful don't work, but good effort. I agree we should remove the install-* targets when installing a web framework. Issue #76.
• Every object creates builder objects in hashCode and toString.
  • This is true, and I've seen no performance implications from it. In reality, these are a product of the commons-lang project, as well as Commonclipse. We should probably change these to use smarter methods like the ones IDEA generates. It'd be nice if Eclipse has hashCode() and equals() method generation like IDEA.
• The project's directory layout is bound to confuse a seasoned webapp veteran.
  • The directory structure is largely based off the example app in Java Development with Ant. Since AppFuse uses Ant, I figured it was a good idea to use a "best-practices" structure like Erik describes in his book. I've often thought about consolidating the 3-source tree, 3-test tree directory structure to one, but users are very attached to the current setup. Maybe for 2.0.
• XDoclet generates web.xml.
  • I agree that using 11 XML fragments to generate 1 XML file is a little ridiculous. You're right - developers should know how to write a web.xml and what goes where. Issue #77.

Thanks for the feedback Hani - sounds like I owe you a car bomb or two at JavaOne.

AppFuse cost $78K to develop

I somehow stumbled upon Koders.com this morning, where they have a cost-of-development based on LOC in the project's CVS repository. Apparently, AppFuse has cost around $78K to develop. Here are a few other project costs I discovered:

• Cocoon - $287,750
• MyFaces - not listed
• Struts - $490,040
• Spring - not listed (add to index form - I'd do it, but I'm not a developer on the project)
• Tapestry - $278,185
• WebWork - $109,025
• Ruby on Rails - $181,985

Are these costs accurate? Probably not, but it's still an interesting indicator.

[ANN] AppFuse 1.8.1 Released

This release is mostly a bug fix release with no new features. It also includes many upgrades to the core libraries (Hibernate, Spring, iBATIS, MyFaces). Thanks to all the sponsors who have contributed products and free hosting to the AppFuse project. You guys rock!

• Download
• Release Notes
• Learn more about AppFuse

To see how AppFuse works, please see the following demos:

• Demo of Features in Flash
• Struts + Spring + Hibernate
• Spring + iBATIS
• WebWork + Spring + Hibernate
• JSF + Spring + Hibernate
• Tapestry + Spring + Hibernate

Comments and issues can be sent to the mailing list or posted to the AppFuse Issue Tracker.

RE: Why wait for Intel?

Norman Richards asks Why wait for Intel?. He argues that you might as well upgrade now if you want a faster Mac. I've had a very personal experience with a new Mac recently and I don't think it's worth the upgrade. My "normal" PowerBook is a 17" 1.33 GHz with 1 GB RAM. The new one I bought is a 17" with 1.67 GHz and 1.5 GB RAM. When I first got the new PowerBook, I did some brief tests against my current benchmarks. To my surprise, the new PowerBook is not faster than the old one. In fact, in some tests it was slower.

Yes, this does seem impossible. I will re-run these tests before I get rid of this new machine, but right now I don't see any reason to upgrade.

AppFuse 2.0: JDK 5, Annotations and JSP 2.0

For the most part, I haven't used JDK 5 on any of my recent projects. You can compile and run AppFuse with JDK 5, but it doesn't use any JDK 5 features. After doing a code review at Bouvet last week and seeing how much cleaner their code is with Generics, Varargs and the Enhanced for Loop, I think it's time to dig in. I don't know how soon we'll start, but I think it's time to start creating a branch for AppFuse 2.0 - which will use these features. For AppFuse 2.0, I'd like to go whole hog, bleeding-edge and use all the stuff that's out there to make developer's lives easier. This includes JSP 2.0, Annotations (especially for Hibernate and Spring, as well as Tapestry) and all the JDK 5 features that seem useful.

Since most developers won't be able to deploy on a JDK 5-compliant server for quite some time, we'll continue to maintain the 1.x branch as JDK 1.4-compliant. I expect to release AppFuse 1.8.1 later this week (with mostly bug fixes + latest releases of Hibernate/Spring) and 1.9 in the next month or so. From there, we'll likely do 1.9.x releases with bug fixes and do all the major upgrades (i.e. Tapestry 4.0.x) in the new branch. Working with new features in JDK 5 should be a lot of fun.

I'm hopeful that we can get rid of XDoclet and we may even give Maven 2 a run for its money. Last week in Norway, I found that most Java developers were using Maven on their projects and I also discovered that many of the core Maven 2 developers are getting paid to work on it full time. There were even claims that Maven 2 is going to be twice as fast as Ant - which definitely intrigues me.

Later: I just realized the hardest part of this migration is going to be replacing AppGen. It currenly uses XDoclet templates for all the class templates - and we'll need a new solution based on annotations. Oh well, it's kind of ugly anyway, but it'll likely be difficult to figure out a new solution. Hopefully we can create some sort of tool that involves easy-to-customize templates and a GUI to drive it all.

[OSCON] AppFuse Tutorial and Spring MVC vs. WebWork

Now that the OSCON 2005 site is up, I might as well advertise the two things I'm doing: an AppFuse Tutorial and a session titled WebWork vs. Spring MVC Smackdown with Matthew Porter. I wasn't planning on doing the AppFuse Tutorial, but I was asked to do it - so what the heck. The title has "Struts" in it, but I'm willing to do whichever one (JSF, Struts, Spring MVC, Tapestry or WebWork) the audience chooses. If we're good, maybe we'll have an Eclipse Plugin done by this conference to simplify the new project and code generation process.