Live GWT Q&A with Colin Alworth on Java 8 in GWT 2.8

We are pleased to announce that we are going to hold our May live Q&A with Colin Alworth on May 18th.

Colin Alworth has been a member of the GWT community since 2008, as a user, contributor, and steering committee member. Currently spending much of his free time building Java 8 library emulation and filing bugs along the way, he can most frequently be found in ##gwt on freenode as well as StackOverflow and gitter.im/gwtproject/gwt. Continue reading “Live GWT Q&A with Colin Alworth on Java 8 in GWT 2.8”

Build your own test framework

One of the most used library, if not the most, in the world of Java programmers is JUnit. It is a test framework (not necessarily of unit tests) that allows one to write tests this way :

This is a really practical tool, but for a lot of developers, that library (like many other developer’s tools) sometimes has a magical and mysterious aspect, where we tell ourselves that we would certainly not be able to build something like this. Continue reading “Build your own test framework”

Live GWT Q&A with Manuel Carrasco Moñino on GWTQuery and Polymer

We are pleased to announce that we are going to hold our April live Q&A with Manuel Carrasco Moñino on April 27th.

Manuel will be our guest for this one and he will be talking about GQuery, as he is one of the core developers of this Open Source library. Also, he will be talking about Polymer, one of his recent interests. Continue reading “Live GWT Q&A with Manuel Carrasco Moñino on GWTQuery and Polymer”

Testing client-server communication with REST-Dispatch

A lot of the tests that are written in GWTP applications focus on client-server communication. Fetching and saving data is what most web applications do nowadays.

You can use whatever library to accomplish this work, however, in this post I use REST-Dispatch and Resource Delegates, from gwtp-extensions. They come with nice testing utilities that I’ll show you. Continue reading “Testing client-server communication with REST-Dispatch”

Testing patterns in GWTP

This post is intended to be the next steps towards a TDD approach with GWTP. We’ll try to show you the patterns and workflow of writing a GWTP application in a TDD fashion. Continue reading “Testing patterns in GWTP”

Using GWT 2.8 beta 1

EDIT : An earlier version of this post talked about Java 8 Streams, which are not supported by GWT 2.8 for the moment. My apologies.

A few weeks ago, the GWT Team released on Maven a beta for the new version of GWT: GWT 2.8 beta 1. This new version has been announced for a while and was eagerly awaited by the community.

Other than speed improvement and many cool new enhancements, there are new features we can now use in our GWT application. One big feature of this version, in my opinion, is the support of lambdas, a part of Java 8.

Lambdas

In Java 7, if one wanted to pass a function in parameter, they had to do something like that :

In Java 8 (and also in GWT 2.8), simply do this:

We now have a more elegant way to write exactly the same functionality. It makes for more compact code, with less clutter and cleaner code.

JSInterop

Another thing to note, the interoperability with JavaScript is no more experimental. You can now simply use the annotations (@JsType, @JsProperty, etc.) and directly use a JavaScript library in your GWT code.

As Brendan Donnelson said in his Q&A, you can now imagine – if you have a GWT and JavaScript expertise in your business –  a seamless collaboration between JavaScript developers who do part of the application and GWT developers who use their work in the GWT application.

For example,

This example was taken from the current specification of JSInterop which covers a lot of the possibilities of JsInterop. It is also possible to make content in Java that could be exported and usable in JavaScript. A few of our developers are currently exploring on both sides of this coin. I think it will make for good next articles on this blog.

Concrete example

If you want to see concretely what a migration to GWT 2.8 beta1 is like on a typical GWT 2.7 application, just refer to this pull request. I am currently in the process of moving our BeeStore sample to GWT 2.8. It will give you an idea of how to do so.

We just covered the tip of the iceberg of what is new in GWT 2.8. See the complete release notes for the complete list of features that GWT 2.8 beta 1 brings.

Feel free to tell us what cool web application you did (or plan to do) with GWT 2.8 or JsInterop in the comments!

Code Splitting for Non-Presenters in GWTP

One of the interesting features in GWT is Code Splitting. It allows you to load part of your application only when it is needed. This reduces your app’s loading time and makes for a better user experience.

What is a split point?

Code splitting allows you to separate your code in multiple fragments (more specifically, in multiple JavaScript files). Each location where you choose to separate your code is called a split point. If you want an analogy, each split point is like a door for the content behind it. The main advantage (other than a faster initial loading time) is if a user never accesses some heavy part of your app that is less often used, the total download that the user requires to navigate your app is also reduced.

ProxyCodeSplit

In GWTP, when you want to put one of your Presenters behind a split point, you can use the @ProxyCodeSplit annotation to do it.

ProxyCodeSplitBundle

Sometimes, you want to group some Presenters (“bundle” them) behind a split point. That way, they will be grouped in a unique JavaScript file, which is sometimes more time-efficient than multiple files.

The first thing that you have to do is create an interface with the names of your different bundles, and use the @ProxyCodeSplitBundle annotation. GWT Code Generation will kick off and generate all that you need to separate the Presenters as you wish.

For example, you can write your interface like as follows (taken from Arcbees’ website) :

You can then use the annotation on your Proxy and the name of the bundle you want your Presenter to be in :

Bundles for Non-Presenters

A question that we get quite often these days is how to use this annotation function for Java classes that are not Presenters. These annotations are tailored for Presenters, but not for other use cases.

Suppose we want to bundle two services (FirstService and SecondService) behind a split point. We will have to first create a concrete class for our bundle.

We now have access, via our getters, to each of our services.

Now, if we want to use these services, we can inject the MyBundle class with AsyncProvider (this is necessary for GWT to do its code splitting).

You can now retrieve your service (the best practice is in the onBind() function if you are in a Presenter) this way :

I hope this article helped you understand how split points work, in particular with the non-Presenter bundles. Don’t forget to subscribe to our newsletter if you want more articles like this.

Testing GWTP applications with Jukito – Introduction to Jukito

In this second post of the Testing GWTP applications with Jukito, we present : Jukito!

The purpose of this post is to show the basics of Jukito, and to show what are the advantages for you and for your project.

What is Jukito?

Jukito is a Java library that allows you to reduce the amount of code to write when testing code that is written using dependency injection. Typically, people use Mockito to mock their dependencies and it ends up being cumbersome. Jukito creates mocks for you for all the injected dependencies.

Here is an example made with Mockito and an example done with Jukito.

As you can see, the only differences with the two snippets, are:

  • With jukito you don’t have to call the class under test’s constructor
  • The annotation used to mock dependencies is @Inject instead of @Mock
  • The TestRunner annotation changed

At first, it doesn’t look like a big deal, but when the code base grows, things can get out of control. For example, imagine that we want to add a new dependency to the Endpoint class and inject it via constructor.

With Mockito, this kind of change will produce a compilation error. On the other hand, with Jukito, everything still compiles fine, since the call site doesn’t change.

OK, what now?

Jukito uses Google Guice and Mockito behind the scenes. However, even if you’re not using Guice, you can still use Jukito. The only requirement to use Jukito is to use Java’s standard annotation @Inject on your class’ constructor.

Everything that is possible in a Guice Module can also be done in a Jukito module.

Example

Let’s say you have an interface called UserInformationService. You could have a test that uses a fake implementation, another test that uses the real implementation and another test that uses a mock implementation. By default, Jukito injects Mockito mocks, but it is also possible to bind the interface to whatever implementation you want. To do so, we have to declare a Jukito module in the test class, and setup things there.

There is another cool use case for Jukito and Guice. A lot of Java code use factories. Guice has the ability to generate a factory implementation from an interface. We can either inject a mock factory or create a real factory with a binding in the Jukito module.

The first case would be to inject a mock factory as in the second gist, where we used Jukito.

We had to change the code a little bit here so that the factory would be managed by Guice. As you can see, the scope of the test is a little bit wider. The test verify that the endpoint returns the correct status code.

There is no best solution, it mostly depends on the level of integration you want your test to have. In the first, the response would be the one that you crafted yourself, whereas in the second, the response returned by theResponseFactory would be the same as in production.

Conclusion

In summary, Jukito is a library that does whatever is possible with Mockito and Guice. When writing big projects, it can really help scaling the code base and all its tests.

It is even more useful in a context like a GWTP application, where :

  • Almost all components use dependency injection
  • GWTP uses GIN (which is Guice for GWT)
  • Testing interactions is very natural. Therefore using mocks for testing and driving the design is also natural

Hopefully, this post gave just enough information to understand the upcoming examples about testing GWT components, like Presenters.

GWTP 1.5.1 Release

Hi there !

Just a quick note to inform you that we have just released version 1.5.1 of GWTP.

Here are the bugs that we fixed :

  • We made the new NestedSlot removable
  • We made sure that some of the compile errors are not ignored

We also cleaned up the code and solidified some tests to make sure that we follow best practices as much as we can. These changes should not have any significant impact on your GWTP development.

See the full release notes here.

As usual, you’re more than welcome to contribute to the framework or submit an issue if you find one. It motivates us to see that we have a strong community. In this small release alone we have 7 contributors, which is fun and makes us feel that our team is even stronger for their efforts. Thanks for being such a big part of our community !

Don’t forget to subscribe to our newsletter if you have not done so already. We post how-to videos every 2 weeks, and other posts about software releases and topics like organizational culture, whenever we can.

GWTChosen 3.0.1 Release

A few days ago, we released GTWChosen version 3.0 and made a Q&A about it.

This is a little note to let you know that we have just released the 3.0.1 version which contains fixes for some regressions that sneaked into the 3.0 release.

One of the major things was that the onChange event was not fired anymore, which was obviously pretty important.

Then, we were able to fix our sample on the developer portal and from now on everything should work properly. Please tell us if you see anything that should be fixed or improved in our issue tracker.

Thanks to our active community, we have a lot of eyes on our products. It is thus easier to spot bugs and make a software that is really useful to you!

See the full release notes for more details. Also, if you want to be aware of our future blog posts, you can subscribe to our newsletter.