My grandfather used to say: “Makkelijker gezegd dan gedaan” (easier said then done). So when I talked about how HTML5 could be the new platform in-depended development paradigm, in this previous post, I better come with some real world examples instead of only saying it.

So that is exactly what I’ve been doing. My wife is a bit of an apple fan woman. And she has a book that she would like to publish. She couldn’t find a publisher, so the next best thing would be to put her book on an iPad, but you still need an publisher to put something on the iBook store and publishers are still stuck in the dark ages. So we’ve decided to make an application out of her book. Now I’ve written some objective-c code before and I must say it wasn’t the best experience I’ve had. Xcode at that time was awful, it was like writing software 10 years ago. So I started to look for alternatives. It could be a simple html page, but how to create a native iPad application out of that?

I’ve found something that I’m really exited about. Playn is a cross-platform game abstraction library for writing games that compile to multiple platforms one of these is html using gwt. Now if I use this in combination with phonegap then I can create a iPad app that can also run on android based pads. Not only that I could make it interactive add a game to the book and best of all do it in Java.

If you think about it, for companies this makes a lot of sense. Unless your companies key platform is iOS, having developers in-house that have objective-c knowledge is expensive. Also hiring external company to build an iPhone app is expensive and they have to work together with you to integrate your existing architecture. So having something like this where one can use existing knowhow to create a android and iPhone solution that works on both platforms is a huge cost saver.

Opinions expressed in this post are totally my own and not necessarily that of my employer.

Wednesday started with the infamous “scriptbowl”, a competition between various scripting languages. This year the contenters were JRuby, Groovy, Scala, and Clojure. I wondered whether Scala considers itself a scripting language but obviously they either do or just seek the opportunity to be on stage.

To keep a long story short: Groovy has won this event for the third time in a row! This year the race was tied with Scala. Guillaume presented Groovy in the typical Groovy-idomatic style and explained every single line of his concurrent visual analyzer for Google+ postings. Dick Wall presented only non-idomatic Scala code. I interpret this as: to make Scala appealing you have to make it look like Groovy. Furthermore, he presented Kojo, which is a great interactive learning environment written in Play/Scala. In contrast to all other presentations, this was not specifically created for the scriptbowl, nor was it written by the presenter, nor was it clear how much effort went into it, nor did the audience see a single line the implementation code. How much this skewed the comparison, I leave to everybody’s judgement. The show was good, though.

I felt a bit sorry for Clojure. It is a great language and deserves a presentation that is more visually appealing to convince the crowd.

Afterwards, I attended a hands-on lab for “rapid enterprise development with netbeans”, which was essentially creating a Swing app for database CRUD actions. If I remember correctly, I did the exact same task 1997 with JBuilder. It left me with the feeling of “Yes, it works” but it is not less complex than it was 13 years ago.

Early afternoon Gerrit Grunwald (better known as @hansolo_) presented his work on simplified custom components for Swing. Given that he speaks about an activity that is both utterly important and highly underadvertised he would really deserve speaking at the center stage.

Graeme Rocher’s great session about Grails, polyglot datastores (hibernate, jpa, redis, mongodb, …), and the cloud was overshadowed by the news that Steve Jobs has died. Accidentally, the demo application was about showing a BBC News stream, which displayed this information live on stage. Both the presenter and the audience were equally touched.

The day officially ended with a big event at treasure island. I decided to not go there, though, and meet the former Canooey Denis Antonioli in Berkely where we had a great evening.

Dierk Koenig

Finally, late in the evening I joined Dan Sline’s talk on WebServices in the Groovy space. The major take-away for me was a repercussion of the well-known advice: “keep it simple”.

Throughout the day, a lot of people approached me to tell how much they liked my talks yesterday. That was a really nice experience. Last year I had the very last talk of the conference and only this year I recognized how much of a difference the scheduling of the talks make.

Dierk Koenig

This is gonna be a short series about my impressions of JavaOne 2011.

As always, it is nice to see the town decorated for the event, even though Oracle World gets certainly much higher attention. So the immigration officer as well as the nice guy sitting next to me on a bench at Union Square ask “ah – you are a programmer? Are you here for Oracle World?” “Hmpf…”

Should you ask yourself “what’s in for me”? Here is a first answer: the conference material

The bag is not very practical for a software developer. I guess the selection has been taken by an Oracle employee who assumes that their conference attendees never carry any material themselves in the first place (which may be true for OracleWorld). The jacket is very nice, though.

And, yes, you can rate conference organizers by the badges they produce. Hey, that should not be too difficult, right? Here is what you still can make wrong:

• Printing the delegate’s name so small that it is hardly readable from more than 20 cm away. Now since the badge usually hangs at belly height (if not lower) this can be a bit embarrassing for both involved parties.
• Second, the name belongs on both sides of the badge! Really! How often did you try to read the name only finding that the badge hangs the wrong way around?

Otherwise, the waiting time was not too long. The speakers registration was actually empty when I arrived. The attendees registration was pretty well filled, though. But then everybody has to go to the material pickup which was for me in Moscone West 3rd floor where I waited in line for about 20 minutes and I was very early and the queue grew much longer afterwards.

This made me think about my latest work on highly concurrent producer-consumer scenarios (http://people.canoo.com/mittie/kanbanflow.html) and what it would need to improve the situation.

Otherwise, from studying the program schedule, I found that Oracle has wisely chosen to pretty much always put two Groovy-related talks in parallel as if to make sure that nobody can escape the Groovy (\G) in these time-slots.

I’m eager to see what the week will bring.

Dierk Koenig, @mittie

We’ve all being there, we’ve all had this on a project once or maybe even more times. The assignment is to build an application, but there is no data for you to work with. There could be any number of reasons this could be the case to name a few, the web-service that should be connected is not done in time, the database migration is postponed. Then someone has to create database scripts with test data, or implement a test web-services. This is all a waste of time.

But lucky for you now there is a solution.

I’ve created an little test data framework that is easy to setup and will create test data automatically. So how does it work? Simple, its entry point is a method interceptor that you can wrap around anything you want, it doesn’t even have to be an implementation. So that DAO you want to use, but the database is still empty, just let the framework step into place and all the methods return the data that you want.

It can also be handy to create test data for you unit test. You need to test if you bean serialization works, or want to put an entity into a in memory database with dbunit. Just call the framework with you bean class and the framework will return an instance filled with test data. It will read the existing annotations that you have on your entity bean an will only generate data that is valid for you bean.

Here is an example of how it works:

 //Create an instance of the Employee class and fill it with test data.
 Employee employee = TestData.createBeanInstance(Employee.class);

 //Annotations that restrict the data for first name are recognized.
 assertNotNull(employee.getFirstName());

To create a service that returns test data on it’s service methods:

 //create a instance of the service class/interface that will return test data
 Service exampleService = TestData.createService(Service.class);

 //this now returns a list of employee instances that are filled with test data
 List<Employee> employees = exampleService.findByName("name");

Create a dbunit xml file:

 //create a file
 File fileLocation = File.createTempFile("file", ".xml");

 //populate the file with test data for the employee
 TestData.createDBUnitDataSet(Employee.class, fileLocation);

To give it a spin add the following into you pom.xml

     <dependency>
         <groupId>ch.nerdin</groupId>
         <artifactId>testdata-framework</artifactId>
         <version>0.10</version>
     </dependency>

So nothing holding you back to make your data driven test easier to setup, or to stub out you migration points. I’m hosting this code on github so if you have issues, comments or even better contribute please do so.

The future of computing lies in mobile computing, more and more devices come on the market, tablets and phones that will connect through the Internet as technology is getting cheaper and wifi and 3g more common. That means our software will also need to run on these handheld devices, because our clients will want their services on all platforms. This is what Java set out to do 15 years ago, so that we have the ability to write software once and run it everywhere. The problem is these new platforms, that I believe will make up a large part of the future have, until now, no Java. It would be great if we can find something that will give us the ability to write our software only once.

I believe that the technology that is going to deliver us this promise is called HTML5. More and more applications will run inside you browser. I’m typing this article in google docs, which is a perfect example of how applications will evolve. No need to install anything or maintain up to date versions, even an operating system could be very minimalistic (google chrome). So Google is obviously sharing this vision, but also Microsoft is building it’s next version of office on something that is based on their web-browser.

Sadly the development language of HTML5 Javascript and not Java. Java has been around a long time and there are a lot of libraries that people have made. Would be cool if we can still use these, the answer is Googles Web Toolkit. GWT provides a way to code in Java and then translate that code into Javascript. This way we can still use all that great stuff that others made.

A good example of this future is Angry Birds, you have probably heard of this game. To create this game they have taken the java implementation of box2d called jbox2d and created a javascript version of that with the help of GWT. Once that is done you can use HTML5 Canvas to draw the Birds and calculate their positions if they are falling. Now because they have build it this way with HTML5 this game could also work on an iPhone, but even better because android is based on java you could create from this source a android version with only one line of code.

Have a look at some of the great things people are building with the HTML5, be sure that your browser supports it.

1. Drawing program deviantART
2. Old style game with new technology area5
3. Quake GWT HTML5 port

This screencast demonstrates the small language changes that are part of Open JDK 7, which is available from the Open JDK website. It demonstrates multi-catch, try with resources, strings in switch statements, underscores in literals, and the diamond operator.

If you have any issues watching the video below, then you may have better luck viewing it on the JetBrains.tv site.

I’ve made a lot of screencasts and blog posts over the years. If you like this, then there are many ways to see the other stuff I’ve done: 

• My main blog: http://hamletdarcy.blogspot.com
• My other JetBrains.tv posts: http://tv.jetbrains.net/tags/hamlet
• IDEA related posts on my blog: http://hamletdarcy.blogspot.com/search/label/IDEA
• My screencasts on YouTube: http://www.youtube.com/user/HamletDRC
• IDEA related Posts on my work blog: http://www.canoo.com/blog/tag/idea/
• Or follow me on Twitter: @HamletDRC

The screencast was created with Ubuntu 10.04, PiTiVi, Audicity, gtk-RecordMyDesktop, IntelliJ IDEA, and LibreOffice. OS from top to bottom.

Thanks for watching, and leave a comment!

If you read my series on GWT dependency injection (parts: first, second and third), maybe you remember that, in part 3, I mentioned how convenient would be to reduce the boilerplate required to define events in GWT. I also mentioned how elegant I find the event definition in CDI. Wouldn’t it be nice to have a lightweight event model like that in GWT?

Let’s see first how an event is defined and handled in CDI:

public class CDISample {
    @Inject
    private Event<String> event;

    public void handler(@Observes String payload) {
        System.out.println(payload);
    }

    public static void main(String[] args) {
        event.fire("Hello event world!");
    }
}

While exactly this is maybe not doable in GWT (at least not yet), what about something like this?:

public class GWTSample {
    @Inject
    private SampleEvent event;

    public void execute() {
        event.dispatchTo(new Handler<String>() {
            public void onEvent(String payload) {
                Window.alert(payload);
            }
        });

        event.fire("Hello event world!");
    }

    public interface SampleEvent extends Event<String> {
    }
}

public class PingEvent extends GwtEvent<Handler> {
    public static Type<Handler> TYPE = new Type<Handler>();

    @Override
    public Type<Handler> getAssociatedType() {
        return TYPE;
    }

    @Override
    protected void dispatch(Handler handler) {
        handler.onEvent(this);
    }

    public interface Handler extends EventHandler {
        void onEvent(PingEvent event);
    }
}

public interface PingEvent extends Event<Void> {}

• First, the events have the same payload type (Void in this case), and therefore we need explicit types to distinguish the ping event from the pong event. This also happens in CDI where we would define explicit payload types instead.
• Second, in this implementation we will be using GWT’s deferred binding and, during the code generation phase, we need to know the parametrized type. Because of Java generics limitations, for this last it is necessary to define a new parametrized type which captures the payload type in its type parameter (wrapper).

Did I convince you? If I did, let’s go on and see how to use deferred binding and dependency injection to achieve it.

Letting GWT generate the boilerplate

Deferred binding in GWT is a really powerful feature implemented in the GWT compiler to substitute class implementations depending in environment properties like the user agent. This way, while the developer has the illusion of using the same classes independently of the browser, the deferred binding mechanism allows to select the adequate implementation for each browser.

Far from being static, deferred binding allows to generate code on the fly by mean of a generator class. This happens when the developer invokes the “GWT.create()” method on an interface. For the operation to succeed, a generator for the interface must exist. This will be invoked during GWT compilation time and its result (one or more Java classes) will be compiled and linked into the resulting JS application.

To configure which generator should be used for which interface, it is necessary to add a new “generate-with” entry in the GWT module descriptor. In the case of the demo application, the following code has been added to the “PingPong.gwt.xml” file:

...
    <generate-with class="com.canoo.gwt.events.server.eventsfwk.EventGenerator">
        <when-type-assignable class="com.canoo.gwt.events.client.eventsfwk.Event"/>
    </generate-with>
...

The contents of the “Event” and “EventGenerator” classes are the following:

public interface Event<T> {
    public void fire(T payload);

    public void dispatchTo(Handler<T> callback);

    public interface Handler<T> {
        public void onEvent(T payload);
    }
}

public class EventGenerator extends Generator {
    private static final String EVENT_IMPL = "EventImpl";
    private static final CodeTemplate GWT_SIMPLE_EVENT_TEMPLATE = new GwtSimpleEventTemplate();
    private static final CodeTemplate EVENT_IMPL_TEMPLATE = new EventImplTemplate();

    @Override
    public String generate(TreeLogger treeLogger, GeneratorContext generatorContext, String typeName) throws UnableToCompleteException {
        TypeOracle typeOracle = generatorContext.getTypeOracle();

        JClassType parentEventType = typeOracle.findType(Event.class.getName());
        JClassType eventType = typeOracle.findType(typeName);
        JClassType payloadType = findPayloadType(eventType, parentEventType);

        String gwtSimpleEventImplName = generateGwtSimpleEvent(treeLogger, generatorContext, eventType, payloadType);
        String eventImplTypeName = generateEventImpl(treeLogger, generatorContext, eventType, payloadType, gwtSimpleEventImplName);

        return qualifyInGwtEvents(eventImplTypeName);
    }

    private static JClassType findPayloadType(JClassType eventType, JClassType parentEventType) {
        JClassType interfaces[] = eventType.getImplementedInterfaces();
        for (JClassType anInterface : interfaces) {
            if ((anInterface instanceof JParameterizedType) && (anInterface.getErasedType() == parentEventType.getErasedType())) {
                JParameterizedType parametrizedType = (JParameterizedType) anInterface;
                return parametrizedType.getTypeArgs()[0];
            }
        }
        throw new IllegalStateException("Payload type not found for: '" + eventType + "'.");
    }

    private String generateGwtSimpleEvent(TreeLogger treeLogger, GeneratorContext generatorContext, JClassType eventType, JClassType payloadType) {
        String gwtSimpleEventImplName = getGwtSimpleEventImplName(eventType);

        PrintWriter gwtSimpleEventPrintWriter = generatorContext.tryCreate(treeLogger, getEventsPackageName(), gwtSimpleEventImplName);
        GWT_SIMPLE_EVENT_TEMPLATE.generate(gwtSimpleEventPrintWriter, getEventsPackageName(), gwtSimpleEventImplName, payloadType.getName());
        generatorContext.commit(treeLogger, gwtSimpleEventPrintWriter);

        return gwtSimpleEventImplName;
    }

    private String generateEventImpl(TreeLogger treeLogger, GeneratorContext generatorContext, JClassType eventType, JClassType payloadType, String gwtSimpleEventImplName) {
        String eventImplTypeName = getEventImplTypeName(eventType);
        String eventTypeName = getEventTypeName(eventType);

        PrintWriter eventPrintWriter = generatorContext.tryCreate(treeLogger, getEventsPackageName(), eventImplTypeName);
        EVENT_IMPL_TEMPLATE.generate(eventPrintWriter, getEventsPackageName(), eventType.getQualifiedSourceName(), eventImplTypeName, eventTypeName, gwtSimpleEventImplName, payloadType.getName());
        generatorContext.commit(treeLogger, eventPrintWriter);

        return eventImplTypeName;
    }

... (some methods omitted)

While the “Event” class contains the interface definition for our events and lives in the “client” package of our GWT application, the “EventGenerator” is a GWT specific class that resides in the “server” package of our GWT application. In order to compile the code, we will need to add a new dependency to our project: “gwt-dev-<version>.jar”.

This generator class, by mean of some templates included in the source code, generates the boilerplate classes and saves us the tedious work of writing these classes. If you want to see this in detail, please refer to the “eventsfwk” packages in the client and server part of the application (source code here).

Using GIN to bring everything together

Following what I mentioned until now, it seems that if we define an interface extending the “Event” interface (ex: “SampleEvent”) and we use the generator to generate and wire the code by mean of “GWT.create(SampleEvent.class)”, we should be able to use the result as shown in the “GWTSample” execute method. Not really.

One piece that is missing in the puzzle is which event bus should the underlying GWT events use. We could create an own one without loosing functionality but a better thing that we can do is to provide an injection point and provide a mechanism to make our events participate in the application’s dependency injection context and use the application’s event bus instead of an own instance.

To achieve this, we have created a GIN module in the “eventsfwk” package:

public class EventsModule extends AbstractGinModule {
    @Override
    protected void configure() {
        requestStaticInjection(GwtSimpleEvent.class);
    }
}

This module should be installed in the application’s dependency context and it will inject an static field in the “GwtSimpleEvent” class which is the event bus used for our improved events. To install it in our application, the injection module has been modified like this (note the line “install(EventsModule.class);”):

@GinModules(Module.class)
public interface Injector extends Ginjector {
    public static class Module extends AbstractGinModule {
        @Override
        protected void configure() {
            bind(EventBus.class).to(SimpleEventBus.class).in(Singleton.class);

            install(new EventsModule());
            install(new GinFactoryModuleBuilder().build(Factory.class));

            bindConstant().annotatedWith(named("PingText")).to("Ping");

... (code omitted)
}

This means that, when the dependency injection module is initialized at the beginning of the application execution, the previously configured event bus will be statically injected in the “GwtSimpleEvent” class used by all the generated event classes.

I can not read minds, but maybe you are also wondering why the event fields annotated with “@Inject” get generated and injected. All in all, we don’t call anywhere “GWT.create()” to use the generator class.

Well, we are not doing it but GIN does. Whenever GIN finds a dependency (something annotated with “@Inject”) and that dependency has not explicitly been configured (bound in the GIN modules), GIN invokes “GWT.create()” as fallback strategy. This simple mechanism allows us to generate and inject our event in only one step.

Wow! This post has been “hardcore” GWT, don’t you think? Maybe even too “hardcore”. Please, just let me know if you like it and what do you think about the approach.

See you in a future post!

The source code for the initial version of the application can be downloaded here. The final version here. To see any of the applications working, unzip the corresponding file, change to the folder where the Maven pom file is stored and type the command: “mvn clean gwt:run”. After the GWT “Development mode” application starts, click on the “Launch Default Browser” button.

This is the third part of a series about Dependency Injection in Google Web Toolkit using GIN. If you have not yet read the first and second parts, you maybe should do it before reading this third and last article.

In this article, we will introduce two GIN features: “constants binding” and “static injection”.
To do this with an example, let’s refactor the “serve button” in the “Simulator” main class of the second part into an own class:

...
        final Button button = new Button("Serve!");
        button.addClickHandler(new ClickHandler() {
            public void onClick(ClickEvent event) {
                button.setVisible(false);
                injector.getRacket().serve();
            }
        });
...

Here the new extracted “ServeView” class:

public class ServeView extends Button {
    @Inject
    public ServeView(final Racket racket, @Named("ServeText") String serveText) {
        super(serveText);
        addClickHandler(new ClickHandler() {
            public void onClick(ClickEvent event) {
                setVisible(false);
                racket.serve();
            }
        });
    }
}

As you can see, the constructor of this new class is annotated with the “@Inject” annotation and receives two parameters. One of them is the racket and the other is the button’s label. In the case of the racket, it is already defined as an injectable dependency in the injector interface and in the case of the button’s label, it should be a configurable constant.
GIN, by mean of “constants binding”, performs the binding of injectable dependencies to constants.
Because the type of the “serveText” is String, we need to be more specific here and therefore we have annotated this dependency with the “@Named” annotation. To configure the constant value to bind to, we need to add the following line into our “InjectorModule” class:

...
        bindConstant().annotatedWith(named("ServeText")).to("Serve!");
...

To let the other constants in the application be configured in the same way and to introduce the last GIN feature (“static injection”), let’s now modify the “Simulator” main class as follows:

public class Simulator implements EntryPoint {
    @Inject
    static ServeView SERVE_VIEW;

    @Inject
    static AssistedInjectionFactory FACTORY;

    @Inject
    @Named("PingText")
    static String PING_TEXT;

    @Inject
    @Named("PongText")
    static String PONG_TEXT;

    public void onModuleLoad() {
        initInjection();
        RootPanel.get("buttonSlot").add(SERVE_VIEW);
        RootPanel.get("pingSlot").add(FACTORY.createPingPongView(PING_TEXT, PingEvent.class));
        RootPanel.get("pongSlot").add(FACTORY.createPingPongView(PONG_TEXT, PongEvent.class));
    }

    private void initInjection() {
        GWT.create(Injector.class);
    }
}

And our “InjectorModule” like this:

public class InjectorModule extends AbstractGinModule {
    @Override
    protected void configure() {
        bind(EventBus.class).to(SimpleEventBus.class).in(Singleton.class);

        install(new GinFactoryModuleBuilder().build(AssistedInjectionFactory.class));

        bindConstant().annotatedWith(named("PingText")).to("Ping");
        bindConstant().annotatedWith(named("PongText")).to("Pong");
        bindConstant().annotatedWith(named("ServeText")).to("Serve!");

        requestStaticInjection(Simulator.class);
    }
}

The “static injection” allows us to inject the static fields of a class. This happens by mean of the method “requestStaticInjection” of the GIN module class and, in our application, we use it to inject the static dependencies of the “Simulator” class.

This way, even when the “Simulator” class does not participate in the dependency injection context, its static members will be injected making the explicit references to the injector not required.

This has the side-effect of making the “Injector” getters no more necessary leaving our injector interface “empty”:

@GinModules(InjectorModule.class)
public interface Injector extends Ginjector {
}

Please note that, in order to get the dependency injection context configured and initialized, it is required to instantiate the “Injector” interface by mean of the “GWT.create()” method as part of the application initialization. This is done in our case within the “initInjection” method in the “Simulator” main class.

Conclusions

If you have read the 3 articles of this series, maybe you can remember how our demo application looked like at the beginning. While the functionality and appearance has not changed at all, the intern structure of the application is completely different.

In my opinion, dependency injection allows a much cleaner structure, enables configuring the application in an elegant and easy way and, when used together with an event bus, produces low-coupled high-modular applications.

Of course, “there is no free lunch” and using GIN means also that the development team has to learn new concepts and introduce a new framework in the application. Anyway, dependency injection is an already proven concept and GIN is being intensively used in most of the new GWT projects and GWT frameworks.

While some minimal application structure optimizations could still be applied to the application, the thing that I still find improvable in it is the verbosity of the GWT events definitions. This requires writing some boilerplate classes to ensure the type safety (event handlers), and also the definition of the own event classes is too verbose, being possible to generate them automatically in most of the cases by using either GWT’s deferred binding or a JDK 6 annotation processor. If you know how the events in CDI are defined, very probably you will agree with me that such an approach would be much more elegant and concise.

A solution for that, even when it requires dependency injection, is more related to other topics and therefore a subject for a different thread. If you got curious, stay tuned for a future post on code generation in GWT!

The source code of the application can be downloaded here. To see the application working, unzip the file, change to the folder where the Maven pom file is stored and type the command: “mvn clean gwt:run”. After the GWT “Development mode” application starts, click on the “Launch Default Browser” button.

As always, I hope that you enjoyed reading this series of articles as much as I did writing it and hope to see you soon in a future post!