Wednesday, 30 April 2014

The Clothesline Paradox and the Sharing Economy

“If you put your clothes in the dryer, the energy you use is measured and counted, but if you hang them on the clothesline to be dried in the sun, the energy saved disappears from our accounting.”
I found out about this talk of Tim O'Reilly on YouTube. I thought it was worth a reference in one of my little blogposts.


The Clothesline Paradox

Thursday, 24 April 2014

Coursera - Functional Programming Principles in Scala

On the 25th of April, meaning this Friday, I start my course on Scala.

I found Coursera1, an education platform that partners with universities to provide courses online for free.

I am really excited in finding out how Scala differs from Java, and what new programming methods I'll learn.

The fact that the Course2 has been set up by the creator of the language, Martin Odersky of École Polytechnique Fédérale de Lausanne, is a big plus.

I hope I can meet the deadlines.


[1] Coursera
[2] Coursera - Functional Programming Principles in Scala

Wednesday, 23 April 2014

NetBeans 8.0 - Upgrading My Source Code

I have heard that in NetBeans 8.0, which has full support for the new Java 81, you can have your source code transformed to make use of the latest and greatest Java 8 has to offer.

Naturally, I wish to test this. I've chosen my YPPO project for it.


It seems easy enough. Just select Source in the main menu and choose Inspect2.

It transpired that I require FindBugs to use All Analyzers, but NetBeans automatically asked if I wanted to install it.

A lot of the inspection messages are regarding missing JavaDoc. I'm going to skip over those (as being not interesting).

Functional Operations

Use functional operations instead of imperative style loop.
public static void addErrorMessages(List<String> messages)
    for (String message : messages)
Got turned into:
public static void addErrorMessages(List<String> messages)
{ ->

private void persistGalleries(Map<String, Gallery> galleries)
    for (String path : galleries.keySet())
        Gallery gallery = galleries.get(path);
        logger.log(Level.FINE, "persistGalleries persist gallery {0}.", gallery);
Got turned into:
private void persistGalleries(Map<String, Gallery> galleries)
    galleries.keySet().stream().map((path) -> galleries.get(path)).map((gallery) ->
        logger.log(Level.FINE, "persistGalleries persist gallery {0}.", gallery);
        return gallery;
    }).forEach((gallery) ->

Lambda Expressions

Anonymous inner class creation can be turned into a lambda expression.
Collections.sort(list, new Comparator<Gallery>()
    public int compare(Gallery t, Gallery t1)
        return t.getCreationDate().compareTo(t1.getCreationDate());
Got turned into:
Collections.sort(list, (Gallery t, Gallery t1) -> t.getCreationDate().compareTo(t1.getCreationDate()));


Despite NetBeans telling me that everything is perfectly fine, actually deploying it to GlassFish using the new Streams throws an ArrayIndexOutOfBoundsException. See [3].

I'm sure they're already hard at work.


[1] Overview of JDK 8 Support in NetBeans IDE
[2] 7.11.21 Using Hints in Source Code Analysis and Refactoring
[3] Collection streams provoke java.lang.ArrayIndexOutOfBoundsException

Tuesday, 15 April 2014

"if it hurts, do it more often."

I recently came across the phrase "if it hurts, do it more often."1 on the website of Martin Fowler.

Now, this might not be appropriate to, for example, slamming your hand into a car door, but it does have its uses, for example, in sports.

Personally, I think it is one of the defining characteristics of humans versus animals, that humans can suffer through a bad cause (pain/hardship/uncomfortableness) if they know the effect later is appropriately good. In other words, humans have the ability to reason about causality3, usually with a perception of time.

Unfortunately, sometimes the animal instincts prove stronger.

Continuous Integration

The soundbite in the title comes straight out of the realm of Continuous Integration2.

I came across the sentence, as I was wrestling with a problem at work. We have several branches, which are specific to certain of our customers. An often heard complaint nowadays is that these are so called 'Long-lived branches'. Now, the more I consider it, the more I think long-lived branches are a pretty bad idea.

The complaint I hear most often is that some of our software developers are spending more time merging changes to the different branches and keeping them in sync and retesting, than actually developing new software.

I just thought I'd put down some references (see [4] and [5]) on how to get rid of long-lived branches, and keep everything in the main branch. I don't feel sanguine about convincing management, though.


[1] Martin Fowler - Frequency Reduces Difficulty
[2] Wikipedia - Continuous Integration
[3] Causality
Lean into the pain
[4] Martin Fowler - Feature Branch
[5] Martin Fowler - Branch by Abstraction

Tuesday, 8 April 2014

Batch Jobs in JEE 7

This little blogpost is to describe my current design for Batch processing in my YPPO9 project. The image comes straight from Spring Batch.

As no doubt you are aware, Batch Processing in Java has been standardized in JEE 72. It is based on already existing Batch implementations, for example, Spring Batch7.

The reason I am interested in it, is that I wanted to initially solve my problem using a JMS queue, but after getting the warning that I'm creating too many messages in one transaction, I decided to give batch processing a try instead. Besides, it felt a little (oh, all right, a lot!) like I was abusing the JMS for Batch processing in the first place.

encapsulates the entire batch process. So, in our case, we have two jobs to define for YPPO. Job "Import new Photographs" and job "Verify existing Photographs".
a domain object that encapsulates an independent, sequential phase of the job. There are two kinds, Chunk-style and Batchlet-style. We can suffice here with the standard, Chunk-style. We only need one step for each job. We are keeping it simple as that is all that is needed.
  • chunk-style step "Import Photograph" for job "Import new Photographs"
  • chunk style step "Verify Photograph" for job "Verify existing Photographs"
operates on jobs, starts them, stops them, retrieves required steps etc.
contains history, jobs running, job that have run, etc.
I shall be focussing on the "Verify existing Photographs" job for the remainder of the blogpost.

Batch Artifacts

The Batch Artifacts are injected as Beans into the job system using CDI. Thusly the artifacts used are Beans identified with @Named annotations.

In the package above, the classes Listener, Reader, Processor, Writer are Beans annotated with @Named with names verifyPhotographListener, verifyPhotographReader, verifyPhotographProcessor and verifyPhotographWriter respectively. These names will be used later in defining the job.

In my example, I also wished that if an actual error occurred, the item to be processed would be skipped and a log error written to the database, so that it can be checked and corrected afterwards by the user. So, errors on individual items are no excuse for stopping the job.

In the new JEE 7, there's a setting in the empty beans.xml file called "bean-discovery-mode", which is required. If set to "all", it checks all classes for CDI. If set to "annotated", it checks only those classes that have annotations. I've set it to "annotated". However, I've tried setting the @Named annotation on the classes I required, but my classes weren't injected in the Batch jobs. An additional annotation for the scope (@ApplicationScope) is required, before the classes are picked up.

Below is a sequence diagram of a job.

Job Specification Language

JSL or Job Specification Language is the xml format used to define jobs. It is grammatically defined in [5].

In the picture on the left, you can see where in my project structure in NetBeans the Job definition files are located. In this location, they are automatically picked up by the Application Server.

For YPPO you can find the files AddPhotographs.xml and VerifyPhotographs.xml as visible below on my git repository YourPersonalPhotographOrganiser.

A job can currently not be restarted. My jobs are not configured for restarting (restartable="false" as you can see). I'll devote a future blog to it once I figure out how to do that.

In my example, I have a Batch job chunk-size of 4. (item-count="4")

Listeners should be defined in the step, prior to defining other things, like for example a chunk.

Starting a Batch Job

public void verifyPhotographs(Location location)
    JobOperator operator = BatchRuntime.getJobOperator();
    Properties jobParameters = new Properties();
    jobParameters.setProperty("location", location.getId() + "");
    operator.start("VerifyPhotographs", jobParameters); // maps to VerifyPhotographs.xml

Retrieving Details About Batch Jobs


It seems NetBeans has no Wizards nor GUIs and Widgets to automatically generate Batch Jobs scaffolding, but it is on the roadmap.

There are lots of tutorials on Batch Jobs in JEE 7, however, a lot of them were written in the first half of 2013 and they have in the mean time changed the definition of Batch Artifacts from Annotations to a simple set of Interfaces your Batch Artifacts need to implement.1 3

[4] gives a good general view of Batch Applications in Java 7. The JEE 7 Tutorial8 is also very good.


[1] Batch Applications in Java EE
[2] JSR 352 - Java Batch
[3] Batch Applications for Java Processing - SlideShare
[4] Java EE 7 Introduction to Batch JSR 352
[5] Batch Applications for the Java Platform - Version 1.0 Final Release
[6] JavaDoc - JEE 7
[7] Spring Batch in Action
Arnaud Cogluègnes, Thierry Templier, Gary Gregory, Olivier Bazoud
[8] JEE 7 Tutorial - Batch Processing
[9] GitHub - YourPersonalPhotographOrganiser (YPPO)