A few days ago I went with a friend to JAX conference 2013, a conference in which experts & leaders from the industry share their thoughts and experience with other Java community members.

We started with a session about testing HTML5 in all browsers using Java by Kevin Nilson. He got me hooked right from the beginning with two nice Javascript riddles:

The first:

var t = ['a','b','c',]; // pay attention to the last comma
console.log(t.length);

Is that a legal expression? (yes)
What’s the length? (hint: browser dependent…)

The second:

var abcData = ['a','b','c'];
var xyzData = ['X','Y','Z'];

function xyz(){
  var msg = '';
  for(i=0;i<3;i++){
      msg += xyzData[i];
  }
}

function aXYZbXYZcXYZ(){
  var msg = '';
  for(i=0;i<3;i++){
      msg += abcData[i];
      var tmp = xyz();
      msg += tmp
  }
} 

What’s going to be printed ?
My guess was “aXYZbXYZcXYZ” – but it was wrong…
If you want to see the answer – you can watch the video of the session (in the link above).

After the warm-up, Kevin discussed the limitations of using selenium to test mobile and the advantages of using tools like TestSwarm and QUnit.

Getting Started with WebSocket using Java by Arun Gupta introduced a light full-duplex bi-directional communication protocol between server and client. “Upgrading” HTTP protocol to WebSocket is done using HTTP-headers:

upgrade: websocket
connection: upgrade

for which the server supposed to return HTTP code:

101 - switching protocols

Full-duplex means that once communication has been established, both sides are peers in the manner that both can send information to each other simultaneously (unlike HTTP in which only the client triggers the request and the server can only respond). Another advantage of using Websocket is the speed: the thin frame that is used by the protocol allows sending bigger chunks of data more quickly than using HTTP which carries the overhead of sending headers in every request/response. Arun benchmarked the performance of WebSocket vs. REST and the difference were (as expected) huge, for example: sending 5,000 messages of 1KB each using REST took 55 seconds and only 1.2 seconds using WebSocket.

Another interesting session was: Apache TomEE, Java EE 6 Web Profile on Tomcat by David Blevins. TomEE (pronounced: “Tommy”) is a project that aims to combine plain vanilla Tomcat with some of the more common JavaEE components, such as EJB, JPA, JMS and more (they call it “Web-profile” and it contains about half of the “full profile”). Recently they passed the TCK (Technology Compatibility Kit) of the Web-profile, David says, without increasing Java memory!

In The Road to Lambda (will be released in Java 8 – around sprint 2014) Mike Duigou showed the power of using lambdas which makes your code simpler (reduces the boilerplate), and as a bonus you get lazy evaluation and support for parallelism. Like Generics (introduced at Java 5) helps us abstract over types, the goal of Lambda is to help us better abstract over behavior (passing “behavior” = method, between objects using vars).

I got to admit that even though I like functional programming I hate the use of anonymous classes in Java, to me, it always felt like some kind of ugly hybrid between OOP and functional programming:
Lambda (closure) ties up code to data, and the equivalent to it in OO is… well, Objects.
So I was pretty skeptical about the whole idea but I’m glad to say that I was wrong!

The session started by using the fact that other languages like C++ and C# already introduced closures (bad reasoning TMO), but then Mike gave a couple of good motives, one of which was the transformation of the following code:

for(Shape s: shapes){
    if(s.getColor() == RED)
        s.setColor(BLUE);
}

to:

shapes.forEach(s->{
    if(s.getColor() == RED)
        s.setColor(BLUE);
});

At first glance it looks like there’s no much difference besides the different syntax, but what really matters here is what goes under the hood: the former piece of code translates into an iterator that traverse the shapes in a serial manner, while the latter enables the library to set its own implementation which could, for instance, support parallelism.

Another example which I really liked is

int sumOfWeights = shapes.stream
				.filter(s->s.getColor == BLUE)
				.map(s->s.getWeight())
				.sum();

or even a bit simpler:

int sumOfWeights = shapes.stream
				.filter(s->s.getColor == BLUE)
				.map(Shape::getWeight)
				.sum();

but what really impressed me was how easy it is to modify the code to use parallel processing:

int sumOfWeights = shapes.parallel()
				.filter(s->s.getColor == BLUE)
				.map(Shape::getWeight)
				.sum();

Since this post is becoming too long I won’t write about other sessions, that said, I cannot not mention (and post links to) other great sessions such as Designing a Beautiful REST+JSON API by Les Hazlewood, The Spring 3.1, 3.2 and 4.0 Update by Josh Long and The Java EE 7 Platform: Boosting Productivity and Embracing HTML 5 by Arun Gupta.

See you in #JAXConf next year!