‘Java Web Frameworks Survey’ was my first blog posted which was reposted at dzone. Sadly there never was a follow up of it. Although I planned one with:
jZeno, SpringMVC, Seam, Vaadin (at that time: IT-Mill Toolkit), MyFaces, Stripes, Struts, ItsNat, IWebMvc
Now, today just a short, subjective mini-follow-up, maybe someone is interested after all those months … over the months I have additionally investigated JSF, Rails, Vaadin and one more:
- No comments to JSF
- Rails is great! Especially the db migrations and other goodies. Partials are a crap: I prefer component based UI frameworks. If you don’t like ruby take a look at grails with autobase.
- Additionally I highly recommend everyone to take a look at vaadin (‘server-side GWT’) if you need a stateful webapplication. Loading time was a problem for me. Other client-side performance problems can be solved if you use CssLayout, I think.
But for jetwick.com I chose wicket! There were/are 10 reasons:
The most important thing is: if you use ‘mvn jetty:run’ and NetBeans in combination then the development cycle feels like Rails: modify html, css or even Java code. Save and hit F5 in the browser. Nothing more.
The only problem is the database migration (wicket solves only the UI problems). For that I would use liquibase. Or simply run db4o, a nosql solution ‘or’ solr.
As I started with Rails development I discovered the very neat feature of database migrations. For me this was the main advantage of using Rails compared to a pure Java solution.
In our Rails application this works without any problems: you can change the database schema as well as migrating the data itself via ruby.
I needed a similar feature at that time in Java and discovered Liquibase, which was relative easy to use and stable. But it has (in my opinion) one major drawback that you have to use xml and for your data migration you even have to use pure SQL. Then you’ll run fast into some issues (e.g. this). But okay, there is also one advantage over the Rails-mechanism: you don’t need to specify the rollback statement (if it is not pure SQL) – liquibase knows from the migration command which revert command it should use.
If you use Hibernate one could stick with SchemaUpdate, but several things don’t work properly with that approach.
Another idea would be to export objects from version 1 and import them into version 2 directly within your application logic e.g. with Groovy … or should I give DMT I try?
Now I thought that Grails could solve this issue better for Java, but to my knowledge (‘Automatic Database Migration’) there is not such a mature migration concept within Grails like in Rails. The Liquibase plugin (grails install-plugin liquibase) or the outdated (?) dbmigrate plugin (grails install-plugin dbmigrate) can solve this as well as autobase, which is based on liquibase too. Does somebody has experiences with that? Here is a mini comparison.
Today I discovered migrate4j, which seems to be the best tool I found so far for pure Java. Another option would be to use JRuby with Rails or simply rails, but this would be a bit of an architecture overkill for the most people, I fear.
Other choices might be:
Do you know other (better?) solutions? How do you do db migrations?