Kai Wähner

@James: I think you interpret it wrongly: "Interesting - we're one day into the poll and it seems that over half of the people who responded are happy with Java 6."

You cannot deduce this from the question. The answers do not say if someone is happy or why someone did (not) change yet. Therefore, you should either change the question or the answers :-)

Many people would like to migrate to Java 7 probably to use its advantages. But it is not allowed / reasonable in several projects...

@James: I think you interpret it wrongly: "Interesting - we're one day into the poll and it seems that over half of the people who responded are happy with Java 6."

You cannot deduce this from the question. The answers do not say if someone is happy or why someone did (not) change yet. Therefore, you should either change the question or the answers :-)

Many people would like to migrate to Java 7 probably to use its advantages. But it is not allowed / reasonable in several projects...

I just wrote an article, which explains my experiences with Apache Camel and its alternatives Spring Integration and Mule ESB:

Spoilt for Choice: Which Integration Framework to use - Spring Integration, Mule ESB or Apache Camel?

I just wrote an article, which explains my experiences with Apache Camel and its alternatives Spring Integration and Mule ESB:

Spoilt for Choice: Which Integration Framework to use - Spring Integration, Mule ESB or Apache Camel?

My Scala skills lie anywhere in between novice and medium. I understand the code, but it takes some time.

I am no fan of "you can do THIS in only X lines with THAT language". I prefer using one or two additional lines. It is much easier to read, also for good developers IMO.

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

Thanks for your comments.

@André: Well, you are right: You should not consider only product costs (they are not much cheaper for Liferay than for Oracle), but the whole development cycle. Maybe my article was a little bit unclear about this!

I see, you have a lot more experience with Portlets than me. We did not go any further, because we decided that a Portal / Portlets are not reasonable for our project.

Regarding the Oracle stack: We only evaluated the Portal which Oracle offered us combined with its Oracle SOA Suite (WebCenter). I did not make the choice, I just had to evaluate it...

@Erron: As already mentioned, I do not have much experience with Portlets. We decided that it is too much extra effort without creating a prototype or so :-) Thus, I cannot tell you anything about the GWT Portlet plugin. Maybe someone else can?

Thanks for your comments.

@André: Well, you are right: You should not consider only product costs (they are not much cheaper for Liferay than for Oracle), but the whole development cycle. Maybe my article was a little bit unclear about this!

I see, you have a lot more experience with Portlets than me. We did not go any further, because we decided that a Portal / Portlets are not reasonable for our project.

Regarding the Oracle stack: We only evaluated the Portal which Oracle offered us combined with its Oracle SOA Suite (WebCenter). I did not make the choice, I just had to evaluate it...

@Erron: As already mentioned, I do not have much experience with Portlets. We decided that it is too much extra effort without creating a prototype or so :-) Thus, I cannot tell you anything about the GWT Portlet plugin. Maybe someone else can?

Good article. I agree that a SQL database built on NoSQL foundations would be the best solution, and sufficient in 80 percent. Nevertheless, I wonder if such a solution will be available soon.

I also discussed the problem "NoSQL vs. SQL" shortly in my article about Google App Engine (GAE) with Spring Roo: http://www.kai-waehner.de/blog/2011/07/18/rapid-cloud-development-with-spring-roo-%E2%80%93-part-1-google-app-engine-gae.

I think that there are some reasons why Google developers do not support SQL (yet), but only NoSQL using BigTable. Is uses several different concepts - and these concepts seem to be necessary for offering good scalability in the cloud at the moment.

Everyone should be aware that GAE is the only production-ready PaaS solution in the Java environment at the moment. For instance, VMware Cloud Foundry will support MySQL from the beginning, but it is still in BETA status. I assume that it is not that easy to offer good scalability using MySQL as database in the cloud. I also assume that Google developers know what they do and why they do not offer a SQL solution for GAE yet. Nevertheless, I am really looking forward to the final release of Cloud Foundry.

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

Traits are my favorite feature in Scala.They are easy to understand, do solve the "diamond problem" of multiple inheritance and give a lot of opportunities to seperate and structure code.

I would appreciate if Traits make it to Java. That would be much more important than Closures and all this stuff (because e.g. Closures will be ugly in Java, no matter which syntax will finally be chosen)...

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

Hey Matt,

I really like JSF 2.0, it is much more productive than older versions. I think many (other) people still use their old knowlegde of JSF 1.x and do comparisons as they do with EJBs. Of course, JSF is not as productive as Spring Roo, Play or Grails.

Nevertheless, I think it is the best choice for a server-side web framework if you have to realize a really huge web application with many developers (besides CRUD). The productivity of Spring Roo is awesome - but only for the initial startup of a web application (see my blog "When to use Spring Roo and when NOT to use it": http://www.kai-waehner.de/blog/2011/04/05/when-to-use-spring-roo/).

I listened to your web framework comparison at Java Symposium 2011 in Las Vegas some months ago (I especially liked your presentation style) and in my opinion JSF is not as bad as you make it :-) Nevertheless, I want to mention that things like TDD with JSFUnit is everything else, but NOT productive! It is a lot of effort...

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

BTW: I also had problems with the lights in my Jazoon talk on Tuesday about Apache Camel. Besides, the cinema environment is awesome for such a conference!

@Mark: You are right! I was not aware that e.g. WebLogic or WebSphere MQ also offer Multicast support. Although I think that Tibco RV is most widespread for multicast solutions, I changed the title and some content to make this clear. Thanks for your feedback.

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

@Mark: You are right! I was not aware that e.g. WebLogic or WebSphere MQ also offer Multicast support. Although I think that Tibco RV is most widespread for multicast solutions, I changed the title and some content to make this clear. Thanks for your feedback.

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

@Mark: You are right! I was not aware that e.g. WebLogic or WebSphere MQ also offer Multicast support. Although I think that Tibco RV is most widespread for multicast solutions, I changed the title and some content to make this clear. Thanks for your feedback.

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

@Mark: You are right! I was not aware that e.g. WebLogic or WebSphere MQ also offer Multicast support. Although I think that Tibco RV is most widespread for multicast solutions, I changed the title and some content to make this clear. Thanks for your feedback.

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

For the point of "slow performance with certified messages", I can only talk about the experiences our architects made when evaluating several JMS implementations (including Websphere MQ and some open source products) and Tibco RV about 3 years ago for their project: Certified Tibco messages were much slower than not certified ones. But honestly, unreliable messaging was very acceptable for our use case, so maybe they did not evaluate Certified Tibco messaging a lot...

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

For the point of "slow performance with certified messages", I can only talk about the experiences our architects made when evaluating several JMS implementations (including Websphere MQ and some open source products) and Tibco RV about 3 years ago for their project: Certified Tibco messages were much slower than not certified ones. But honestly, unreliable messaging was very acceptable for our use case, so maybe they did not evaluate Certified Tibco messaging a lot...

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

For the point of "slow performance with certified messages", I can only talk about the experiences our architects made when evaluating several JMS implementations (including Websphere MQ and some open source products) and Tibco RV about 3 years ago for their project: Certified Tibco messages were much slower than not certified ones. But honestly, unreliable messaging was very acceptable for our use case, so maybe they did not evaluate Certified Tibco messaging a lot...

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

For the point of "slow performance with certified messages", I can only talk about the experiences our architects made when evaluating several JMS implementations (including Websphere MQ and some open source products) and Tibco RV about 3 years ago for their project: Certified Tibco messages were much slower than not certified ones. But honestly, unreliable messaging was very acceptable for our use case, so maybe they did not evaluate Certified Tibco messaging a lot...

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

Hm, it is definitely not! If you can tell me some other good middleware for multicast messaging, I will immediately add them to this article...

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

Hey Shekhar,

good article. But did you also realize some relationships between entities? I think "OneToMany" and so on do not work with GAE?

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

Hey Shekhar,

good article. But did you also realize some relationships between entities? I think "OneToMany" and so on do not work with GAE?

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

Hey Dean,

the intention of this article is not to explain what Spring Roo is!

In a nutshell: It is a development infrastructure, a collection of tools, frameworks and libraries to ease Java development (not just web development).

You might look at this very good article series to get a quick understanding of Spring Roo:

http://www.ibm.com/developerworks/opensource/library/os-springroo1/index.html

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

Hey Dean,

the intention of this article is not to explain what Spring Roo is!

In a nutshell: It is a development infrastructure, a collection of tools, frameworks and libraries to ease Java development (not just web development).

You might look at this very good article series to get a quick understanding of Spring Roo:

http://www.ibm.com/developerworks/opensource/library/os-springroo1/index.html

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

Hey Dean,

the intention of this article is not to explain what Spring Roo is!

In a nutshell: It is a development infrastructure, a collection of tools, frameworks and libraries to ease Java development (not just web development).

You might look at this very good article series to get a quick understanding of Spring Roo:

http://www.ibm.com/developerworks/opensource/library/os-springroo1/index.html

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

Hey Andrew,

I agree 100 percent, IF you want to create a Spring application.

But if you want to create something else, you should not use Spring Roo in my opinion. It falls down when you have to realize more than just CRUD. Of course, you can customize everything by yourself. Actually, you even still have the possiblity to use e.g. the “finder”-feature of Roo to create finders.

Nevertheless, if you have to create a lot of stuff besides CRUD, you are mixed in between “what to do with Roo” and “what to do without Roo”. You can also get stuff out of AspectJ into your Java code. Thus, governance and maintainability is much more complex if you use Roo for some stuff and no Roo for other stuff.

Try out e.g. GWT with Roo. If you create a CRUD application with 5 entities and relationships, you get about 200 (or maybe only 50 classes, but toooo many!). That is fine if you just need CRUD, but if you want to customize some masks, it is no fun and time-consuming.

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

Hey Andrew,

I agree 100 percent, IF you want to create a Spring application.

But if you want to create something else, you should not use Spring Roo in my opinion. It falls down when you have to realize more than just CRUD. Of course, you can customize everything by yourself. Actually, you even still have the possiblity to use e.g. the “finder”-feature of Roo to create finders.

Nevertheless, if you have to create a lot of stuff besides CRUD, you are mixed in between “what to do with Roo” and “what to do without Roo”. You can also get stuff out of AspectJ into your Java code. Thus, governance and maintainability is much more complex if you use Roo for some stuff and no Roo for other stuff.

Try out e.g. GWT with Roo. If you create a CRUD application with 5 entities and relationships, you get about 200 (or maybe only 50 classes, but toooo many!). That is fine if you just need CRUD, but if you want to customize some masks, it is no fun and time-consuming.

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

Hey Andrew,

I agree 100 percent, IF you want to create a Spring application.

But if you want to create something else, you should not use Spring Roo in my opinion. It falls down when you have to realize more than just CRUD. Of course, you can customize everything by yourself. Actually, you even still have the possiblity to use e.g. the “finder”-feature of Roo to create finders.

Nevertheless, if you have to create a lot of stuff besides CRUD, you are mixed in between “what to do with Roo” and “what to do without Roo”. You can also get stuff out of AspectJ into your Java code. Thus, governance and maintainability is much more complex if you use Roo for some stuff and no Roo for other stuff.

Try out e.g. GWT with Roo. If you create a CRUD application with 5 entities and relationships, you get about 200 (or maybe only 50 classes, but toooo many!). That is fine if you just need CRUD, but if you want to customize some masks, it is no fun and time-consuming.

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

Meanwhile, Smart GWT 2.4 (LGPL and EE) is available. Besides some very good new features such as offline capability or some more powerful components, the quick start guide is much more extensive than some months ago. I really appreciate that!

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

Great article, Nicolas!

I like it to use Scala with an existing Java web framework. On the other hand, I do not like some concepts of Lift that much. Your example looks like it really eases development with Vaadin (given that you already know Scala). Thus, I hope to read more experiences from you...

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

I just tried out the newest release 2.5 (stable).

Now, an installer and very good configuration support is available. You do no more have to install JRebel manually. Great work of ZeroTurnaround!

The disadvantages are very crucial for Java developers. But if you really need to build a RIA, there is no alternative to Flex at the moment (because the old JavaFX of 2010 has too many disadvantages, e.g. bad IDE support, just basic widgets, also a new programming language).

I hope that the new JavaFX of 2011 will solve this problem. It has much potential for Java developers (Java language, thus also good IDE support), but maybe it is too late... I think, if the new JavaFX will have good widgets, it has a chance!

At the moment, I (as Java developer) would use other Web-Frameworks such as JSF or GWT wherever possible, but if the requirements demand be a "real" RIA, you have to use Flex.

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

@Charles:

I agree with you, that the "I perspective" is missing in this part! I do not want to damage anyone. So I also changed this part a little bit to make clear, that this is MY personal experience.

Probably, I still would use plain Hibernate and GWT RPC next time instead of the server-side integration of SmartGWT.

But there is no question that you can also build good, complex enterprise web applications with SmartGWT - of course you can! If someone wants to use SmartGWT server-side, the support must be bought, too (in my opinion).

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

@Charles:

I agree with you, that the "I perspective" is missing in this part! I do not want to damage anyone. So I also changed this part a little bit to make clear, that this is MY personal experience.

Probably, I still would use plain Hibernate and GWT RPC next time instead of the server-side integration of SmartGWT.

But there is no question that you can also build good, complex enterprise web applications with SmartGWT - of course you can! If someone wants to use SmartGWT server-side, the support must be bought, too (in my opinion).

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

@Charles:

I agree with you, that the "I perspective" is missing in this part! I do not want to damage anyone. So I also changed this part a little bit to make clear, that this is MY personal experience.

Probably, I still would use plain Hibernate and GWT RPC next time instead of the server-side integration of SmartGWT.

But there is no question that you can also build good, complex enterprise web applications with SmartGWT - of course you can! If someone wants to use SmartGWT server-side, the support must be bought, too (in my opinion).

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

@Charles:

Thanks for your extensive comments. I do not disagree with a lot of your post, but remember: This is our experience! Some things you posted may be true, e.g. this one:

[quote] Have to really emphasize this: this is absolutely, 100% percent completely false. The fact that you ended up writing some kind of "mapping files" suggests that you badly misunderstood how the product is meant to be used and did something unnecessary. [/quote]

Yes. Maybe you are right! Maybe I did not understand some part of the product.

But the problems we had to solve were not in any tutorial or guide (by the way: I am not the guy who posted most of our problems in the forum). And the forum support could not help us with some of these problems. So maybe you can do this without mapping files, that is great! But unfortunatelly we could not make it, also if it may be possible!

So again: this is my experience with the product after one and a half persons worked some months with it (WITHOUT training or commercial support). I do not want to make things bad if they are not, I just wanted to report MY experiences! To make this more clear, I will add this information to the beginning of the article!

Next time, if we have to decide to use the server-side integration of SmartGWT, we would probably decide against it or also buy support, because in my opinion it is absolutely necessary to use SmartGWT successfully.

Unfortunately, we still have huge J2EE projects with EJB 2.1 and WebSphere AS 6.1. It is horrible! But because each new CR takes just some days, I am not sure if they will ever let us migrate it to at least JEE 5.

In my opinion, worse than the EJB 2.1 technology is the architecture. Countless interfaces everywhere (and I do not mean the EJB interfaces)! I think, there is almost an interface for EVERY class - no joke!

Everything is generic - and that deduces very awful, hard readable code. Theoretically, you could change every little bit of this X million dollar project. Of course, never ever anyone of the components was replaced :-)

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

I can only report from our project.

We use some tables with thousands of data entries (with live-scrolling). We use Buttons and Dropdown Boxes to Open new Windows. These windows also load data form the DB to manipulate them (CRUD). The new windows are loaded within some milliseconds. New data is auto-refreshed. If we store data, it shows up in the GUI instantly.

It is not that complex GUI! And it works really fine. Maybe there would be performance issues with huge or complex GUIs, but for us the performance is good and sufficient!

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

I can only report from our project.

We use some tables with thousands of data entries (with live-scrolling). We use Buttons and Dropdown Boxes to Open new Windows. These windows also load data form the DB to manipulate them (CRUD). The new windows are loaded within some milliseconds. New data is auto-refreshed. If we store data, it shows up in the GUI instantly.

It is not that complex GUI! And it works really fine. Maybe there would be performance issues with huge or complex GUIs, but for us the performance is good and sufficient!

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

I can only report from our project.

We use some tables with thousands of data entries (with live-scrolling). We use Buttons and Dropdown Boxes to Open new Windows. These windows also load data form the DB to manipulate them (CRUD). The new windows are loaded within some milliseconds. New data is auto-refreshed. If we store data, it shows up in the GUI instantly.

It is not that complex GUI! And it works really fine. Maybe there would be performance issues with huge or complex GUIs, but for us the performance is good and sufficient!

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

[quote]I have even been able to successfully integrate gwt-platform's MVP pattern with it.[/quote]

We also used the MVP pattern. I can recommend it to everybody! Also, since version 2.1 the MVP pattern is integrated in GWT.

[quote]the interoperability between SmartGWT widgets and regular GWT widgets is horrible[/quote]

That is true. But because every GWT widget is also available as SmartGWT widget, that is no problem, isn't it? So you do not have to combine both.

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

@Dejan:

I added one PRO i forgot! Please read it again. We had no performance problems. The GWT development mode worked without any problems.

And we also used some GWT-RPC calls to call some EJBs (but we do NOT use JSNI / handwritten JavaScript at all).

@Aleksandar:

I also like Vaadin. I think it is a great alternative if you want to realize a server-centric web application.