Close

How to use GWT 2.8 in Vaadin applications today

GWT 2.8 brings a bunch of interesting new features and improvements for Vaadin client-side developers. Some of the most interesting features are Java 8 support and a matured JsInterop. You can catch up with other new developments from the GWT Release Notes. At the time of writing this, GWT 2.8 is in its release candidate phase.

In this post I’m going to show you how to use GWT 2.8 today when doing Vaadin client-side development. I’m going to use the Vaadin archetype widget as our example project. I’m using the newly released Vaadin 7.7 as that has changed the way Vaadin depends on GWT and thus makes using a custom GWT version simpler than ever before.

The sample project is available on GitHub. The first five commits correspond to the sections in this post so you can see exactly what was changed in each step.

Creating a project to work with

Let’s start by creating a project to work with. You can use the Maven command line:

mvn -B archetype:generate \
    -DarchetypeGroupId=com.vaadin \
    -DarchetypeArtifactId=vaadin-archetype-widget \
    -DarchetypeVersion=7.7.0 \
    -DgroupId=org.test \
    -DartifactId=widget \
    -Dversion=1.0-SNAPSHOT

or your IDE of choice to materialize a project.

Change GWT dependencies

If we take a look at the addon sub-module’s dependency tree using mvn dependency:tree, we can see some GWT 2.7 dependencies are brought in by com.vaadin:vaadin-client

$ mvn dependency:tree

--- maven-dependency-plugin:2.8:tree (default-cli) @ widget ---
org.test:widget:jar:1.0-SNAPSHOT
+- com.vaadin:vaadin-server:jar:7.7.0:compile
|  +- com.vaadin:vaadin-sass-compiler:jar:0.9.13:compile
|  |  +- org.w3c.css:sac:jar:1.3:compile
|  |  +- com.vaadin.external.flute:flute:jar:1.3.0.gg2:compile
|  |  \- com.yahoo.platform.yui:yuicompressor:jar:2.4.8:compile
|  |     \- rhino:js:jar:1.7R2:compile
|  +- com.vaadin:vaadin-shared:jar:7.7.0:compile
|  \- org.jsoup:jsoup:jar:1.8.3:compile
+- com.vaadin:vaadin-client:jar:7.7.0:provided
|  \- com.vaadin.external.gwt:gwt-elemental:jar:2.7.0.vaadin3:provided
|     \- com.vaadin.external.gwt:gwt-user:jar:2.7.0.vaadin3:provided
|        +- javax.validation:validation-api:jar:1.0.0.GA:provided
|        \- javax.validation:validation-api:jar:sources:1.0.0.GA:provide
\- junit:junit:jar:4.8.1:test
------------------------------------------------------------------------

These are practically the same as official GWT modules, but built by us to a different groupId. We need to exclude these dependencies and introduce equivalent GWT 2.8 dependencies. This can be done by adding an exclude rule to the pom.xml in the com.vaadin:vaadin-client section:

<dependency>
    <groupId>com.vaadin</groupId>
    <artifactId>vaadin-client</artifactId>
    <version>${vaadin.version}</version>
    <scope>provided</scope>
    <exclusions>
             <exclusion>
                   <groupId>com.vaadin.external.gwt</groupId>
                   <artifactId>gwt-elemental</artifactId>
             </exclusion>
    </exclusions>
</dependency>

 

And let’s introduce an equivalent GWT 2.8 dependency:

<dependency>
    <groupId>com.google.gwt</groupId>
    <artifactId>gwt-elemental</artifactId>
    <version>2.8.0-rc2</version>
    <scope>provided</scope>
</dependency>

Now we can build & install the project (run mvn clean install in the addon module) and move on to the demo project where the actual widget set compilation happens. Again we can run mvn dependency:tree to identify dependencies we need to change. Add the following exclude rules to the pom:

<dependency>
    <groupId>com.vaadin</groupId>
    <artifactId>vaadin-client-compiler</artifactId>
    <scope>provided</scope>
    <exclusions>
          <exclusion>
                  <groupId>com.vaadin.external.gwt</groupId>
                  <artifactId>gwt-dev</artifactId>
              </exclusion>
              <exclusion>
                  <groupId>com.vaadin.external.gwt</groupId>
                  <artifactId>gwt-elemental</artifactId>
              </exclusion>
    </exclusions>
</dependency>

And add equivalent GWT 2.8 dependencies:

<dependency>
    <groupId>com.google.gwt</groupId>
    <artifactId>gwt-dev</artifactId>
    <version>2.8.0-rc2</version>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>com.google.gwt</groupId>
    <artifactId>gwt-elemental</artifactId>
    <version>2.8.0-rc2</version>
    <scope>provided</scope>
</dependency>

Change to use the GWT 2.8 compiler

Normally Vaadin Maven projects use the vaadin-maven-plugin to compile the widgetset. We want to use the upstream gwt-maven-plugin instead. Let’s first configure the vaadin-maven-plugin to generate the widget set in a directory where the gwt-maven-plugin can find it. Add the following configuration section to vaadin-maven-plugin:

<groupId>com.vaadin</groupId>
<artifactId>vaadin-maven-plugin</artifactId>
<version>${vaadin.plugin.version}</version>
<configuration>
   <generatedWidgetsetDirectory>${basedir}/src/main/java</generatedWidgetsetDirectory>
</configuration>

Before generating the widget set, make sure that there is no existing *.gwt.xml files in the demo project, as the Vaadin plugin will only create a new widget set into src/main/java if there is no existing widget set it can update. To generate the widget set just run mvn vaadin:update-widgetset.

Next we can remove or comment out the compile goal from vaadin-maven-plugin as we’ll use the upstream GWT compiler for that:

<goal>resources</goal>
<!-- <goal>compile</goal> -->
<goal>update-widgetset</goal>

Last modification we need to do to the pom.xml is to add the gwt-maven-plugin build plugin:

<plugin>
   <groupId>org.codehaus.mojo</groupId>
   <artifactId>gwt-maven-plugin</artifactId>
   <version>2.8.0-rc2</version>
   <configuration>
       <webappDirectory>${basedir}/target/classes/VAADIN/widgetsets</webappDirectory>
   </configuration>
   <executions>
       <execution>
           <goals>
               <goal>compile</goal>
           </goals>
       </execution>
   </executions>
</plugin>

Test GWT compilation and run Jetty

Now you are ready to run mvn clean gwt:compile to compile the widget set. After the widget set is compiled you can run the demo UI using mvn jetty:run and access the test UI at http://localhost:8080/.

Use new GWT 2.8 features and recompile the widget set

Now for the fun part! We can start to utilize new GWT 2.8 features e.g. by simply changing the ClickHandler in MyComponentConnector from

getWidget().addClickHandler(new ClickHandler() {
    public void onClick(ClickEvent event) {
       final MouseEventDetails mouseDetails = MouseEventDetailsBuilder
               .buildMouseEventDetails(event.getNativeEvent(),
                       getWidget().getElement());
       // When the widget is clicked, the event is sent to server 
       // with ServerRpc
       rpc.clicked(mouseDetails);
    }
});

into a lambda expression:

getWidget().addClickHandler(event -> {
    final MouseEventDetails mouseDetails = MouseEventDetailsBuilder
           .buildMouseEventDetails(event.getNativeEvent(),
                   getWidget().getElement());
    rpc.clicked(mouseDetails);
});

After making changes to the addon project, you follow the normal workflow of mvn clean install in the addon project followed by a mvn clean gwt:compile in the demo project.

I hope this post helped you to get started with GWT 2.8 development. The next major Vaadin version, Vaadin 8, will use GWT 2.8 by default. This means that any Java 8 and JsInterop code you write today should be reusable in Vaadin 8 without the tricks listed in this post.

The sample project with all the modifications described in this post is available on GitHub. Go ahead and import that to your IDE and

Start your own GWT 2.8 adventure!

Community Spotlight - September 2016

Do the words JProfiler or Install4j sound familiar to you? Well, they are both popular products developed by ej-technologies and for this month’s Community Spotlight, I had the pleasure of talking with one of its founders, Ingo Kegel. Ingo and his team used Vaadin to develop the front end of their new product, Perfino, a promising JVM monitoring tool for production servers. Ingo is also a very active member of the Vaadin Community, having published a couple of add-ons, one of them recently merged into the core of Vaadin.

ingo.png

Hello Ingo, it’s great to talk with you! I was really looking forward to it.

Me too! My Vaadin-based monitoring tool Perfino 3 has been released last week and I'm ready to talk about it and my general experience with Vaadin.

Congrats! I played with the demo and the UI components on it look familiar to me… what can you tell us about it?

Screen Shot 2016-09-26 at 13.11.37.png

Indeed! Vaadin is a very good fit for the Perfino UI which falls into the "admin UI" category. There is a lot of data in the backend in our case and the easy incremental delivery of data to the browser makes it very performant for large tables. Perfino is a relatively new tool but it's now reached a mature state in version 3. We've used the experiences of our first customers to improve the tool and we're really confident that Perfino delivers excellent value. It's very easy to set up, has extremely low overhead and a really simple and transparent licensing scheme.

What kind of technologies are you “mixing” with Vaadin in Perfino?

Perfino has a couple of separate parts. The most important part of Perfino is the agent which does not have any third-party dependencies apart from ASM. The collector is totally separated from the UI, and its most important external technology is a database. In the UI server we do not use any frameworks except for Vaadin. One important external client-side component is yFiles for displaying call graphs, which I integrated as a Vaadin Javascript component.

Would you say that development is simpler when your UI code is next to your backend code?

In a sense, the UI code in Vaadin is both frontend and backend code at the same time, so yes, eliminating the transport layer between browser and server is priceless in terms of developer productivity. Our real backend is the collector which is not coupled to the UI, because it must be able to run in a separate process.

How do the frontend and backend communicate in Perfino?

Via RMI, but that's only optionally the case if the collector needs to run in a DMZ. Usually they run in the same process.

What about the persistence layer? What technologies do you use there?

Plain SQL. We need every extra bit of performance and we need total control over what is executed on the database. Persistence layers are great for applications with data from complex business domains, but not in our case.

Why did you decide to use Vaadin for Perfino?

I compared a lot of frameworks, mostly client side based ones. Vaadin seemed like a silver bullet for me in how it combined backend and frontend development into a single layer, so I went with it. I'm fluent in Swing programming so learning Vaadin was extremely easy. Mostly, my expectations have been met and I feel like the time for developing complex UIs is an order of magnitude shorter than it would be with some client-side frameworks. Of course there are drawbacks, but they are not especially significant for me. For example, when you want to "break-out" of the framework and extend it yourself with new client-side functionality, you have to understand the orchestration that goes on behind the scenes. But if you go with what the framework offers, you really don't have to do that.

And in fact, you indeed digged into the code and now are a committer of the Vaadin framework itself. What’s the story behind this?

Well... nearly every web application needs a login form and I rely on the browser to save my user credentials and auto-fill the form for me. With Vaadin, this was not so easy. When you click on a button, the interaction goes through a server-side loop and the browser does not see a direct submit of a form. Vaadin had a special login form component before, but then modern browsers became more restrictive and it stopped working and eventually it was deprecated. So I decided to develop my own login form component as an add-on. A couple of Vaadin versions later, that add-on was merged into the core in place of the deprecated component.

Awesome! It was a pretty popular add-on with more than 20.000 downloads and now available out-of-the-box. I bet you received a lot of positive feedback.

The user feedback was very helpful in getting it work in all kinds of different situations. As a single developer you sometimes only test things in one way - for example, I always closed the auto-complete drop-down with the enter key, but the tab key did not work for auto-completion, as another user pointed out. So this open development benefits my users, as well as everybody else.

Yes, that’s one of the advantages of having an active community in open-source projects. Vaadin has been around for more than 15 years already, but what’s your personal view of the future of Vaadin in contrast with pure client-side frameworks?

Well, I don't see how advances in client-side-only frameworks could threaten Vaadin. And with its web components strategy, Vaadin seems to have an interesting angle for breaking into the client-side only development. I'm personally looking forward to the immensely improved data-binding in Vaadin 8 and I hope that Vaadin will continue to work on the Grid component and add lots of features to it, for example hierarchical support.

Well said! Thank you Ingo not only for your contributions to the Vaadin framework but also for sharing your thoughts in this interview. Best wishes with Perfino and your future projects!

Thanks a lot Alejandro! Bye!

Vaadin community survey - learn more about our users!

Vaadin today has an active community of over 150 000 developers, which is why it’s vital for us to know more about you so we could serve you better. In order to do this, we ran a community survey in August with over 15 questions. Over 250 of you answered so let’s have a look at what you said.

Part I: User & company profile

What best describes you?

This is a crucial question for understanding the priorities and challenges of our users. The majority of you are Software Developers (49%) and Architects (32%), responsible for the technology decisions and implementation of new features in your projects. The rest 19% are made up of Designers (8%) that are in charge of the look and feel of the product’s design, and Managers (6%) that are responsible for the coordination and success of the product. Overall, this spread of roles is what we would have expected, as our community is heavily made up of developers and technical people.

PersonType.png

What best describes the company you work for?

This question has been asked in two parts: what is the industry and the size of the company that you are working for.

Let’s start with the company size. As it can be seen below, almost one in three respondents run a Startup company, taking 35% of the share. The second place was shared between Small companies (22%), Mid-size companies (23%) and Large companies (20%). It is great to see a diversity like that among Vaadin users as it proves that Vaadin fits both smaller and larger companies in different stages.

CompanySize.png

The second part of the question covers the company’s industry. It has been challenging to segment our respondents based on the industry, because nowadays many companies have two (or more) areas as their core competences, e.g. IT and Healthcare. As it can be expected, the majority (77%) of our respondents are working in Computer software industry, either making ready-made software solutions for other companies or performing consulting and building software on demand. Those companies are building software solutions for different industries, including Banking & Finance, Healthcare, Public sector, Logistics & supply chain, Retail, Telecommunications and other. It was excellent to see a confirmation that Vaadin is suitable for all companies of different sizes and industries.

Type-3.png

With this background info about you, we wanted to know more about your technology stack as well.

Part II: Technology choice

Which JVM language do you use most often?

As it can be seen below, Java is leading over other JVM languages, taking up 96% of the total vote. Groovy and Scala are responsible for 2% and 1% of the votes respectively. Kotlin and many others contribute to the remaining 1%. This was somewhat a surprise to us – might it be that plain-Java users are just more eager to answer surveys? :)

Language.png 

Which Java version do you use?

We can see that 74% of the respondents stated that Java 8 is used to run their main production applications. 21% of the respondents are on Java 7  and the rest - 5% are using Java 6. Java 8 really is the way to go when going forward.

JavaVersion.png

Which IDE do you use most often?

According to the survey, Eclipse is still the most popular IDE among the Vaadin respondents, taking 60% of the vote. Next in line is Intellij that is used by 29% of the users. NetBeans, as the last of the bunch, still has a solid 11% of the votes.

It’s also nice to notice that the Vaadin Plugin for Eclipse is used by 40% of Eclipse users. One of you mentioned Vaadin Designer inside the plugin as a reason to its popularity: “The plugin for Eclipse is so simple and intuitive that I was able to develop the layout of complex applications in minutes”.

These results are different from a recent JRebel survey (Java Tools and Technologies Landscape Report 2016). According to their studies, IntelliJ is the number one IDE (taking 46% of the votes) for Java developers for the first time. We suppose that it might be because Vaadin has supported the Eclipse plugin for a longer period of time.

IDE.png

How is your backend developed?

Front-end and back-end development work in tandem to create an application for users. That’s why it’s important for us to learn how the backend of an application is done in each case. As it can be seen below, Java EE is leading over other ways of development, taking up 41% of the total vote. Spring is used in 31% of the cases. The rest 27% includes a custom-made backend and other options.

Backend.png

Part III. Comments & suggestions

Would you recommend Vaadin to you friends or colleagues?

It is very essential for us as a company to understand how our users are perceiving Vaadin and if they would recommend it to their friends and colleagues. We asked this question using the NPS (Net Promoter Score) scale, where 1  is very unlikely and 10 is very likely. We're happy to see that as many as over 82% of you gave Vaadin Framework a 7 or higher!

Your feedback to Vaadin

It was superb to receive so many comments and suggestions in our last section - feedback to Vaadin. It was pleasing to see that many Vaadin users are positively motivated about Vaadin. Here are some quotes:  “As a Java guy I consider Vaadin to be the best Java web framework at the moment. It's pros are elegant UI design (themes) and clear and evident approaches behind everything” or as another one of you puts it “It's simple and productive… Today I start the project scribbling on paper and within minutes already have an application running in the browser. This was certainly the greatest motivation of technical leaders to adopt the framework.

While it was great to have such a positive feedback, we also received a lot of improvement ideas and suggestions. Some users were proposing to have more “out-of-the-box” examples and tutorials. Others were recommending to have additional tutorials for different IDEs, such as IntelliJ and Netbeans. A few respondents mentioned that Vaadin’s public roadmap should be more transparent with a clear explanation of the company’ priorities and future steps.

There were many other priceless comments that will be taken into consideration. You’ll hear something about all of the mentioned things very soon!

Once again, we are extremely grateful for your contribution, your honest information, and if you still haven’t filled in the survey, please do so now at vaadin.com/survey