I have uploaded my slides to slideshare.net:

The problem is: too many tools that don’t seem to like each other fighting over project layout and classpath. Java EE packaging specs and GWT specialities coming from DevMode don’t really make things easier. If you were not a pro in all of this, you ended up with a mess. I have seen it too often.

Since m2e integration things started getting better. And finally, using recent versions from the following official update sites, it started working flawlessly. Even the DevMode/ classpath issue that made us patch the Jetty launcher past year is solved!

I’ll try to keep this posting here up-to-date, so you won’t have to read through all the docs, tips, tricks comments from here and here again and again.

What you need:

• m2e – maven integration for eclipse

  http://download.eclipse.org/technology/m2e/releases

• m2e-wtp – maven Integration for WTP

  http://download.eclipse.org/m2e-wtp/releases/

I am using the latest stable releases from eclipse.org. Well, not always, I am going as stable as possible: the actual wtp integration is still in incubation… but works…

Talking numbers, this are the version numbers I used here:

• m2e – Maven Integration for Eclipse 1.2.0.20120903-1050
• m2e-wtp – Maven Integration for WTP (Incubation) 0.16.0.20120914-0945
• m2e connector for mavenarchiver pom properties 0.15.0.201207090125-signed-201209140800

I have installed a few m2e connectors I required for other non GWT projects, I think they are not needed for a GWT project. Just for the curious:

M2E connectors are a bridge between Maven and Eclipse. When a maven plugin is bound to a lifecycle phase like generate-sources, or process-sources it becomes a part of Eclipse build. (source)

Don’t use the archetype. And if you do, remove the maven-war-plugin plugin. I am using the copyWebapp configuration option in the gwt-maven-plugin to copy the

src/main/webapp

stuff into the folder used by the DevMode and build system located at 

${project.build.directory}/${project.build.finalName}

.

<build>
    <plugins>	
      <!-- GWT Maven Plugin -->
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>gwt-maven-plugin</artifactId>
        <version>2.5.0</version>
        <executions>
          <execution>
            <goals>
              <goal>compile</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <runTarget>index.html</runTarget>
          <gwtSdkFirstInClasspath />
          <copyWebapp />
          <extraJvmArgs>-Xms128m -Xss1M -Xmx512m -XX:MaxPermSize?=512M</extraJvmArgs>
        </configuration>
      </plugin>

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>2.3.2</version>
        <configuration>
          <source>1.6</source>
          <target>1.6</target>
        </configuration>
      </plugin>
    </plugins>
  </build>

By the way, defaults work fine now, there is no need to setup/ fix the path configs for the plugin anymore. If you use M2E to update the project configuration things will work.

If you are sure your config is right, and you are absolutely sure you have at least the versions mentioned above, try killing your eclipse config with

mvn clean eclipse:clean

This will leave you with a completely missconfigured project in eclipse. Let m2e update the project again. Sometimes I get the error that m2e did fail setting up the project description. Ignore it, do it again.

Talking about GWT is always fun. Thanks to all participants for the great feedback.

First, add the guava.jar and the guava-gwt.jar libs to your project. If you are using maven, just add the following dependency to you pom.xml:

<dependency>
   <groupId>com.google.guava</groupId>
   <artifactId>guava-gwt</artifactId>
   <version>12.0</version>
</dependency>

For Ivy or Gradle, just have a loot at here.

Once the libs are in your classpath, you can inherit the required modules in your GWT module:

<inherits name="com.google.common.base.Base"/>

<inherits name="com.google.common.math.Math"/>

<inherits name="com.google.common.primitives.Primitives"/>

or, as in my case, just add

<inherits name="com.google.common.collect.Collect"/>

which does all of the above…

I am not going into all the guava goodies here, but…

if (!Strings.isNullOrEmpty( somebean.getSomeProperty() )) {
      ...
}

.box {
}
@if user.agent safari gecko1_8 {
	.box {
		border-radius: 10px;
	}
}
@if !user.agent safari gecko1_8{
	.box {
		background-color: grey;
	}
}
@if user.agent safari {
	.box {
		background: -webkit-linear-gradient(top, rgba(247, 134, 18, 0.4) 0%,
			rgba(250, 250, 250, 0.5) 23%, rgba(200, 200, 200, 0.7) 30%,
			rgba(247, 134, 18, 0.9) 40%, rgba(247, 134, 18, 0.5) 100% );
	}
}
	
@if user.agent gecko1_8 {
	.box {
		background: -moz-linear-gradient(top, rgba(247, 134, 18, 0.4) 0%,
			rgba(250, 250, 250, 0.5) 23%, rgba(200, 200, 200, 0.7) 30%,
			rgba(247, 134, 18, 0.9) 40%, rgba(247, 134, 18, 0.5) 100% );
	}
}

detailTabs.addSelectionHandler(new SelectionHandler<Integer>() {
            @Override
            public void onSelection(SelectionEvent<Integer> event) {
                Widget w = detailsTabs.getWidget(event.getSelectedItem());
                if (w instanceof RequiresResize) {
                    ((RequiresResize) w).onResize();
                }
            }
        });

Coding HTML in a custom cell means writing HTML in Java code, and while it is possible, it is not very readable. The code is hard to read and hard to maintain. Wrapping css, js and html in Widgets is quite heavyweight, but it enables a certain level of software engeneering on the java side. With the cell widgets it changed in favor of performance – and in my opinion it was a fair trade: we needed an efficient data grid.

The first remedy for the HTML and CSS pain with the cell widgets came with the SafeHTMLTemplates. SafeHtmlTemplates did a good job helping here and there, here is an simple Example:

interface MyTemplate extends SafeHtmlTemplates {
        @Template("<span style="0cursor: pointer; text-decoration: underline; padding-left: 5px;">{0}</span>")
         SafeHtml withFileName(SafeHtml fileNameSafeHTML);
    }

Another nice example (where I do copy and past from), comes from the IconCellDecorator from the toolkit itself. For “small” or “simple” cells, SafeHtmlTemplates will continue to be my favorite approach. But when it comes down to more complex cells, the new UiRenderer approach is better.

One drawback with the SafeHtmlTemplate approach is that it is cumbersome to catch specific events on the rendered cell. Since the cell is not a Widget, you cannot register DOM event handlers. This changes a little with the new UiRenderer, as shown on the next example.

So here is a more complete example of how to use an UiRenderer to shape a custom cell. This is quite cutting edge, and the API is likely to change. The example below works with GWT 2.5 RC1. The actual 2.5 RC documentation seems to be a little out-dated, it took me a little try-and-error to get it working.

This is the UiBinder like markup for the layout of the cell. Did you notice the “fileName” trick? You declare what the cell will need with the “<ui:with field” element, and use it later with “<ui:text from”…

<!DOCTYPE ui:UiBinder SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent">
<ui:UiBinder xmlns:ui="urn:ui:com.google.gwt.uibinder">
	<ui:with field='filename' type='java.lang.String' />
	<ui:style>
		.fileName {
			cursor: pointer;
			text-decoration: underline;
			padding-left: 5px;
		}
	</ui:style>
	<div>
		<span ui:field="fileNameSpan" class="{style.fileName}">
			<ui:text from='{filename}' />
		</span>
	</div>
</ui:UiBinder>

public class FileNameCell extends AbstractCell {

    private static CellBinder cellRenderer = GWT.create(CellBinder.class);

    interface CellBinder extends UiRenderer {

        void render(SafeHtmlBuilder sb, String filename);

        void onBrowserEvent(FileNameCell cell, NativeEvent e, Element p, ValueUpdater valueUpdater, FileDTO n);
    }

    public FileNameCell() {
        super("click");
    }

    @Override
    public void onBrowserEvent(Context context, Element parent, FileDTO value, NativeEvent event, ValueUpdater valueUpdater) {
        cellRenderer.onBrowserEvent(this, event, parent, valueUpdater, value);
    }

    @Override
    public void render(Context context, FileDTO file, SafeHtmlBuilder sb) {

        cellRenderer.render(sb, file.getName());

    }

    @UiHandler("fileNameSpan")
    void onFileNameGotPressed(ClickEvent event, Element parent, ValueUpdater valueUpdater, FileDTO name) {
        valueUpdater.update(name);
    }

}

This is very promising!

But how do we change the styles? Simply subclass the client bundle, replace the images/ styles partially or completely, and they give it to the cell widget.

Here is a small example:

interface TableResources extends DataGrid.Resources {
    @Override
    @Source(value = {DataGrid.Style.DEFAULT_CSS, "DataGridPatch.css"})
    DataGrid.Style dataGridStyle();
  }

Now, you have to create the cell table:

@UiField(provided = true)
DataGrid<Company> table;
(...)
table = new DataGrid<Comapany>(numRows,
        GWT.<TableResources> create(TableResources.class));
(...)

It’s basically a new API for GWT that is “to the metal”. It is not hand written, but completely generated by the W3C machine readable IDL specs which are used by Chrome and Firefox to implement the C++/Javascript API bindings.This means GWT will have 100% feature parity with hand written JS. There will be no API not exposed. In fact, even experimental stuff like MouseLock, Web Components/Shadow DOM and Web Intents is exposed. And of course, Typed arrays, WebGL, WebAudio, WebSockets, WebRTC, WebWorkers, and pretty much everything else.

I am using the selection model and the data list provider to do the selection magic.

May not work for everyone….

And here is my custom header:

public final class CheckboxHeader extends Header {

	private final MultiSelectionModel selectionModel;
	private final ListDataProvider provider;

	public CheckboxHeader(MultiSelectionModel selectionModel,
			ListDataProvider provider) {
		super(new CheckboxCell());
		this.selectionModel = selectionModel;
		this.provider = provider;
	}

	@Override
	public Boolean getValue() {
		boolean allItemsSelected = selectionModel.getSelectedSet().size() == provider
				.getList().size();
		return allItemsSelected;
	}

	@Override
	public void onBrowserEvent(Context context, Element elem, NativeEvent event) {
		InputElement input = elem.getFirstChild().cast();
		Boolean isChecked = input.isChecked();
		for (TYPE element : provider.getList()) {
			selectionModel.setSelected(element, isChecked);
		}
	}

}

Entstanden sind zwei Instrumente, die für uns GWT-Interessierte relevant sein könnten: zum einen geht es um eine Studie, die im kleinen Kreis den Einsatz von GWT in deutschen Unternehmen dokumentiert, zum anderen geht es tatsächlich um eine Liste mit Unternehmen, die GWT einsetzen.

OIO Kompass : Java Web-Frameworks

Im letzten Jahr habe ich in Zusammenarbeit mit der Firma Orientaion in Objects, Mannheim, im kleinen Kreis eine Umfrage zu den Hintergründen der Auswahl von Java Web-Frameworks im deutschsprachigen Raum durchgeführt.

Die Studie, die wir kürzlich veröffentlicht haben, beruhte auf 50 Entscheidungen. Von diesen Entscheidungen waren ca. 250 Entwickler und 200 Projekte betroffen. Genug, um eine erste Studie zu veröffentlichen. Die Studie kann auch als PDF geladen werden.

Unter dem reisserischem Titel Java-Frameworks: Zweikampf zwischen JSF und GWT hatte unsere kleine Studie einen kleinen Auftritt in den Medien.

Und somit ist auch die zweite Runde eingeleitet: mit einem überarbeiteten Fragebogen wollen wir die Studie nochmal im großen Kreis durchführen.

Hier geht es direkt zur aktuellen Umfrage.

Für die Beantwortung der Fragen veranschlagen wir rund 10 bis 15 Minuten:

GWT Referenzliste

In den letzten Jahren wurde ich unzählige Male danach gefragt, welche Unternehmen GWT einsetzen würden. In diesem Kontext ist eine kleine GWT Anwendung entstanden, in der sich Unternehmen anmelden können, die GWT im Einsatz haben.

Inzwischen sind 80+ Unternehmen eingetragen, darunter 20++ aus Deutschland und 20++ aus den USA.

Die Liste ist öffentlich zugänglich, die Kontaktdaten werden nicht veröffentlicht (dienen nur für Rückfragen und Verifizierung). Optional können ein paar Angaben zum Kontext gemacht werden, daraus entstehen die netten Statistiken, die ebenfalls öffentlich zugänglich sind.

Mit ein bisschen Hilfe können wir sicherlich die Anzahl der deutschen Unternehmen in der Liste deutlich erhöhen. Für die Registrierung werden keine 5 Minuten veranschlagt…

Als Java-Entwickler ist man nicht selten Webentwickler. Über einen ungewöhnlich langen Zeitraum haben sich die Technologien um einen herum kaum geändert: Das W3C hat sich in Bezug auf HTML lange seitwärts, insgesamt im Kreis, aber praktisch kaum bewegt, der Browserkrieg schien gewonnen und mit den Java-Webframeworks waren wir im Großen und Ganzen recht zufrieden.

The Web 2.0 Toolkit

Das Google Web Toolkit ist eine Sammlung von Werkzeugen und Bibliotheken für die Entwicklung von JavaScript-Anwendungen. Das Toolkit wird sowohl intern von Google als auch weltweit in vielen Projekten eingesetzt. Das Besondere an GWT ist die Vorgehensweise: Ein Compiler liest Java-Quellen ein und generiert JavaScript. Somit können Java-Entwickler auf bestehendes Wissen, Erfahrungen und Werkzeuge aufsetzen. Allerdings hat GWT nicht den Versuch unternommen, das gesamte JDK und Swing im Browser zu unterstützen. Die JDK-Unterstützung ist fragmentarisch (nicht alle Klassen können verwendet werden), und GWT liefert ein eigenes, an HTML orientiertes
UI-Komponentenmodell.

Der komplette Artikel von Benjamin Bart (Orientation in Objects GmbH) und Papick G. Taboada (pgt technology scouting GmbH)  kann im PDF nachgelesen werden und stammt aus der Ausgabe 2.12 des Eclipse Magazins.

In GWT we did something like that to cancel the backspace back navigation:

Event.addNativePreviewHandler(new NativePreviewHandler() {
    @Override
    public void onPreviewNativeEvent(NativePreviewEvent event) {
        if (event.getNativeEvent().getKeyCode() == KeyCodes.KEY_BACKSPACE) {
            if (event.getNativeEvent().getEventTarget() != null) {
                Element as = Element.as(event.getNativeEvent().getEventTarget());
                if (as == RootPanel.getBodyElement()) {
                    event.getNativeEvent().stopPropagation();
                    event.getNativeEvent().preventDefault();
                }
            }

        }
    }
});

First, there is Google:

„AdWords, AdSense, Flights, Hotel Finder, Offers, Wallet, The New Blogger, Chrome Webstore, Product Search, Public Data, New Google Groups, Orkut, Google Takeout, Google Pagespeed, Google WebFonts, Google Tables, Google Health (discontinued), Google Wave (discontinued), PlayN (basis of Angry Birds)“

And now, online, there is a public reference list of companies using GWT:

http://gwtreferencelist.appspot.com/

There you will find the company list, some fancy charts and the “register company” form. Using GWT and not on the list? Please register!

But this time, the team posted several comments on whether GWT is dead or not (mainly because of the fuss around Dart), and Ray Cromwell posted a comment providing some insight on what is coming on GWT 2.5:

The next release or two of GWT may include more core improvements than the last few point releases of GWT so far, consider:

1) Compiler optimizations that reduce code by size by 30% uncompressed, and 15% gzipped
2) SourceMap support and Source-Level Java debugging in Chrome (and hopefully Firefox)
3) A „super draft mode“ that can recompile many apps in under 10 seconds and most under 5
4) New „to the metal“ „modern browser“ HTML bindings
5) Testing framework that makes GUI testing delightful
6) Incremental compile support to speed up production compiles

So code will be getting smaller, faster, easier to debug (in some situations) and test, and compiles will go quicker. This reflects somewhat the shift in GWT team composition, but as people ramp up on other parts of the SDK (e.g. MVP stuff), I’m sure there will be improved responsiveness to fixing bugs in that area as well.

Add this to the list of issues already fixed and scheduled for 2.5, and we will have a really interesting release.

Oder direkt hier: http://bit.ly/gwt-jsf-wahlomat

It was a very interesting evening, great feedback and nice chatting afterwards. Recapping, we had a talk on RAP, the Canoo RIA thing, Silverlight and Qooxdoo. I jumped in with my talk on GWT, my third slide says: “GWT is better”:

Here are the slides I used in the VKSI sneak preview “RIA Entwicklungsplattformen im Vergleich“.

Many companies are still stuck in – IMHO – the most successfull vendor-version lock-in web history. Ever heard this?

I cannot upgrade IE in our company because of  (…)*

(*) You can fill in you favorite corporate intranet application that won’t work elsewhere, only in IE6.

And even if you can upgrade IE to the latest version (actually IE8), it won’t get much better. Chrome, Opera, Firefox and Safari – pic anyone and you will see that the RIA in question can be fast.

And here is where Google comes to the rescue. In a recent blog posting, the Chromium declared that “chrome is ready for business“:

Both Chrome and Chromium are now manageable through Group Policy objects on Windows, plist/MCX configuration on Mac, and special JSON configuration files on Linux. We polished up the NTLM and Kerberos protocol support, and created a list of supported policies and administrative templates to help administrators deploy.

This is good news for companies willing to switch from IE to chrome, but for those sticking to IE we still have the nochrome-vendor-version lock-in. And this is the greatest problem: how do you switch to a modern browser, if you must run several applications in IE? The answer is simple: you switch the rendering engine inside IE, but not for all applications, just for those explicitly asking for it:

For users needing access to older web applications not yet qualified for Chrome, we also developed Chrome Frame, an Internet Explorer (TM) plug-in that provides Chrome-quality rendering for the broader Web, while defaulting to host rendering for any web applications that still require IE.

This way, IE will work as always, but if some page adds a simple html or http header, google chrome will do the rendering of the page, inside IE. Users don’t have to switch from one browser to another, and the IT department can rollout one web application upgrade after another, without compromising legacy apps.

You could even use a proxy with content adaptation to add the required http header to all pages from the internet.

I mean, really, even Microsoft says you should upgrade:

Microsoft’s urging to upgrade to IE8 appears to be partially in response to the German and French governments’ recommendation that people stop using Internet Explorer altogether due to its security vulnerabilities.

Microsoft’s announcement said: “It is important to note that all software has vulnerabilities and switching browsers in an attempt to protect against this one, highly publicized, but currently limited attack can inadvertently create some false sense of security. Moreover, IE8 has other built-in security protections, such as the SmartScreen filter, that other browsers do not have that protect against real consumer threats, such as socially engineered malware and phishing attacks.”

My first though is, what exactly is meant with “standard”?

A short look at Wikipedia shows:

Open Standard: An open standard is a standard that is publicly available and has various rights to use associated with it, and may also have various properties of how it was designed (e.g. open process). There is no single definition and interpretations do vary with usage.

De facto standard: A de facto standard is a custom, convention, product, or system that has achieved a dominant position by public acceptance or market forces (such as early entrance to the market). De facto is a Latin phrase meaning “concerning the fact” or “in practice”.

Internet standard: In computer network engineering, an Internet Standard (STD) is a normative specification of a technology or methodology applicable to the Internet. Internet Standards are created and published by the Internet Engineering Task Force (IETF).

No, no,  no! Not that kind of standard, right? Ah, ok, the Java EE standard!

Again, looking at Wikipedia you will find the following under “nomenclature, standards and specification“:

Java EE is defined by its specification. As with other Java Community Process specifications, providers must meet certain conformance requirements in order to declare their products as Java EE compliant.

Java EE includes several API specifications, such as JDBC, RMI, e-mail, JMS, web services, XML, etc., and defines how to coordinate them. Java EE also features some specifications unique to Java EE for components. These include Enterprise JavaBeans, Connectors, servlets, portlets (following the Java Portlet specification), JavaServer Pages and several web service technologies. This allows developers to create enterprise applications that are portable and scalable, and that integrate with legacy technologies.

Which leaves us just a few options: the Servlet/ JSP and the JavaServer Faces specifications. While the Servlet and JSP specifications focus on how to handle HTTP request/ responses, the JSF specification defines a GUI component model for web applications.

The problem here is: there is no room anymore for another “compliant” web framework – JSF made it into the Java EE specification – end of line. But, despite of a wide industry support, JSF is not the only web framework being used today by Java developers. And to make things a little more trickier, typical Web 2.0 web applications do not render the UI on the server side but in the browser.

Fancy “Web 2.0″ applications are not written in Java. Rich user interfaces are being rendered completely in the browser, avoiding the server roundtrip and minimizing latency. How? By simply using DHTML (technologies defined by the W3C).

So is this the end of Java? No! You will find people using Java backends for “Web 2.0″ applications. But even as a backend technology we won’t be abiding by the rules of standard compliance by using RMI or SOAP to communicate: it is common to send lightweight JSON over HTTP. All you need for that is a Servlet and a little bit of JSON <-> Java objects mapping. People developing RIAs and using JSON back and forward to the server are measuring latency in milliseconds.

So, if you will be building a Web 2.0 application, don’t look for a specification at the Java EE side. It is the wrong side, as Java is actually the backend, not the frontend. That brings us back to the first standards I cited above: open standards, de facto standards and internet standards.

This is how things were before JSF, and this is how things became after Web 2.o.

So, back to the question, is GWT standard compliant or not? Well, besides of those blue boxes on the picture above I would say yes!

• The compiler is not standard, but I would not know what a standard compiler would be or mean to development anyway
• The GWT-RPC mechanism is highly GWT proprietary, don’t use it if you don’t like it. But it is my belief that there aren’t too many developers out there that can code something better than GWT-RPC by hand…