JavaOne 2013 – Part II

The time I’ve spent travelling had really caught up on me yesterday evening.  I found myself heading back to my room for any early night, which in turn caused me to wake up early again today.  I was still not over the jet lag, but getting up early does have some advantages as it gave me time to check in with team members back home and finish my plan of attack for the day.

Notify Your Mobile Clients by Integrating Push Networks and Java EE 7 (CON5073)

The session, given by AeroGear, discussed the two sides of push notifications, the server side that sends the push and the client side that must maintain a connection to the server to receive messages.

A push notification is a very small message that really just signals that an event happened (“You’ve got mail”).  The device can then decided what next steps to take (fetch that email message from the server).
While it is possible to create your own push network using JMS or CDI events on the server side and on the client: TCP Socket, UDP Socket and / or WebSocket along with multiplexing over one connection to the actual Push Network to minimize battery usage.  It’s much simpler to just reuse the networks offered by Apple, Google and Mozilla.

Apple’s Push Notification Service setup is quite complicated, but once setup, it’s very simple to use the API.  A Java-APNS Library (GitHub) was discussed which is used, server side, to tell Apple’s cloud that a notification is to be sent to a device.

While Apples PNS may be complicated to setup and easy to use, the reverse is true for Google.  For Google’s GCM, the setup work is simple, but the Android API is quite complicated.  Google provide their own server side Java API for pushing notifications to their cloud.

Mozilla SimplePush was also discussed for Firefox OS and Firefox Desktop which is still very early in development.

AeroGear offer a UnifiedPush Server that uses each of the push networks offered by Apple, Google and Mozilla.  You can download the web application and host it all yourself, dispatch notifications to your host using a multitude of different APIs including REST which are then forwarded to each of the third party push notification networks.  Their tools can be used to create all of the required boiler placed code needed leaving you with just a few pieces of information (Authentication info) to update for your setup and then include in your mobile app. Later planned additions will be support for Windows Phone and BBM.

Jump-starting Lambda Programming (TUT3877)

“All problems in computer science can be solved by another level of indirection” – Butler Lampson

The second session of the morning was about Lambda programming and it was the first full room I’ve seen with quite a few people waiting on standby outside.  The speaker, Stuart Mark, along with another individual (who was wearing a fedora) were at the top of a packed room, so all signs pointed to a good session.  It was a two hour session and was really just a basic overview, which covered the new API, parameterisation, streams, parallelisation and more.

We were first presented with a simple function

void robocallEligibleDrivers(Sex sex, boolean checksex, int minAge, in maxAge)
	for (Person p : list) {
		if ((checkSex && p.getSex() == sex) &&
			p.getAge() >= minAge && p.getAge() <= maxAge) {
			PhoneNumber num = p.getPhoneNumber();

Given the above, what happens if you do not what to set the min or max age?  What happens if you want to add new checks on the person like city, state etc.  A better solution would be to use an anonymous class that could take care of whatever checks needs to be applied to see if a person should be processed.

void robocallEligibleDrivers(PersonPredicate pred)
	for (Person p : list) {
		if (pred.test(pred)) {
			PhoneNumber num = p.getPhoneNumber();

The downside to this approach is that an anonymous inner class needs to be created each time your function is called.  This makes for ugly code.

void robocallEligibleDrivers(new PersonPredicate() {
	public boolean test(Person p) {
		return p.getAge() >= 16;

A better way to do this is with a Lambda expression which would look like:

void robocallEligibleDrivers() {
	robocallMatchingPersons(p -> p.getAge() >= 16);

The lambda code is much simpler, cleaner, easier to read and easier to use.  Lambda expressions do not only make for cleaner code, they also allow you incorporate new business requirements and new functionality with minimal changes to the original code.  There is a load of new annotations such as @FunctionalInterface and new packages, java.util.function etc which contains a large number of useful classes for lambda expressions.

Other topics discussed, all far too large to mention here, included:

  • Stream Pipelines
  • Parallelism
  • Reduction
  • Collectors

Lambda expression is one of the largest changed to the Java language ever, even bigger than generics and it will be very interesting to see how simple it is for the average developer to use in their day to day programming.

Liftoff with Groovy 2.1 (CON2591)

I was quite surprising to discover that Groovy is now ten years old.  It has grown quite a bit over that time and has now become more serious about been taken seriously.  The speaker, Guillaume Laforge, told us that in the beginning he received quite a few complaints from developers that were not allowed to use the framework due to its not very serious project name.  While the name of the project has stayed, the naming of new features has become more serious.  A feature, originally intended to be named Grumpy, after the dwarf, was renamed to a more serious, but less fun, ‘Static Type Checking’.

The theme of the session was a quick run over most of the new features in Groovy 2.0 with some sample code

  • Modular design – moved from one large jar file to many smaller jar files.
  • Extension modules – allow you to write your own modules that provide extension points to other classes.  For example, adding your own methods to the java.lang.String class.
  • Multi-catch exception blocks – as the name suggests, this feature allows you to write one catch block to catch multiple different exceptions.
  • Static type checking – throw errors at compile-time rather than at runtime.

Following that, the features of version 2.1 was discussed

  • Compile-time Meta-annotations
  • @DelegatesTo annotation
  • Type checker extensions

Overall, it looks like Groovy has come a very long way it both maturity and also in performance with the improvements for dynamic languages in JDK 7.

Effective Use of HTML5 JavaScript for Java EE 7 Web Applications (BOF7838)

This session had the biggest attendance so far, and it was a real let down for me!  The session only covered two of the items mentioned in its title, some of the new features in HTML 5 and a little bit of JavaScript!  I really don’t understand why Java EE 7 was mentioned as the only bit of Java in the session was the fact that the speaker worked for Oracle and used Netbeans as his HTML and JavaScript editor.  I really was expecting more.  The topics covered were HTML 5 Audio, Video, Canvas, Web Workers and Web Sockets.  The Audio and Video demo showed some HTML source core that played back audio and video content.  While the section on Web Workers and Web Sockets was much more informative, it was nothing that you wouldn’t fine in a short blog post on the topic. The session ended with a demo of a little hardware project that was hooked up to the speaker’s laptop. When individual elements of an 8×8 matrix on a webpage were clicked, the corresponding LED of an 8×8 LED matrix on the device connected to the laptop lit up.

Ten Things You Should Know When Writing Good Unit Test Cases in Java (BOF4255)

This birds of a feather session was given by Paul Thwaite of IBM and Stuart Marks from Oracle.  Both speakers work on JDK development, Paul on IBM’s version of the JDK and Stuart on Oracle’s OpenJDK.  It was the second session I attended by Stuart, the first on Lambda this morning which was also great, so I may have to keep an eye out for any other talks Stuart is giving over the week.  Below are the ten main points of the session.

  1. Thing before you act
    • What are you testing?
    • Why are you testing?
    • Plan
  2. Make your tests understandable
    • Comments
    • Expected behaviour
    • Diagnostics
    • Aid debug
  3. Keep your tests “small and simple”
    • Separate test logic / setup
    • Use setup / teardown
    • Much easier to debug
  4. Test one thing only
    • One scenario per test
    • Obvious why test failed
    • Enables fast debug
  5. Fast tests only
    • Run unit tests often as possible
    • Quick results
    • Maintain quality bar
  6. Absolute repeatability
    • Non-deterministic tests are a headache
    • Must trust all tests
    • Fix intermittent tests immediately
    • No value, waste of resource
  7. Independent tests only
    • Must run in any order
    • No dependencies
    • Run subset, faster results
  8. Provide diagnostic data on failure
    • Use message in asserts
    • Reference input data
    • Record test environment info
    • Make it simple to debug
  9. No hard-coding of your environment
    • Portable tests
    • No ports, IP addresses, data files, databases
    • Use config files, system properties or mock objects
  10. No extraneous output
    • A passing test is a silent test
    • Too much output = confusion
    • Use option, config file to turn on debug, save output

Slides are available on SlideShare

  1. Leave a comment

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: