The difference to other competing HTML5 frameworks shall be the end-to-end development vom client to backend with just one Java framework. Thus, Avatar will compete with other client-side Java frameworks such as Google Web Toolkit (GWT). Avatar shall be easy to use and finally be fun to create HTML5 web applications in the Java environment. In the end, Oracle alone will offer three different alternatives for creating modern web applications: Java Server Faces (JSF) as Java EE standard, JavaFX, and Avatar.

In the meantime, this raises the question of whether JavaFX is still a good alternative for creating web applications. Because of the required browser-plugin at runtime, JavaFX is a bad decision in many use cases. Instead, JavaFX is highly recommended for creating desktop applications (as replacement for Swing), and will be a good alternative for embedded applications (where devices usually do not offer a browser).

Unfortunately, Avatar still looks like a blackbox to me – even after some days at JavaOne 2012. If you google for it, you just find information about announcements from JavaOne 2011 (e.g. http://www.theserverside.com/feature/Project-Avatar-One-HTML5-Strategy-to-Rule-Them-All). There was also a web framework panel at JavaOne 2012 with experts from JSF, Grails, Play, and Avatar. Several questions regarding Avatar could only be answered with empty phrases such as „sorry, as we are not ready for production yet, this answer cannot be answered reasonable“.

In the end, Avatar may become an interesting alternative for creating modern, plugin-independent HTML5 web applications within the Java environment… In the future! However, it is still a blackbox without a website, download, or community. So, developers probably have to wait some more time to get additional information.

If you have any other opinions, or if you can find further information about Avatar, feel free to post a comment…

UPDATE (Day 3 at JavaOne 2012):

I could take a look at some source code of an Avatar project at the Oracle booth of JavaOne 2012. Honestly, I do not like the concepts of Avatar. You write web applications by using a new declarative XML language which uses HTML5 and JavaScript inside. You define your data objects in JavaScript on client-side. You write your server-side code either in JavaScript or via JAX-RS. It’s your choice. Communication is via JSON.

So, the goal of Avatar is NOT to make developing modern HTML5 web applications more fun for Java developer, but the “new” goal is to offer a good solution for web developers (i.e. HTML5 / JavaScript experts). Nevertheless, these web developers also have to learn a new framework around the new declarative XML language.

Due to my first impressions, I would still use JSF, GWT or another web framework instead of Avatar in the future…

BTW: Even after showing some source code at JavaOne 2012, Avatar is still a blackbox because there is no product strategy yet – as one of the Oracle guys confirmed to me. Of course, this is also the reason why there is no website or download available yet.

Best regards,
Kai Wähner (Twitter: @KaiWaehner)

The post Avatar as Alternative for Java Server Faces (JSF) and JavaFX? – JavaOne 2012 appeared first on Kai Waehner.

A decision has to be made for the upcoming project: Shall we use HTML5 or JavaFX 2 for realizing the web client? If you ask Google for “javafx or html5”, you do not find much information. In the majority of cases, you end up with a presentation hold at several IT conferences in 2011: “Moving to the Client: JavaFX and HTML5 Presentation”. Here is the Slideshare link (from JavaOne 2011): http://www.slideshare.net/steveonjava/moving-to-the-client-javafx-and-html5. Because this presentation does not help much, we took a look at pros and cons, which are listed below in this blog post.

But let’s start from the beginning…

What is a Rich Internet Application (RIA)?

There is no real definition for RIA. Therefore, here is my definition for this blog post:

“A Rich Internet Application provides a modern looking web application with animations, effects and multimedia features. The web application is hardly recognizable as web application. There is no classic HTML user interface with forms, drop down boxes or tables. Typical features of web browsers such as bookmarking or forwards / backwards navigation are usually missing / not required. It is client-centric, i.e. most of the user interface is loaded at the beginning to offer very good responsiveness. Sometimes (i.e. if you use a web framework instead of just HTML5), a plugin must be installed (e.g. Java Runtime Environment or Adobe Flash Player). Pokerstars (www.pokerstars.com) is a very good example for a RIA.”

Alternatives

Several alternatives are available in the JVM environment for realizing a RIA:

• Plain HTML5: Good solution, but you do not code in Java or another JVM language.
• Adobe Flash / Flex: Dead! Even Adobe moves to HTML5.
• Microsoft Silverlight: Dead! Even Microsoft Windows 8 moves to HTML5. (Of course, Silverlight is no real JVM solution, but you can make it work together with JVM backend. For the sake of completeness, I added it to this list.)
• JavaFX: Java-based solution (replacement for Swing in the future).
• Other JVM web frameworks besides JavaFX (JSF, GWT*, Wicket, Tapestry, Grails, Lift, “You-Name-It”): Not built for realizing RIAs. Yes, you can realize a RIA with these frameworks. Though, development is ugly, and the RIA will be ugly, too. So why would you do this? (Please remember my above definition of a RIA before you begin complaining in the comments!)

* GWT also has nice (experimental) HTML5 support for some features already: http://www.google.com/events/io/2011/sessions/gwt-html5-a-web-developers-dream.html => If Google continues adding support for HTML5 to GWT, this may be a good alternative in the next years, too – you develop only in Java, and you do NOT need a browser plugin because GWT generates plain HTML and JavaScript. However, there are also rumors that GWT is dying due to Google’s new language Dart. Google did not comment this yet, or release a roadmap for GWT.

So, the question is when to use JavaFX 2 instead of HTML5 for realizing a RIA (from the view of a Java developer)? If you do not know much about HTML5 or JavaFX, you should look at Wikipedia or google for other articles.

What is HTML5?

=> http://en.wikipedia.org/wiki/Html5

Important: HTML5 is HTML + CSS + JavaScript! It offers several next generation features for modern web development, such as Offline Storage or Application Cache.

What is JavaFX?

=> http://en.wikipedia.org/wiki/Javafx

Reminder: We are talking about JavaFX 2.0. The main difference to earlier versions is that JavaFX now offers a Java API instead of a new programming language (JavaFX Script). Thus, it is easy to learn for a Java developer.

Why HTML 5 / JavaScript?

Pros

• W3C standard
• It’s the future – no question!
• No plugin is required, can be used in every (supported) web browser
• Already many widgets and features available

Cons

• Development with HTML / JavaScript instead of Java => Main disadvantage for a Java developer!
• Spec not final yet (according to the roadmap not before 2014!)
• Not supported by all browsers (yet)
• Cross-browser development is necessary (JavaScript frameworks such as jQuery or Dojo solve this problem, but increase efforts nevertheless)

Probably, there are many other pros and cons for HTML5. Though, the named ones should be sufficient for deciding when to use HTML5 or JavaFX.

Why JavaFX 2?

Pros

• Offers a Java API => Leverage your Java skills and use existing JVM features and libraries
• Offers DSLs for further JVM languages, e.g. Groovy (GroovyFX) and Scala (ScalaFX). Read this article to learn how to benefit by using modern JVM languages instead of Java: “JavaFX 2.0 and Scala, Like Milk and Cookies” => http://www.javacodegeeks.com/2012/02/javafx-20-and-scala-like-milk-and.html
• optional: “layouting” language FXML to split UI definition from behaviour => choose your favorite between programming (with Java) and layouting (with FXML)
• Same development environment for backend and web client (including debugging, refactoring, etc.)
• No cross-browser problems
• CSS support (as in HTML)
• HTML and / or JavaScript can be integrated in a JavaFX application
• Swing and JavaFX can be used in same application, so existing Swing applications can be extended
• JavaFX 2 provides a unified architecture for writing an application once and then deploying it to various contexts (standalone application, embedded in a web browser or run via Java Web Start). Additional contexts will be added in the future (e.g. running the same application on a mobile device).

Cons

• Java Runtime Environment is required on client
• Only parts of JavaFX are open source. The Oracle JavaFX runtime and SDK will continue to be released under the Java Binary Code License
• JavaFX for Mac only available as Developer Preview (GA planned for the mid of 2012) => see JavaFX roadmap
• JavaFX for Linux not available yet (Developer Preview planned for Q3 of 2012)
• No information about future of JavaFX Mobile yet (at least I did not find anything, if someone has a link, please add a comment!)
• Offers less widgets and other features than HTML5
• Though JavaFX is the (future) replacement for Swing, development is different due to several new concepts. Of course, this is the consequence of adding RIA features such as animations => Thus, this is no real disadvantage, and its still easier for a Java developer to learn some new concepts than learning HTML and JavaScript

Conclusion

HTML5 and JavaFX 2 are both awesome for realizing RIAs including media, charts, animation, etc. In the end, both have a different target audience:

• Public web applications should be realized with HTML5, because requiring a browser plugin is a no-go in most use cases. Therefore, even for Java developer there is no alternative to HTML5.
• Within an enterprise, it may be acceptable to require a plugin. Probably, Java is already installed on most machines anyway. If all needed widgets and other features are available, JavaFX is the better choice for enterprise applications because a Java developer can realize RIAs much easier by developing in its well-known JVM environment.

Have fun realizing your RIA with HTML5 or JavaFX 2. By the way: We will probably choose JavaFX for our internal project because the required Java plugin is no show-stopper and most colleagues are Java developer.

If I missed any important pros or cons, or if you have any other feedback, please feel free to leave a comment…

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

The post When to use JavaFX 2 instead of HTML5 for a Rich Internet Application (RIA)? appeared first on Kai Waehner.

Publication Date: February 29, 2012

ISBN-10: 1430268727

ISBN-13: 978-1430268727

Edition: 1

Authors: Jim Weaver, Weiqi Gao, Stephen Chin, Dean Iverson, and Johan Vos

Publisher: Apress

Content

The book begins with a “getting started” chapter, which explains the initial setup of software and tools, and explains the basic concepts. This is what you need when you start with a new technology.

Afterwards, several chapters go into more detail about creating a user interface, defining properties and bindings, and using UI controls. After reading these chapters, you are ready to realize your first JavaFX application.

The next chapter explains the thread concept of JavaFX. This is very important to understand for writing responsive applications. After reading this chapter, you can start programming production-ready JavaFX clients. Of course, you also need to connect to a backend, so the chapter “accessing web services” is a must-read for developer who do not write standalone applications. The book explains several ways how to connect to a backend via XML or JSON. Even several addons and frameworks are mentioned including code examples (e.g. RESTFX or Jersey).

Further chapters describe how to use advanced UI controls for creating charts or including media files.

The last chapter describes how to use alternative JVM languages and layout markup languages besides Java, namely Groovy, Scala, FXML, and Visage. This chapter is awesome. Even if you do not have any experience with these languages, you will learn and understand the differences compared to Java, and see why and when you can benefit from using another language instead of Java.

Criticism

Even though this book is a great introduction to JavaFX 2, here is some criticism. The major weak point is that you do not get much information about deployment. You can deploy JavaFX applications as standalone application, as Applet within a web browser, or run it via Java WebStart. But how do you do that? How do you configure the application (e.g. how do you configure your JNLP file for Java WebStart)? Every developer needs to know this to use the application outside of his IDE… You have to google to get answers.

Besides, two minor weak points:

Firstly, there is no word about unit testing. How should you write tests for your JavaFX application? Are there any best practices?

Secondly, when should you use JavaFX, when should you use another framework (e.g. JSF, GWT, Grails, etc.)? This book has a lot of marketing style, so you won’t get an answer here about problems of JavaFX.

Conclusion

As mentioned in the beginning, this is a very good introduction to JavaFX (omitting the deployment aspect) and easy to read. Every feature is explained in detail, including good code examples. So, if you want to get started with JavaFX 2, I can recommend this book to you.

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

The post Book Review: Pro JavaFX 2 – A Definitive Guide to Rich Clients with Java Technology appeared first on Kai Waehner.

What is a Portal?

It is important to know that we are talking about an Enterprise Portal. Wikipedia has a good definition:

„An enterprise portal […] is a framework for integrating information, people and processes across organizational boundaries. It provides a secure unified access point, often in the form of a web-based user interface, and is designed to aggregate and personalize information through application-specific portlets.“

Several Portal server are available in the Java / JVM environment. Liferay Portal and GateIn Portal (former JBoss Portal) are examples for open source products while Oracle Portal or IBM WebSphere Portal are proprietary products.

You develop Portlets („simple“ web applications) and deploy them in your portal. If you need to know more about a Portal or the Portlet JSR standards, ask Wikipedia: http://en.wikipedia.org/wiki/Portlet.

Should we use a Portal or not?

I found several pros and cons for using a Portal instead of just web applications.

Disadvantages of using a Portal:

• Higher complexity
  • Additional configuration (e.g. portlet.xml, Portal server)
  • Communication  between Portlets using Events is not trivial (it is also not trivial if two applications communicate without portlets, of course)
  • Several restrictions when developing a web application within a Portlet
• Additional testing efforts (test your web applications and test it within a Portal and all its Portal features)
• Additional costs
  • Open source usually offers enterprise editions which include support (e.g. Liferay)
  • Proprietary products have very high initial costs. Besides, you need support, too (e.g. Oracle)
• You still have to customize the portal and integrate applications. A portal product does not give you corporate identity or systems integration for free. Software licensing often is only ten percent of the total price.
• Developers need additional skills besides using a web framework
• Several restrictions must be considered choosing a web-framework and implement the web application
  • Rethinking about web application design is necessary
  • Portlets use other concepts such as events or an action and render phase instead of only one phase
  • Frameworks (also called bridges) help to solve this problem (but these are standardized for JSF only, a few other plugins are available, e.g. for GWT or Grails)
  • Actually, IMO you have to use JSF if you want to realize Portlets in a stable, relatively „easy“ and future-proof way. There is no standard bridge for other frameworks. There are no books, best practices, articles or conference sessions about Portlets without JSF, right?

Advantages of using a Portal

Important: Many of the pros can be realized by oneself with relatively low efforts (see red font).

• Single Sign On (SSO)

Several Java frameworks are available, e.g OpenSSO (powerful, but complicated) or JOSSO (not so powerful, but easy to use).

Good products are available, e.g. Atlassian Crowd (I love Atlassian products such as Crowd, Jira or Confluence, because they are very intuitive and easy to use).

• Integration of several applications within one GUI
  • A portal gives you layout and sequence of the applications for free (including stuff such as drag & drop, minimizing windows, and so on)
• Communication between Portlets (i.e. between different applications)

This is required without a portal, too.

Several solutions can be used, such as a database, messaging, web services, events, and so on.

Even „push“ is possible for some time now (using specific web framework features or HTML 5 websockets).

• Uniform appearence

CSS can solve this problem (the keyword „corporate identity“ exists in almost every company).

Create a HTML template and include your applications within this template. Done.

• Personalization
  • Regarding content, structure or graphical presentation
  • Based on individual preferences or metadata

Some of these features can be realized very easily by oneself (e.g. a simple role concept).

Nevertheless, GUI features such as drag & drop are more effort (although component libraries can help you a lot).

• Many addons are included
  • Search
  • Content management
  • Document management
  • Web 2.0 tools (e.g. blogs or wikis)
  • Collaboration suites (e.g. team pages)
  • Analytics and reporting
  • Development platforms

But:

A) Do you really need these Features?

B) Is the offered functionality sufficent? Portals only offer „basic“ versions of stand-alone products. For instance, the content management system or search engine of a Portal is less powerful than other „real“ products offering this functionality.

Thus, you have to think about the following central question: Do we really need all those features offered by a portal?

Conclusion:

The total cost of ownership (TCO) is much higher when using a portal. You have to be sure, that you really need the offered features.

In some situations, you can defer your decision. Create your web applications as before. You can still integrate them in a Portal later, if you really need one. For instance, the following Oracle blog describes how you can use iFrames to do this: http://blogs.oracle.com/jheadstart/entry/integrating_a_jsf_application

If you decide to use a Portal, you have to choose a Portal product.

Should we use an Open Source or Proprietary Portal Product?

Both, open source and proprietary Portal products have pros and cons. I especially looked at Oracle Portal and Liferay Portal, but probably most aspects can be considered when evaluating other products, too.

Advantages  of Oracle Portal

• Oracle offers a full-stack suite for development (including JSF and Portlets): Oracle Application Development Framework (ADF)
• Oracle JDeveloper offers good support for ADF.
• Everything from one product line increases efficiency (database, application server, ESB, IDE, Portal, …) – at least in theory J

Disadvantages of Oracle Portal:

• High initial costs (I heard something about 200K in our company)
• Complex, heavyweight product (compared to Liferay Portal)
• Proprietary
• Communication between Portlets is not implemented using the standard JSR-286, but a custom proprietary solution (Source: http://www.contribute.be/web/contribute/news/-/journal_content/56_INSTANCE_pdF5/10234/21893)

Advantages  of Liferay Portal:

• Open source
• Drastically lower initial costs
• Lightwight product (1-Click-Install, etc.)

Disadvantages of Liferay Portal:

• Not everything is from one product line (this cannot be considered as disadvantage always, but in our case the customer preferred very few different vendors (keyword “IT consolidation”)
• Portlets are still Portlets. Although Liferay is lightweight, realizing Portlets still sucks as it does with a proprietary product

When to use a Portal?

Well, the conclusion is difficult. In my opinion, it does make sense only in a few use cases. If you really need many or all of those Portal features, and they are also sufficient, then use a Portal product. Though, usually it is much easier to create a simple web application which integrates your applications. Use a SSO framework, create a template, and you are done. Your developers will appreciate not to work with Portlets and its increased complexity and restrictions.

Did I miss any pros or cons? Do you have another opinion (probably, many people do???), then please write a comment and let’s discuss…

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

The post Pros and Cons – When to use a Portal and Portlets instead of just Java Web-Frameworks appeared first on Kai Waehner.

What is Spring Roo?

“Spring Roo is a lightweight developer tool that makes it fast and easy to deliver instant results. Best of all, you code 100% in Java and get to reuse all your existing Java knowledge, skills and experience. You’ll like it – and have plenty of fun too!” (http://www.springsource.org/roo)
Many introductory articles exist already, just use Google if you do not know Spring Roo yet. In a nutshell: Spring Roo is a Java-based tool (using the SpringSource Tool Suite which is based on Eclipse). It uses AspectJ to simulate many features of Grails and other frameworks with dynamic languages to improve the developer experience.

Spring Roo is awesome for CRUD-Clients!

You can create a CRUD application within minutes to create, read, update and delete data. I recommend Spring Roo for CRUD applications because of a good community and a powerful vendor (compared to other CRUD frameworks such as Roma Meta Framework or OpenXava).
Personally, I would prefer Grails, but if you want to create CRUD applications with Java, then Spring Roo is the best alternative.

Spring Roo is good for learning Technologies!

Spring Roo is also good for learning technologies because you get a working example in seconds, and you can create more complex stuff within minutes using the Roo Shell. Then you can learn and understand how Spring Roo uses these technologies.
Of course, Spring-based technologies such as Spring MVC or Spring Security are supported very well. Also JEE standards such as Bean Validation or JPA are supported. Besides, many further technologies are supported, e.g. GWT, JSF, Vaadin, Flex or Google App Engine. Actually, many of these addons are not production-ready yet – but Spring Roo is young and I am sure that many improvements will happen because of the large community.

Spring Roo is NOT good for complex Projects (yet)…

Please be aware, that this is my personal opinion due to my experience with Spring Roo: If you want to build something really complex, then you should use technologies such as JPA, GWT or Google App Engine without Spring Roo, because Spring Roo is not ready yet for this kind of project, and thus will probably create more questions than answers…
One exceptional case: If you want to realize an application which uses especially or better just Spring frameworks, then you might start your project with Spring Roo. It can be a huge help in the beginning of a project.

Conclusion: Spring Roo is a nice Tool => Become a Part of the Community!

My final conclusion: You should know Spring Roo, because it is nice, but you should also know when to use it and when to use something else. Use it to create CRUD applications or to learn technologies. Do not use it (yet) for complex, large projects.
Spring Roo is young and has a large community plus a powerful vendor. You should participate and become a part of the Roo community to make it better and production-ready (this does not mean you have to commit code – I do not commit code as well – but even if you only read the JIRA issues and vote for your favorites helps the community).
So, if you never used Spring Roo yet, try it out now!

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

The post When to use Spring Roo? appeared first on Kai Waehner.

The following article shows a categorization of Java / JVM web-frameworks, considering different types of web applications. The intention is to give an overview, not to start a flame war.

Motivation

An uncountable number of web-frameworks exists in the Java environment. If you visit IT conferences or google for comparisons, almost always you find a discussion about the advantages and disadvantages. Often, a flame war is the consequence, each guy likes or dislikes a specific framework. Thus, a neutral comparison, which helps to choose the one which fits best for your requirements, is rare.

In the following, I try to compare web-frameworks in a more neutral way. I categorize the most important web-frameworks in the Java / JVM environment (i.e. frameworks which generate bytecode for the JVM) by classifying them to different types of web applications.

My experiences from discussions with colleagues and customers showed me, that the consequence is a neutral overview without any flame war or framework-bashing. I wonder if you think so, too.

Types of Web Applications

Different types of web applications exist. They have different sizes. Thus, the time to develop them is varying, too. The following chart shows the types of web applications:

Classical Web Application

A classical web application (e.g. Amazon) is server-centric and uses HTML user interfaces with multi-page structure, bookmarking and forwards / backwards navigation. It is well-known since the beginning of the internet age. In the course of time, AJAX was integrated. Thus, just the changed part of the site has to be refreshed. A plugin is not necessary, but therefore the user inferface must be adjusted explicitly for every web browser.

Rich Internet Application (RIA)

A Rich Internet Application (e.g. Pokerstars) provides a modern looking web application with animations, effects and multimedia features. The web application is hardly recognizable as web application, there is no HTML user interface with forms, drop down boxes or tables. Typical features of web browsers such as bookmarking or forwards / backwards navigation are usually missing. A plugin must be installed required (e.g. Java Runtime Environment or Adobe Flash Player).

Rich Client

The Rich Client mixes the characteristics of classical web applications and RIAs. The web application is client-centric (i.e. the user interface is loaded to client at the start of the application). The view uses HTML widgets, thus no plugin is required. Contrary to RIAs, the goal of a Rich Client is NOT to offer a modern looking user interface, but to improve the usability of an already widespread and accepted view.

CRUD Client

A CRUD Client complies to a classical web application. However, it primarily offers functionalities to create, read, update and delete data.

The web-frameworks for CRUD clients have a conceptual difference: Instead of just realizing the user interface, the whole application (database, application logic and user interface) is realized at once. Important characteristics of these frameworks are „Convention over Configuration“ and „Code-Generation“. The main goal is high productivity, thus often „modern“ JVM languages such as Groovy or Scala are used.

Portal

A Portal offers the possibility to present different applications such as standard software, individual components or websites in a consistent way. A Portal Server such as Liferay Portal must be used in combination with one or more web-frameworks. The effort is huge, because you have to use a Portal server, create portlets and implement the communication between different portlets. A Portal does not make sense for a small web application – e.g. if you want to realize just a little CRUD Client, then a Portal Server and Portlets are oversized.

Categorization of Java / JVM Web-Frameworks

The following chart categorizes the most widespread and popular web-frameworks in the Java environment. Some important notes before:

• Complexity implies the view of a Java developer! Therefore, it is much more complex and time-consuming to learn e.g. Grails because you have to learn Groovy first.
• JavaFX: The new JavaFX (which will be released 2011 with a Java API) is meant here.
• Adobe Flex does not compile Java bytecode. Due to missing alternatives for a RIA in 2010 (besides the old JavaFX without Java API, bad IDE support, and so on), it is added nevertheless. Flex can be integrated with JEE by using tools such as GraniteDS.
• I cannot tell you, why JSF is a little bit above Wicket or Tapestry. The intention is to give an overview and a categorization, no flame war. So you also could put JSF a little bit below Wicket and Tapestry. Does not matter! The same is true for the other frameworks.

Key Message: Right Tool for Right Job!

The key message is: Use the right tool (i.e. web framework) for the right job!

If you want to realize…

… a classical web application, choose JSF or Wicket or Tapestry if you want to use a component-based framework. Use Spring MVC or Struts if you need an action-based (also called request-based) framework.

… a RIA, you have to use Flex or JavaFX, because none of the other frameworks offers the possibility to realize a modern looking application such as Pokerstars at the moment.

… a Rich Client, you have to evaluate if you need a Client-centric framework (such as GWT) or a Server-centric framework (such as Vaadin or ZK).

… a CRUD Client, you can realize it with every framework. If you want to realize it with high productivity, you should use a framework which is constructed exactly for this. If you are a good Java developer, you can use Spring Roo or the Roma Meta Framework. Grails (using Groovy) or Lift (using Scala) are good alternatives, if you are familiar with a „modern“ JVM language or if you want to learn that language.

… a Portal, you have to do much more work. Choose a Portal Server, use Portlets, and choose your web-framework. For this purpose, JSF could a good choice in the majority of cases, because good (and standardized) bridge implementations are available. But other web-frameworks offer “integration plugins”, too.

Conclusion

I showed you a categorization of web-frameworks in the Java / JVM environment, considering different types of web applications.

I hope this is a good overview. Discussions are welcome, but please do not start a flame war. Do not tell me that JSF is better than Wicket because of XYZ. But of course, tell me if you do not like this categorization considering different types of web applications. Tell me if some important framworks are missing or if anything else is in your mind besides a flame war.

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

The post Categorization and Comparison of popular Web-Frameworks in the Java / JVM Environment appeared first on Kai Waehner.

IMPORTANT: All information is my personal opinion! We bought the SmartGWT Power license, but we used SmartGWT without commercial training or commercial support. Regard this, when you read my stated CONs!

What is SmartGWT?

SmartGWT (http://code.google.com/p/smartgwt) is a component library for the Google Web Toolkit (GWT). Four different licences exists. The visual components are free (LGPL). Three further licences exists (see http://www.smartclient.com/product). These licences offer several additional features and components such as data binding, a “push”-implementation or Hibernate integration. We chose the Power Edition. SmartGWT is maintained by SmartClient (http://www.smartclient.com/smartgwt). SmartClient also offers commercial support.

Technically, SmartGWT is a wrapper framework for the JavaScript library of SmartClient. The whole architecture is described within the documentation of SmartGWT. To summarize: SmartGWT has a end-to-end application architecture where the client-side is for free and the server-integration is commercial. Of course you can just use the client side of SmartGWT, then you have to implement the server-side integration by yourself. In our project, we used GWT 2.0 and Smart GWT 2.3 Power.

Pros

– Many good components (almost everything you can imagine). Look at the showcase: http://www.smartclient.com/smartgwt/showcase. All components are displayed including source code examples.

– Verbose documentation and API. Every class has good documentation.

– Support for many technologies and frameworks (Hibernate, JMS, REST, WSDL, Microsoft Excel, and so on).

– Good performance. About 5000 data entries are inserted daily into one table. Thanks to “Live-Scrolling”! The initial loading of the web application takes some seconds, but that is no problem of SmartGWT, but a characteristic of every client-centric Rich Client / Rich Internet Application.

Cons

– You have to learn a totally new API. You know GWT, you know JPA, Hibernate or JDBC? Does not really matter! You just use the SmartGWT API. That is a problem especially for getting started and for maintenance, because other developers also first have to learn one more API.

– Almost no public information available (books, tutorials, blogs, articles, talks at conferences, best practices).

– No tutorials for realizing some (at least a little more complex) use cases. [UPDATE January 2011:] SmartGWT EE 2.4 released including much more extensive documentation and a good quick start guide!

– Commercial support is expensive. First we wanted to buy support (for some hundred dollars we thought), but it costs approximately as much as the SmartGWT Power license itself.

– Sometimes bad forum support. You get an answer to almost every posted question. But that answer often does not help. They ask you things such as “why do you want to do that”. Or they say: “use our tool and do XYZ with it” three times, although again and again I told them this suggestion does not work. After a few answers to a question the final answer is: “you need training, buy our support”. So you can either buy the support or try to find a workaround by yourself – and that can take a long time because you do not know the internals of SmartGWT and there is no public information such as a book, which you can “ask”.

– Promises to reduce boilerplate code because it automatically does the connection and integration to the database (create, read, update, delete) – that is true. But solely if you do not want to change anything and just use the basic behaviour. If I wanted to change just a small piece, I updated the automatically generated, huge XML mapping files or used setter-methods within the Java Code. If I just re-generated the mapping file, custom changes (e.g. specific WHERE-clauses) were overwritten, too. I could not find a better way. Thus, I do not see any benefit in using this server-side integration of SmartGWT instead of plain Hibernate or JDO and GWT RPC or REST communication. You just have one more abstraction layer to learn.

– Just a wrapper about a JavaScript framework instead of a native GWT implementation (for a counter-example see Ext GWT: http://www.sencha.com/products/gwt). That is no problem, if you just want to use the components. It is tougher, if you want to extend them. (Another myth is a worse performance because of this fact. We did NOT have any performance issues because of this fact)

Conclusion

At first glance, SmartGWT is a gift for you. The components are integrated in your web application easily. Your prototype is realized very fast (with dummy data instead of a real datasource). But the server-side integration is a lot of effort.
I had a lot of problems to solve and workarounds to find. Of course, you also have problems with other frameworks, but you have public information to look at for solutions.

Finally, SmartGWT did not save any development time (in my opinion! Some team members have another opinion and think it saved development time). Additionally, the project cannot be maintained by other developers, expect they also invest a lot of time in the SmartGWT API.

Would I use SmartGWT again?

Yes and no.

The components are great! They are easy to integrate and save a lot of development time. So I would use the client-side again.

The server-side integration is time-consuming and has no advantages for our team. If we had used JDBC, MyBatis or Hibernate for persistence and GWT RPC or REST for client-server-communication, then we would have finished the project with the same expenditure of time. But with some advantages: We know what we do. SmartGWT is one more abstraction level, and that is not an advantage in my opinion. Also, other developers can maintain the web application in the future, because they already know Hibernate or EclipseLink or Toplink (if you know one OR-Mapper, you can use them all).

Finally, I (again: me, not other team members) would use the client-side again, but not the server-side. Paradoxically, SmartClient earns money solely with the server-side stuff or the (proportionally too expensive) support.
SmartGWT is a very nice component library, but maybe the guys at SmartClient should rethink about their business model, if they want to acquire more customers.

Do you have the same expericences? Or do you disagree? Please make a post and tell me…

Best regards,
Kai Wähner

The post Lessons learned: SmartGWT 2.3 – Component-Library for Google Web Toolkit (GWT) appeared first on Kai Waehner.