London Java Community

London Java Community Open Conference 2015

Yesterday, I saved up enough pennies to go to the annual LJC Open Conference at the IBM building, right next to the National Theatre on London’s South Bank, and done in the same brutalist style.

Open Conferences, sometimes called Un-conferences, are where there is no set schedule, other than perhaps, as here, a key-note to start. It’s left to the participants to organise the presentations and workshops.

The Conference Key-note: 20 Years of Java

Starting off with the key note by Simon Ritter and Steve Elliot, both former employees of Sun Micro-Systems (Steve still works for Oracle, Simon does not). This covered Java since it’s launch in 1995, showing how the language has evolved from the 200 odd classes in version 1 to the 4000+ in the latest version, 8. They commented that this bloated situation would improve with the introduction of “Jigsaw”, the modularisation of the JDK.

Performance by the Numbers with Simon Maple

The first presentation I attended concerned a survey conducted by Simon and his company to see how much performance testing was done by the profession and what effect it had. Unsurprisingly, few tested regularly and most tested in reaction to performance bottlenecks when they were found in production. Most performance bugs were connected to databases as much, if not slightly more, than the applications themselves: JPA and Hibernate being the worse culprits in this regard. The lesson here being performance test early, often and with the right tools.

Microservices in the Real World with Chris Batey

Given the popularity at the moment, and linked, to some extent, with the previous talk, Chris took us through his experiences with microservices, especially dealing with outages and his efforts to make the applications more robust (he recommended Netfix’s Hysterix). His slides of the talk can be found here.

Lightning Talks and Lunch

Both before and after lunch there were lightning talks, five minutes where anyone could talk about almost anything. One involved the use of Microsoft’s Kinetix to create ghostly 3D images, like a cut-price 3D scanner. Another mentioned a book called “Godel, Escher, Bach: An Eternal Golden Braid” by Douglas Hofstadter, with a view to writing every algorithm that ever could be written.

JDK8 Lambdas and Streams: Beyond the Basics with Simon Ritter

The first proper presentation after lunch was regarding the new features of JDK 8. Simon gave us a few examples of how he has changed his style of programming from the procedural style to the new functional style using lambdas and, especially, streams. In particular, he showed how using the Supplier interface could allow lazy evaluation, something normally only available in interpreted or functional languages such Scala, and how to design and use accumulators for use with Streams.

IoT 4 Java with Carl Jokl

Having been to the presentation earlier in the week on the BBC micro:bit, I was interested to see what the LJC was doing about this. Unfortunately, it’s all at the very early stages at the moment and Carl didn’t have much to show other than a few concepts: it would have been nice to see some actual things.

Generics: Past, Present and Future with Richard Warburton

Lastly, Richard gave a short presentation on the use of Generics and how they might evolve with future versions. Generics are Java’s way of implementing meta-classes, classes built around other classes, Collections being a usual example. Java 7 introduced intersection types to generics, which can make things even more confusing, so you get code like this:

private static <I extends DataInput & Closeable> PersonWithGenerics read(I source)

Allowing any object that implements both DataInput and Closable in it’s hierarchy of classes and interfaces to be used. It’s a bit like a multiple inheritance workaround.

Richard also showed us was an actual use of the “super” keyword in Generics, something you don’t often get. I won’t go into it here, as it was somewhat involved, but he put the code for the session on Github.

He also mentioned some ideas for future versions, including Generics for primitive types (not just the objects of types, as at the moment).

Conclusion

Was it worth the £25? Yes, I think so, and 200 other people thought so too. The presentations were of reasonable quality, what I saw, and better than you would expect. Perhaps because it’s less contrived than a more expensive conference.

London Java Community, Docklands – Swagger and Hazlecast

Tonight I went along to see two presentations hosted by the London Java Community Docklands branch at Credit Suisse, all wood panelling and soft carpets in the lobby:

First up was David Garry, whose soft Irish tones introduced us to Swagger, an open source REST API definition language and tool suite. You can either reverse engineer you existing API into Swagger or create a new one and generate code from that. The web site has a rather natty online editor:

which will allow you to roll your own definition as well as creating the source code for both server and client. Shown below is some the code produced for SpringMVC:

@Controller
@RequestMapping(value = "/addresses", produces = {APPLICATION_JSON_VALUE})
@Api(value = "/addresses", description = "the addresses API")
@javax.annotation.Generated(value = "class io.swagger.codegen.languages.SpringMVCServerCodegen", date = "2015-10-13T22:20:28.432Z")
public class AddressesApi {

  @ApiOperation(value = "Addresses", 
                notes = "A collection of addresses.", 
				response = Address.class, 
				responseContainer = "List")
  @ApiResponses(value = { 
    @ApiResponse(code = 200, message = "An array of addresses"),
    @ApiResponse(code = 200, message = "Unexpected error") })
  @RequestMapping(value = "", 
                  method = RequestMethod.POST)
  public ResponseEntity<List<Address>> addressesPost(@ApiParam(value = "Latitude component of location.", 
		required = true) 
		@RequestParam(value = "latitude", required = true) Double latitude

It’s a mess of annotations, as you can see, but I suppose if you’ve got a couple of hundred of these definitions, and you have to keep them all documented, Swagger can come in handy.

Next was David Brimley who introduced us to Hazelcast. A few months ago, Pakt had a free book offer and one I downloaded was on an introduction to the subject:

It’s a kind of middleware for data services, styled as an “In-memory Data Grid”, implying caching of data. It does implement the JCache standard (JSR107), but it also includes a messaging and event API, allowing you to be notified of changes in data; clustering and scaling of data “nodes”; and remote code execution (imagine Java stored procedures… sort of). David gave us a very thorough overview, given the limited time available to him.

Mockito Spies

That is the collective noun, not the verb, although I suppose Mockito is spying…

Spies are used to make existing classes into Mockito classes. Say your class under test hooks into a Java listener, so you want some kind of dummy listener for it to hook into. You can’t do this with Mockito (at least I can’t find a way), but you can make your own:


//listener interface
public interface SomethingListener {
    //change that sends the event
    public void somethingChanged(EventObject e);
}

//our little dummy listener provider
public class DummyListenerProvider {

    private SwitchListener listener;

    //this is used by the class under test
    public void addSwitchListener(SwitchListener listener) {
        this.listener = listener;
    }

    //send event, saying the class is the source
    public void triggerEvent() {
        this.listener.somethingChanged(new EventObject(this));
    }

    //used by the event consumer when the event occurs
    public void switchMeOn(boolean isTrue) {
    }
}

Cool, but you still want all the nice little trinkets that come with the Mockito objects. This is where spies come in. You just wrapper the class using spy instead of mock:


DummyListenerProvider spyListenerProvider = spy(new DummyListenerProvider());

ClassUnderTest underTest = new ClassUnderTest(spyListenerProvider);

spyListenerProvider.triggerEvent();

verify(spyListenerProvider).switchMeOn(true);

Java Concurrent Animated

I thought I take a trip into town this evening to see a presentation at Skills Matter by Victor Grazi (complete with “Brooklyn accent”) concerning Java concurrency.

Concurrency is always a difficult subject, but not so much the thing itself as what happens when concurrent processes try to access the same resources at the same time. Normally, in Java, this is done via the “synchronized” command. You designate a block of code and wrapper it in a synchronized block:

synchronized(this) {
    Counter.count++;
    System.out.print(Counter.count + "  ");
}

or declare a function to be synchronized:

public synchronized void assign(int i) {
    val = i;
}

However, if one thread gets to the block first, it locks out the any other threads trying to do the same. There’s nothing that the others can do about it other than wait.

Victor’s presentation was regarding what was available in the Java API, such as Locks, Semaphores, to get around this or avoid it altogether, as well as exploring other aspects of the API such as Thread Pooling.

What made this presentation a little different was the animation of the threads, which were doing little animated circuits to illustrate his points. The source can be found on SourceForge. It looks cute, plus is does show you the various options available to the Java programmer other than just the ubiquitous “synchronized”.

Overall, Victor gave a very good presentation of a difficult, but important, subject.

London Java Community – Lambdas: Myths and Mistakes

On Wednesday evening I went to see the presentation by Richard Warburton at Skills Matter regarding the new functional features of Java 8.

A few words of explanation for those not familiar with the terminology.

The JSR mentioned is a Java Specification Request, which is what you create when you have a suggestion for how you want Java to change in the future. These are submitted as part of the Java Community Process, set up by Sun when they realised they had something big on their hands releasing Java. In theory it allows everyone to have a voice, but in practise it’s mostly those with very extensive knowledge of the language (such as Richard), although the Adopt-a-JSR he talks about is a move to allow the average code-cutter their ten-penn’th, as well as field testing the resulting change. The JCP has been criticised for slowing down changes to Java which might make it more competitive: Microsoft just releases their software to beta without any real consultation, while Google just seems to keep everything in permanent beta, killing it off when they get tired of it.

The “lazy” and “eager” he talks about are functional concepts that are easier to grasp by watching them in action rather than talking about them, but the nearest non-programming equivalent would be the just-in-time of logistics and manufacturing (a part is ordered to arrive just in time to be used, thus eliminating the need to store it and the resulting cost of doing so). The lazy algorithm is executed when it’s needed, whereas the eager one is executed completely. This is why there’s a problem when the different algorithms are mixed and why the lazy ones play havoc with profilers (software that tries to work out how efficient your code is, amongst other things).

Richard was quite eloquent, highlighting the changes and giving examples of the way in which they should be used, but it became clear that Java 8 is not the radical change that everyone thought it might be. The functional features, like interfaces and generics before them, look like they’ve been added onto the existing features and even create conflicts with them (the “streams” and collections Richard talks about).

While it’s looking as if they are not going to be usurping Scala and Clojure any time soon, the new features look very Scala-like, which does look a little ominous for the latter. Mind you, they also look a little Erlang-like as well, so make of that what you will.