Vaadin 7 alpha3 contains GWT as a part of the framework itself.
Server and Client Side Development
Sometimes it is easier to do something on the server side, sometimes on the client side. As GWT is always there and available in Vaadin 7 its easy to do something on the client side when it makes sense.
Ease of use
You no longer need to ensure you have the correct version of GWT in your project, it is guaranteed as long as Vaadin is there. You will automatically have the latest bug fixes from GWT in all Vaadin maintenance releases. Vaadin 7.0.0.alpha3 is compatible with GWT 2.5.0.RC1.
Moves the framework to Java 6
As GWT is now an integral part of Vaadin and GWT depends on Java 6 we have moved the whole framework to use Java 6. End of life for Java 5 was reached already a long time ago so this should be seen as progress.
This is an alpha release so we expect there to be bugs and still expect changes will be made to the API and functionality before the final 7.0.0 release. All your comments on the new features are welcome. Please post all Vaadin 7 related comments in the Vaadin 7 category of the forum.
Unfortunately some of us backwater companies are still stuck on JDK 1.5 for the foreseeable future. I would love to upgrade to 1.7 but its not currently in the cards for us at the moment.
Is there a compelling reason why you want to drop Java 5 support? This would be a showstopper for us migrating to Vaadin 7.
WebSphere 6.1 which includes IBM JDK 1.5 support doesn’t officially end until Sept 2012 and you can extend that even further:
The problem with staying on Java 5 comes from the inclusion of GWT, which depends on Java 6. Already in Vaadin 7 versions before alpha 3 you were required to compile the widget set using Java 6 even though the server side code was Java 5 compatible. As we included GWT in alpha3 we ended up with a project where part of the project could be compiled with Java 5 and part with Java 6, so the whole project had to be compiled using Java 6.
We tried really hard to come up with a solution which would enable us to keep Java 5 compatibility in Vaadin 7 but in the end we felt the only option was to move to Java 6. Any mixture of Java 5 and 6 such as server side being Java 5 compatible but development tools requiring Java 6 would just be confusing to a majority of our users.
For those of you still stuck on Java 5 platforms we will continue to support Vaadin 6 at least until June 2014.
So, there are really no new features that Vaadin 7 server side is using from Java 6 at this point?
I didn’t look at the source code of V7 yet so I don’t know how much separation between GWT and Vaadin core is there, but perhaps, we would be able to compile on our own and run it on Java 5 then. Based on Artur’s post, I understand that only GWT has new features that requires 1.6 on compile time.
I’ve seen many Vaadin add-ons that are doing the same and we were successfully able to re-compile them back to Java 5 without any change.
Perhaps, this could buy us little bit more time, until Vaadin server side starts using new features from Java 6. It’s dirty, but feasible I guess?
If your reason you want to migrate to JDK 1.6 is that you don’t want to complicate the build process is not a legitimate reason IMO especially considering that you already publicly stated that Vaadin 7 would support JDK 1.5. You cannot even use any/most of the JDK 1.6 features in GWT compilation AFAIK so the only value add is a simpler build script.
I don’t know what build system you use but Ant, Maven, and Gradle all support setting different JDKs for different stages of the build process. We’re doing it and its not that hard. Annoying but not difficult technically, e.g.
If you had a compelling reason on the server side that couldn’t be satisfied on JDK 1.5 can we at least discuss it? Maybe there are workarounds? Like I said WebSphere 6.1 doesn’t officially end support of JDK 1.5 until next month. Seems like this move onto JDK 1.6 is still premature.
