CRUD: To Roo or not to Roo?
I have been using Groovy on Rails for CRUD applications. I am starting a new project where we are not allowed to use Grails anymore (we have a list of allowed jars and grails is not there).
I am considering using Spring ROO or JBoss Seam. How do they compare? What are their major strengths and weaknesses?
Answer
Note that Spring Roo and JBoss Seam aren't directly comparable, as JBoss Seam in itself doesn't provide the CRUD application generation mentioned in the question. JBoss Seam however comes with the seam-gen tool, which provides this functionality. It would therefore probably be better to see JBoss Seam as comparable to the Spring framework and compare the seam-gen tool with Spring Roo. I know this is also not a complete comparison, but that is outside of this topice I guess. What needs to be stated is that in the below answer, when I refer to JBoss Seam, I actually am referring to JBoss Seam in combination with the seam-gen tool.
Both Spring Roo and JBoss Seam (with seam-gen) make the creation of CRUD applications really easy, as by the way other Java full stack/scaffolding solutions like the Play Framework and RIFE also do. If you compare the two (Spring ROO and JBoss Seam with seam-gen) in how fast you have a new basic CRUD application up and running, based on an existing database or by adding entities and defining the fields and relationships, I guess there isn't that much of a difference. In my experience you can do it in Spring Roo just a (slightly) bit quicker, but with both you have the application up in less than an hour (in case of an existing database) or in less than (half) a day (in case you manually have to add all entities and relationships).
Before continuing, the reader should note that this whole comparison was made based on my humble experience with both solutions, and therefore is based on Spring Roo version 1.1.0 and JBoss Seam 1.2 and 2.x. The reader should also note that there is currently already an excellent Seam 3 version (actually CDI (Weld) with Seam module addons) wich is based on the Java EE 6 spec, but that this new version of JBoss Seam no longer has the seam-gen application and therefore hasn't yet the functionality to create a complete CRUD application with just a couple of commands like Spring Roo and JBoss Seam 2.x and lower have. There are currently people from JBoss working on something similar though, named JBoss Forge, which looks very promising but which, as of today, has not yet had any actual release and is therefore not yet an option I guess.
Both Spring ROO and JBoss Seam (with seam-gen) create a nice basic CRUD application, though the default UI design of the Spring Roo generated application looks a bit better in my humble opinion, but as you probably want to restyle it anyway, this isn't much of an argument for either one. The created web applications also differ slightly in offered functionality, but for as far as the basic CRUD functionality goes and other basic features like authentication and internationalisation, they are on a par with eachother.
I think the main differences and therefore the reasons to decide for which you want to go, aren't in the time it takes to generate a basic CRUD application nor in the scaffolded basic CRUD applications, but in far more important things like architecture/design decisions, usage, support, documentation, flexibility, maintainability, extension points etc. For as far as I'm concerned, both Spring Roo and JBoss Seam are great options to base your web application on (as a matter of fact my team has created production application with both), but before you make a decision, you have to look at these important differences and decide what works best for you. Of course the best way to decide, would be to do a proof-of-concept for yourself with both options, but if you don't have the time and/or resources, here is what I can come up with (from the top of my head) that are differences between the two and that might help you decide either way:
- The underlying build system used in Spring Roo is Maven, where JBoss Seam uses Ant. Seam can, for as far as I know, also be used with maven, but seam-gen by default uses Apache Ant. Note that JBoss Forge (replacement of seam-gen and actually more like Spring Roo) is using Maven though.
- Spring Roo is based on the Spring framework, while JBoss Seam is based on the whole Java EE 5 stack (Seam 3 will be using the Java EE 6 stack). Note that JBoss Seam and the seam-gen tool will by default use EJB 3.0, but this is optional and you can also opt for a none-EJB solution with JBoss Seam and the seam-gen tool.
- JBoss Seam (with seam-gen) uses basic OO inheritance to add basic functionality to generated classes by extending JBoss Seam specific classes. This does add a runtime dependency to the JBoss Seam (and seam-gen) specific classes. Spring Roo chooses a totally different approach, by generating both plain Java source files (without extending Spring related classes) and annotating these classes. Alongside the generated Java source files, Spring Roo also generates one to several so called inter-type declaration (ITD) files, which are AspectJ specific files containing generated source code and annotations. These ITD files will be completely transparently weaved into the generated class files upon compile time and therefore don't impose a runtime dependency.
- Seam generated files can (and will) be updated by you, but if you need to regenerate the files with seam-gen, it will overwrite your manual changes, this because you will do the changes in the by Seam-gen generated files. Because of Spring Roo's approach with ITD's, you make changes in the Java source file that override the generated sourcecode in the ITD files. This makes it possible for Spring Roo to regenerate the ITD's as it leaves the manual changes, which are in the Java source file, then unchanged.
- The usage of seam-gen is more inclined to a one-time generation/usage to initially set up the project and get a running start, whereas Spring Roo is used throughout the lifetime of the project.
- Spring Roo can be removed from a project, leaving a completely working project that has no dependencies on Spring Roo anymore and can of course still be build and extended any way you want. The seam-gen utility doesn't offer such a functionality, though in the case of seam-gen you are of course never depending on seam-gen itself, but rather on a specific JBoss Seam package (called framework).
- JBoss Seam (with seam-gen) is mainly targetted for using JSF as the web framework, while Spring Roo is focused on Spring MVC and/or GWT as its web framework. JBoss Seam itself has also good support for Wickete, but not with the seam-gen tool. Spring Roo also has a Flex addon and more addons for other web frameworks are created in the community, but they're all still not as good as the ones for Spring MVC and GWT.
- Documentation is for both JBoss Seam and Spring great, but for Spring Roo and the seam-gen tool they lack the more advanced documentation. Spring Roo by the way also offers great helpful hints in the command line shell.
- IDE support for the JBoss Seam approach is better than for the Spring Roo approach. Both the solutions have an Eclipse based specific IDE and plugins (SpringSource Tool Suite for Spring Roo and JBoss IDE for JBoss Seam) and all other big IDE's (Netbeans en IntelliJ) have great support for the base frameworks, but the none-Eclipse IDE's (not completely sure for IntelliJ IDE though) don't have good support for the by Spring Roo generated ITD's. This is not a problem in the build, but does provide problems with intellisense and code completion related functionality in these IDE's.
Though there are of course far more differences between these two great products and I haven't even touched important things like testability, learning curve and the future of these projects, I hope the above bullets might already help people who are considering these two solutions, to make an at least bit more founded decision. I like to stress again that the best way to make a decision is still to create a proof-of-concept with both these approaches and see which best suites you.
Main points, in my humble opinion, that might give you to an easy and quick decision are the choices between the Spring stack or the Java EE stack, IDE support, Web Framework and 'adulthood' of the solution. So if you are very familiar with the Spring stack (which I guess you are, seeing that you're coming from Grails), go for Spring Roo as else you might loose quite some time in getting familiar with the Java EE stack, including JSF (of course this does depend on the size of your project, but assuming it is not a very large project, the impact of learning new techniques might be too large for a single project). If you cannot or don't want to use Eclipse and are really passionate about this, I guess JBoss Seam might be a better solution. If you want to use JSF or Wicket, go for JBoss Seam, while if you want to use Spring MVC or GWT, use Spring Roo (for other web frameworks it probably doesn't really matter which you choose, though Spring roo might then be a better solution). And if 'adulthood' is your main point of decision, I guess you'd better use JBoss Seam. All in all deciding between the two can be really hard, but at least know that both solutions are really great and will help you a lot, either way.
By the way, make sure to keep an eye on the JBoss Forge project as the current seam-gen solution will be replaced in the near future with this promising project.