Rapid application development techniques, favoring rapid prototyping over intensive planning, have become popular in the last few years. Although the "old-school" Java Web frameworks (such as Struts and JSF) are well suited for enterprise projects, their development cycle is often too slow and complicated for prototyping. Due to their nature, dynamic languages such as Ruby, Python, and Groovy are natural for fast prototyping and scaffolding. But is there a way to benefit the Java ecosystem without compromising simplicity and productivity? This presentation tries to answer this question by comparing, head-to-head, three leading Java RAD tools—SeamForge, Play, and Roo—by writing a full-blown Web application in each of them, comparing the pros and cons along the way.
7. Why Slow?
Integration == pain!
Java Web Frwks suck!
Java EE application
– Map model to relational (JPA)
– Write Session EJBs for DAOs and Services
– Write JSF UI (E.g.JSP)
– Write bunch of xmls (persistence, web,
jsf, server specific)
– Deploy to JEE server
17. Obvious and trivial jboss SEAM
FORGE Facts
Developed by JBOSS (surprise!)
Heavily based on JBOSS SEAM (surprise!)
Heavily based on Maven
Uses standard java ee 6 features
Evolved from seam-gen project in August 2010
latest version 1.0.0-beta1
25. Obvious and trivial Spring ROO Facts
Developed by springsource (surprise!)
Heavily based on the Spring framework (surprise!)
revealed @ SpringOne Europe on 27 April 2009
latest version 1.1.5
36. More unusual stuff
Not using servlet API
Build and deployment handled by Python scripts
Static controllers
“Share nothing” architecture
JSP-LIKE templating engine (based on Groovy)
Admin area otf generation
Graphical Test runner
37. Modules
Infrastructure
Scala ElasticSearch and Lucene
Eclipse Compiler JUNIT and selenium
GAE OAuth
JBoss Netty
*Yap, we lied
43. Feature Seam Forge Spring Roo Play!
Scaffolding One-Time Continuous One-time
(as module)
OTF compile No No Yes
Persistence JPA JPA JPA
Morphia
User interface JSF Spring-MVC HOME-Grown
GWT (JSP-like)
Full Text Search No Solr ElasticSearch
Lucene
REST support No Spring-rest Rest-easy
Deployment JBOss AS Servlet container Embedded netty
Glassfish AS GAE Gae
Cloud Foundry Servlet container
44. Feature Seam Forge Spring Roo Play!
Backed up JBOss Springsource zenexity
Maturity Low High high
Documentation Low Medium Medium
Books NO “Roo in action” “Introducing the
Early access Play Framework”
License LGPL Apache 2 Apache 2
Mailing List 6 messages in 132 messages in ~550 messages in
last month last month last month*
*Inc. announcements on usage, etc.
Notes de l'éditeur
Presentation of the speakers – background, twitter, etc.
Explain agenda:Background and overview on what RAD isFor each framework:Overview Interesting features Extension capabilitiesDemoPros and consSummary and comparisonQ&A
Fourth-generation-languages tried to move away from the machine towards business problems. They failed being too restrictive.
Overview on what RAD is:Opposite to slow J2EE, will explain why slow in next slidesPopularized by RoRCommon features:Scaffolding (will be explained in following slides)Modularity (will be explained in the following slides)CLI (shell)
Why traditional J2EE apps are slow to delevop? Mainly 2 reasons:Integration of a lot of stuff (see next slides)Java web frameworks are suboptimal (see next slides)
What is scaffolding? Generation of UI from entities
modules are used to add functionality to project.They ease integration by generating configurations.E.g. all the ORM configurations are generated
Lot’s of modules are like scaffolding. They generate functionality based on existing entitiesE.g. solr add-on, which generate the configuration, and lots of indexing and searching logic based on the entity
Simple to use, lot’s of reasonabledefaults are assumed and hidden.
Full power at your hand comes with tedious configuration and setup.Simple example of COC is Hibernate 2 hbm.xml, which named each and every persistent property vs. Hibernate annotations (or JPA), in which all the properties are persistent by default unless otherwise stated.
Metawidget – UI generation framework. Supports various backends, inc. JPA, Hibernate, Seam, etc. and various frontends, inc. Android, GWT, Spring MVC, Swing, SWT and JSF.In theory, selecting Metawidget as the scaffolding tool should give the ability to provide all those UIs. In practice, only JSF is supported
Promisesabstractions for Persistence as a general concept (JDBC, JPA, Hibernate, NoSQL, and JDO). For now only JPA is implemented
Seam Persistence supports for no-sql, currently implemented only JPAMetawidget supports GWT, Spring MVC, Struts, Swing and SWT, currently implemented only JSF
Developing plugin is easy, project created automatically, use standard Java EE to perform operations, use Forge API to do stuff to project. Full support for CLI.Not using OSGi, so plugins run in same classloader, which creates classpath hell. Current workaround is maven shade plugin with relocation.
Pros – Scaffolding with JSF – easy to create JSF UIHeavily based on Java EE 6 and Seam framework.Cons – Early days, only limited amount of features implemented (e.g. Metawidget only for JSF), bugs and failures.Generated classes are editable by user, regeneration destroys the changes. That limits the usage to project bootstrap stage only.Classpath hell ugly workaround for plugins creation
Standard AspectJ technique for separation of conserns. Used inRoo to separate auto-generated content from user-editable contentAlso fights some Java boilerplate – here it hides the getters and setters from JavaBean
Here is adds the JPA stuff to entity, both technical details of entity itself (like ID and Version) and the active record nature (persist, merge, find)
Variosaddons include full text search, REST support with JSON, GWT UI, deployment to cloud factory and other fancy stuffJPA providers – Hibernate, EclipseLink, OpenJPA, DataNecleus
Creation of add-on is simple and convenient:Use add-on creator add-onInject the services for manipulating the project, generate code and ITDs, access application contextAdd-on is regular Spring bean, everything works.Roo is running inside OSGi container (Apache Felix), the add-ons are bundles. That solves the classpath issues better way than Seam Forge does. The OSGi complexity is hidden from add-on developer.
Pros – Separation of user-authored code from autogenerated code. That allows Roo to manage the application even after the user started to change the code in IDE.Tight integration with Spring Framework, allowing easy usage of all the features.Solr add-onGood usage of OSGi to solve classpath issues with add-ons. The complexity of OSGi is well hidden.Cons – Most of the code is in ITDs. They are almost Java, but not quite. Looks like magic.No support for NoSQL persistence. We’d expect it to present due to excellent SpringData project. Work in progress.We can’t say Active Record as it is implemented in Roo is a con, but absence of DAO option is. Debates in progress.
Play does not support scaffolding by default. So, is it still Rapid Application Development Tool?
Yes. It uses other technique to achieve rapid development – the on-the-fly compile. It saves recompile-redeploy-restart cycle and speeds up the development.
Play also differs from other tools in:Not using Servlet API, it uses Netty (NIO) directlyNot using Maven, but bunch of Python scriptsAll the methods in controllers are static Uses “Share nothing” architecture to be totally statelessUses its own templating engine, the improved JSP, written in Groovy
Various add-ons include mongoDB, Rest-Easy for REST over JSON, Scaffolding (not as default, but in add-on) , Scala support, deployment to GAE, full text search etc.
A module is just another Play application.
Special command for bootstrapping module developmentModules are automatically loaded from the /modules directory of the applicationModules are less restricted than application , e.g. module doesn’t have application.conf file. Everything in module is optional.Public module repo exists, your module can be there after a short review of the core team.The classpath hell is not tackled. Ivy is used for dependency management, so ivy.xml should sort out all the jar conflicts.
Pros – OTF compile gives great productivity boostFansy modules, like full text search, MongoDB and even ScalaNIO server based on NettyCons – Scaffolding as module with questionable qualityClasspath hell in module development