In this SpringSource tutorial, Christian Dupuis goes through the steps required to start using Roo and GWT with the SpringSource Tool Suite.
http://blog.springsource.com/2010/06/02/using-springsource-tool-suite-2-3-3-m1-with-roo-and-gwt/
Clearly, Spring is trying to make itself the standard programming model when it comes to working with GWT.
I saw Rod Johnson speak at the Philly JUG last week (thanks Penn State/Great Valley for hosting) and while he clearly had a little VMWare acquisition elevator pitch on the brain, he had some interesting insights (as you would expect a Rod Johnson to have). The key message I got was Java as a language, even with its critical mass and maturity, needs to make the jump to the cloud if it is going to survive. That means leveraging existing skillsets but making applications (new and legacy) portable to the cloud. That is where Spring comes in and where VMWare sees value. Think of Spring as an anti-gravity device for your "fat server" Weblogic and Websphere apps.
Another take-away was that in a code-off, Java geeks would still be evaluating frameworks and libraries, while Rails and .Net geeks would have deployed systems. Point is Java has too much choice that kills productivity. In answer, Roo narrows down to a few community digestible Java best practices and offers lower effort to get your logic on GAE/Spring/GWT apps on the cloud. I still don't see why VMWare is promoting real estate on App Engine. Could be their market is really the private cloud and this is a bait and switch. A nice one once you start looking at security and RDBMS options.
As for GWT, from what I see the Spring integration is server side and doesn't replace gin/guice. Even GWT 2.1 doesn't deliver Flex quality widgets but rather sets the foundation for highly testable MVP and paging/filtering/sorting-enabled flyweight controls. Those Googlers are really smart adding low level robustness instead of jumping to the eye candy. Things you would do if you were in it for the long haul.
I don't think this will be the tipping point for GWT although Spring's blessing makes it somehow cool and approachable like it will solve problems the way Spring did. A better tipping point was Apple's Flex "thoughts." So when serverside shops become device aware and hit the javascript maintainability wall, they will see the value of large scale, unit testable, strongly typed code a la GWT. The widgets will get better and draw the eye candy weenies.
Spring adds credibilty more to GAE than to GWT. The GAE services seem too "cloudy" compared to EC2 or everyone's corporate stack. Leading off with Python just made GAE seem like it was UNESCO funded. Now we are back to apples to apples.
I really liked the idea of GWT very much when I first read about it's principles and design. But really using it was quite cumbersome for me. Then for comparison I tried the Vaadin framework, and I was really enjoying it. I think in the JEE-context Vaadin really does AJAX the way how it should be done - more server-centric, just using GWT as rendering-engine and it frees the developer from the very cumbersome c/s-communication and cross-compiling.
I really liked the idea of GWT very much when I first read about it's principles and design. But really using it was quite cumbersome for me. Then for comparison I tried the Vaadin framework, and I was really enjoying it. I think in the JEE-context Vaadin really does AJAX the way how it should be done - more server-centric, just using GWT as rendering-engine and it frees the developer from the very cumbersome c/s-communication and cross-compiling.
I agree that GWT is a cumbersome technology. I was initially attracted to GWT because it came from Google- just followed the hype, I must admit. I didn't find it charming at all. And then I went back a year later to look after some intensive hype surrounding it. Again, I didn't find it very appealing.
Let's face it. GWT doesn't do any more wonders than generating Javascript code from Java code outputting some darn ugly web UIs. Itegration with other technologies such as Maven and Spring looked very poorly done at that time, IMHO.
My conclusion was that GWT is meant for Java developers who are scared of Javascript. I think for this group of developers there are appealing webframeworks out there since GWT that does far better than GWT and yet shields us from Javascript. For me it's a no no to GWT. I won't choose GWT just because Google is behind it.
My .02 cent.
Jan
What has Maven go to do with selecting a particular UI toolkit or any other library ? Maven is a glorified build tool it has no runtime impact with GWT or any other Java library. This seems a very poorly chosen reason to not think GWT is suitable.
Your second comment about GWT integration with Spring again seems strange. Why would anyone need Spring something that lives in a JVM to be deeply meshed with GWT which ends producing javascript. What part of JdbcTemplate, IOC etc would i need in my ui code ? On the other hand, Spring works well in its field of strength on the server to help with all your services that are consumed by your GWT RPCs.
What has Maven go to do with selecting a particular UI toolkit or any other library ? Maven is a glorified build tool it has no runtime impact with GWT or any other Java library. This seems a very poorly chosen reason to not think GWT is suitable.
What a naive question- any sound thinking Java developer would know straight away from that sentence that I meant building GWT projects with Maven.
Your second comment about GWT integration with Spring again seems strange. Why would anyone need Spring something that lives in a JVM to be deeply meshed with GWT which ends producing javascript.
I am refering to the Integration layer between GWT and Spring.
Jan
Why even mention Maven at all ?
GWT is about writing client side applications and as such its pretty much server agnostic hence its very lightweight presence with regards to server side stuff. Just because GWT does not have official Spring integration is no big deal, libs exist to handle that missing gap.
I was scared of pure javascript before, but after learning it a little bit and then working with jQuery extensively, I think javascript/jQuery is great. However using 2 different javascript libraries together may cause problems that you don't know how to fix (e.g. using jQuery with Google Maps API).
Nobody chooses a technology X because he/she is scared of technology Y. It is simply the question of whether the chosen technology helps in
I'd say GWT scores high on all these fronts. The same cannot be said about JavaScript - not even by a JavaScript Ninja
jQuery is great - no doubt at all. It has its place. However if the systems to be integrated with are Java EE systems, GWT has a great advantage.
Let's face it. GWT doesn't do any more wonders than generating Javascript code from Java code outputting some darn ugly web UIs.
Really.. Is that your conclusion. Wow !! I bet you did some basic "Hello World" kind of GWT and compared its JavaScript to a handwritten JavaScript. You need to think of GWT as a platform and not just a API. Think of the GWT platform supporting multitude of component sets - the likes of Ext-GWT, Smart GWT etc. Do you honestly think the kind of Rich UI you get in GWT ecosystem is just about generating JavaScript.. All I can say is Wow
My conclusion was that GWT is meant for Java developers who are scared of Javascript.
Yeah right.. IDEs are meant for pussies too. Oh by the way, who wants Java and the wonders of generating bytecode or even native 0s and 1s. I can do just fine with assembly language. Are you scared of assembly language?
And now speaking seriously - the amount of productivity gains when developing large and complex web front ends with GWT (+ Ext-GWT) talking to Java EE backend on several huge projects is mind boggling. I just kept wondering why i didnt get on to GWT earlier.
But hey to each - his own reasons
Peace,
Srikanth Shenoy
My conclusion was that GWT is meant for Java developers who are scared of Javascript. I think for this group of developers there are appealing webframeworks out there since GWT that does far better than GWT and yet shields us from Javascript. For me it's a no no to GWT. I won't choose GWT just because Google is behind it.
There is another third way, plain HTML design and JavaScript-like programming in Java (Java W3C DOM APIs and W3C DOM Events) and executed in server (and friendly with JavaScript frameworks).
I think this thread is proving Rod Johnson's (my previous message) point that there is just too much choice in Java-land. Spring is putting wood behind its arrow with best practices in Roo (convention over convolution).
I really don't understand why Java programmers are just plain spooked by the client side. Are they really that complacent on the server side. I guess today's Java programmer is no longer the innovator of 10 years ago.
To those safety first types, think of GWT as a Javascript condom. It's browser free love with no STDs (Sisyphian Testing and Debugging). Seems like your coding the server side but you're not. If you don't like GWT in the end, at least you will have some reusable services you can use with your next sparkley RIA.
To qualify GWT, I think you probably need to be a TDD group doing medium to large scale mission critical development to get the real benefit from GWT. You can only appreciate the non-functional features as the pressure points, complexity, and size of your apps or modules increases. Modularization is huge. JUnit testing is huge. Being able to code the server and client in the same language means your skills are less watered down. UiBinder is huge for porting as-is HTML over to GWT so you can show what your ported app looks like quickly instead of slower Composite building. MVP is a trade-off between fast testability and more abstraction (i.e. more code).
I think this thread is proving Rod Johnson's (my previous message) point that there is just too much choice in Java-land. Spring is putting wood behind its arrow with best practices in Roo (convention over convolution).
I really don't understand why Java programmers are just plain spooked by the client side. Are they really that complacent on the server side. I guess today's Java programmer is no longer the innovator of 10 years ago.
To those safety first types, think of GWT as a Javascript condom. It's browser free love with no STDs (Sisyphian Testing and Debugging). Seems like your coding the server side but you're not. If you don't like GWT in the end, at least you will have some reusable services you can use with your next sparkley RIA.
To qualify GWT, I think you probably need to be a TDD group doing medium to large scale mission critical development to get the real benefit from GWT. You can only appreciate the non-functional features as the pressure points, complexity, and size of your apps or modules increases. Modularization is huge. JUnit testing is huge. Being able to code the server and client in the same language means your skills are less watered down. UiBinder is huge for porting as-is HTML over to GWT so you can show what your ported app looks like quickly instead of slower Composite building. MVP is a trade-off between fast testability and more abstraction (i.e. more code).
I find that funny. Whenever I see someone say "java has too many choices", what they mean is "choose us and we'll think for you." Having choices doesn't scare me and I'm glad there's choices. Sure it means I have to put in the time to study and understand the choices, but that's a good thing. It lets me see different approaches and find what I like best.
by having lots of choices, it lets me see what parts are common and different. The common parts tend to show those parts work well. The different parts help me expand my thinking and step outside of myself. At the end of the day, I'm responsible for the code I write and the design choices I make, not some vendor. Honestly I don't buy the "too many choices" argument from anyone.
I think this thread is proving Rod Johnson's (my previous message) point that there is just too much choice in Java-land. Spring is putting wood behind its arrow with best practices in Roo (convention over convolution).
[...]
I find that funny. Whenever I see someone say "java has too many choices", what they mean is "choose us and we'll think for you."
My sentiments exactly. If Rod Johnson was really concerned that there are two many choices (in general), then he would stop creating new ones. What he's really saying is that there are too many choices aside from his products. Or in other words, he's lamenting that he has too much competition. He may be having trouble accpeting that Spring and SpringSource is not destined to be THE future of Java that was considered a given by a lot of people just a few years ago.
Sorry to put words in Rod's mouth about choice but I think he was more focused on productivity. For a guy who made is nickel on not-EJB it does seem confusing. But I think he was singing the praises of Rails/Grails saying they were on to something. If the latest rev of JEE came out today as a choice stack instead of the 10 years of pain experienced, we probably wouldn't be using Spring and be more aligned.
Definitely a trade-off on creativity and free will to cut down on choice but funny thing is I pretty much use the same stack outside of Roo so I can't complain.
Oh, and my app is up and running while you were still chosing between ant and maven ;)
I think this thread is proving Rod Johnson's (my previous message) point that there is just too much choice in Java-land. Spring is putting wood behind its arrow with best practices in Roo (convention over convolution).
I find that funny. Whenever I see someone say "java has too many choices", what they mean is "choose us and we'll think for you."
My sentiments exactly. If Rod Johnson was really concerned that there are two many choices (in general), then he would stop creating new ones. What he's really saying is that there are too many choices aside from his products. Or in other words, he's lamenting that he has too much competition. He may be having trouble accpeting that Spring and SpringSource is not destined to be THE future of Java that was considered a given by a lot of people just a few years ago.
Don't blame Rod and Spring because of one guy's interpretation of what was said. If someone is berating and saying that java developers are afraid of JS, then I would question whether or not the someone is *injecting* his opinion.
I think this thread is proving Rod Johnson's (my previous message) point that there is just too much choice in Java-land. Spring is putting wood behind its arrow with best practices in Roo (convention over convolution).
What Rod and co. needs to recall is that Spring came into the picture 6-7 years back because it was just a "choice". The Java community saw the value of that "choice" and rallied behind it. It's all about survival of the fittest (whatever be the determining criteria applied by the community/industry) Now that they have won the choice war, why do they want to shut the lid on innovation for the future?
I think this thread is proving Rod Johnson's (my previous message) point that there is just too much choice in Java-land. Spring is putting wood behind its arrow with best practices in Roo (convention over convolution).
What Rod and co. needs to recall is that Spring came into the picture 6-7 years back because it was just a "choice". The Java community saw the value of that "choice" and rallied behind it. It's all about survival of the fittest (whatever be the determining criteria applied by the community/industry) Now that they have won the choice war, why do they want to shut the lid on innovation for the future?
I'm guessing they sold the company, so now they have to deliver the customers and revenue. Best way to do that is claim "tooo many choices!" That's the typical bait and switch. Spring is no different than any other business.
Having only read the overview of Vaadin and your comments it seems more like JSF, than in the sprit of GWT and its goals of writing rich client side javascript apps that hit a server for other "server" stuff.
Vaadin is not GWT, GWT is an implementation detail or did i miss something...
I agree w/ other people that GWT is for someone who's afraid of JavaScript. I really don't belive in philosophy of "Java for everything". What's next? CSS in Java? Why not? that seems like the only component that's not written in Java. lol. I think it's best that Spring stays on as server side programming. Still, Spring is all about "choices", right? So if you don't like GWT you don't have to use that. I'm just glad that it has support for it...not that I will ever use it. Sorry, GWT sux.
I agree w/ other people that GWT is for someone who's afraid of JavaScript. I really don't belive in philosophy of "Java for everything". What's next? CSS in Java? Why not? that seems like the only component that's not written in Java. lol. I think it's best that Spring stays on as server side programming. Still, Spring is all about "choices", right? So if you don't like GWT you don't have to use that. I'm just glad that it has support for it...not that I will ever use it. Sorry, GWT sux.
I disagree. Strongly. Have you used it on a product? I have. I would submit that there currently exists no finer way to bring structure to a web-based front-end.
Want to have a page that inherits menus from a base class?
Want compiler level checks on code?
Want top-notch debugging, front-end to middle tier to data tier?
Want *all* the refactoring support you can handle?
Want to use your choice of IDE?
GWT brings all of this to the table with very little of the "cruft" that attaches to large, long lasting js projects.
Most of the people posting comments here do not seem to have real experience bulding production applications with GWT, and base their opinions on other peoples blogs and runing a "hello world" app. It seems that the concensus is that devs use GWT because they are afraid of JS/CSS. This can't be further from the thruth - at leas in my experience. Over the course of the last three years, I watched, developed and managed a few projects that use GWT. The first one was a rewrite of Prototype/Scriptaculus app in GWT - this means that "afraid of JS/CSS" just does not apply here. The others were: a pretty complex admin tool - 100% Rich single app, and yet another app was a sophisticated single page contyent app embedded into a website (styled in such a way that you can't tell it was GWT). After my experiences, I can see that GWT has huge value, but for specific applicaitons. First, GWT apps are blazingly fast. The JS is highly optimized, and by default compatible across browsers. A large amount of code can be shared across server and client - as a result, it is testable with JUnit. Besides, since all code is Java, it is statically typed and verified by compiler, fleasing many runtime bugs - something you just do not have with JS. Any Java developer will feel comfortable with it after only a few hours, and development is really fast. Just putting together all the "plugins" and various JS libraries for some tasks takes a whole alot of time. I was using a jQuery on a recent project and all I needed was a friken modal box. I tried a few and all were pretty bad - one of them (will not name) even mangled jQuery itself (some functions stopped working). I screwed with this for at least two hours - two hours of my life that were just wasted! For something as simple as this... in GWT I would not even have to pause - this is a one minute task.
All of you who bash it, please stop doing this and develop at least one app that is not trivial, and then try to do the same in JS.
However, GWT is not an "all purpose" tool. I would use it on projects where I would not need SEO and were reacher experience is a preferred way of doing things.
The more complex the project - the more benefit you get out of GWT.
Unfortunately I cannot say the same thing about Spring. IMHO, Spring is the anathema that it promised to eliminate (EJB). In other words, Spring has become the EJB du jure. In most Java projects I was part of in the past few years, Spring was just a pain with little gain. The marriage of Spring and GWT is surprizing and disconcerning, I hope this just blows over. If Spring migrates to Clouds, we will be biting the dust for years to come. Every project where I did not use Spring turned out to be more elegant, simpler, easier to test and maintain (lighter too - fewer dependencies). I seriously do not understand the fact that you cannot rip Spring out of Java developers cold dead hands ...Spring is not the authoritative way to do DI, I hope more people would realize this.
cheers,
Igor
