Wednesday Feb 11, 2015

Java EE @ Java2Days 2014

Java2Days 2014 was held on November 17-19 in Sofia, Bulgaria. It is far and away the largest Java conference in the Balkans region and now perhaps one of the most important conferences in Europe as a whole. This was another great year for this rapidly growing, vibrant event. It attracted a host of international and local speakers including Arun Gupta, Geertjan Wielenga, Roberto Cortez, Ivan St. Ivanov, Andy Gumbrecht and Andrew Lombardi. Topics included Java SE, Java EE, HTML5/JavaScript, mobile, OSGi, IoT and the cloud. I am extremely grateful that the organizers invited me again this year and very glad that I was able to accept.

Java EE had a strong showing this year:

  • What's Coming in Java EE 8 - me
  • Nuts and Bolts of WebSocket - Arun
  • Java EE 7 Hands-on Lab - Arun, Ivan and me
  • Apache Tomcat to Apache TomEE in 1-n Steps - Andy Gumbrecht
  • Java EE 7 Batch Processing in the Real World - Roberto and Ivan
  • Coding for Desktop and Mobile with HTML5 and Java EE 7 - Geertjan
  • JavaScript/HTML5 Rich Clients Using Java EE 7 - me, Ivan
  • Forge and Arquillian Hands-on Lab - Ivan, me
  • Why Open Standards and Java/EE Matter (to You) - me

More details on the sessions and Java2Days, including the slide decks, video and code, posted on my personal blog.

Tuesday Feb 03, 2015

Batch API Hands-on Lab

During last JavaOne, we held a Hands-on-Lab on JSR 352. JSR 352 is one of the new Java EE 7 APIs. The formal API is name is 'Batch Applications for the Java Platform' but it is often referred to as the 'Batch API'.

The goal of this Lab is twofold, introducing the Batch API to newcomers and then explaining some of the most advanced JSR 352 features. For that reason, the Lab has been divided in 5 exercices:
  • Exercice 1 will introduce you the main concepts of JSR 352 such as Step, Job, JSL, etc. 
  • Exercice 2 will enhance the first exercise and introduce mutli-steps jobs combining Chunk step with a Batchlet step.
  • Exercice 3 will cover checkpoint and the JobOperator interface which can be used to resume a failed job.
  • Exercice 4 will build introduce you to listeners, a mechanism that can be used to intervene within the life-cycle of a batch job (e.g. to catch errors).
  • Exercice 5 will introduce the concept of Job Partitioning, a more advanced feature of JSR 352.
This Lab has been developed and tested on GlassFish 4.1 but it should work on any Java EE 7 compatible application server (note that JSR 352 is part of the full platform). This Lab is now hosted on GitHub so to learn JSR 352, just clone the repository and check the masterLab document.

Monday Sep 29, 2014

jBatch Suite: Visual Development for the Java API for Batch Processing/Java EE 7

As many of you know, the Java API for Batch Processing (JSR 352) is one of the key APIs added in Java EE 7. The API is largely based on POJOs, annotations and some XML. As a result you can be pretty productive even without an IDE. As a Java developer, however, like me you probably enjoy the usability of modern IDEs like NetBeans and may be wondering what IDE support there is for the Java API for Batch Processing. Although Java IDEs have been very good about supporting Java EE 7 generally, none of them have had much specific support for JBatch - until now that is. Sensing a gap Gaurav Gupta has stepped up with jBatch Suite. jBatch Suite is a NetBeans plugin that allows for both UML style modelling and code generation for Java Batch. Conveniently, it is available through the NetBeans Plugin Portal Update Center (Tools > Plugins). The following video is a great overview of the basic functionality in the plugin:

Gaurav has actually put together a very nice set of video demos covering the majority of functionality in the plugin on YouTube. The NetBeans plugin website offers further details as well as download. Contributions are welcome through the project for the plugin. Enjoy!

Thursday Jun 05, 2014

Pivotal Announces JSR-352 Compliance for Spring Batch

Pivotal, the company currently funding development of the popular Spring Framework, recently announced JSR 352 (aka Batch Applications for the Java Platform) compliance for the Spring Batch project. More specifically, Spring Batch targets JSR-352 Java SE runtime compatibility rather than Java EE runtime compatibility. If you are surprised that APIs included in Java EE can pass TCKs targeted for Java SE, you should not be. Many other Java EE APIs target compatibility in Java SE environments such as JMS and JPA. You can read about Spring Batch's support for JSR-352 here as well as the Spring configuration to get JSR-352 working in Spring (typically a very low level implementation concern intended to be completely transparent to most JSR-352 users).

JSR 352 is one of the few very encouraging cases of major active contribution to the Java EE standard from the Spring development team (the other major effort being Rod Johnson's co-leadership of JSR 330 along with Bob Lee). While IBM's Christopher Vignola led the spec and contributed IBM's years of highly mission critical batch processing experience from products like WebSphere Compute Grid and z/OS batch, the Spring team provided major influences to the API in particular for the chunk processing, listeners, splits and operational interfaces. The GlassFish team's own Mahesh Kannan also contributed, in particular by implementing much of the Java EE integration work for the reference implementation. This was an excellent example of multilateral engineering collaboration through the standards process.

For many complex reasons it is not too hard to find evidence of less than amicable interaction between the Spring ecosystem and the Java EE standard over the years if one cares to dig deep enough. In reality most developers see Spring and Java EE as two sides of the same server-side Java coin. At the core Spring and Java EE ecosystems have always shared deep undercurrents of common user bases, bi-directional flows of ideas and perhaps genuine if not begrudging mutual respect. We can all hope for continued strength for both ecosystems and graceful high notes of collaboration via efforts like JSR 352.

Thursday Jan 24, 2013

Java Batch in Proposed Final Draft

Java EE 7 marches on forward!

Congratulations to the Java Batch spec lead Chris Vignola of IBM and the Java Batch EG! Java Batch (more specifically "Batch Applications for the Java Platform" or JSR 352) was the very first Java EE 7 JSR to reach the Proposed Final Draft stage. We expect more Java EE 7 JSRs to follow suit shortly.

The draft is available for download on the JCP page for Java Batch. We encourage you to read the draft and provide your feedback (this is one of the last chances you will have to do so before the spec is finalized).

Wednesday Dec 07, 2011

Lesser-advertised Java JSRs

As you may have already read here, Java EE 7 (JSR 342) is well on its way with some JSRs having reached the early draft status (e.g. JAX-RS 2.0, JSF 2.2, CDI 1.1, ...).


On the other hand, you may not have heard of the following JSRs that are all candidates for inclusion in the Java EE Platform:
State Management (JSR 350) was recently filed by Oracle to offer a standard API for a state management subsystem (examples of state include HTTPSession and any state associated with CDI scoping annotations).
Batch (JSR 352) was covered here just recently as it has recently passed the Review Ballot.
Concurrency Utilities for Java EE (JSR 236) is building on JSR-166 (java.util.concurrency) to provide a clean abstraction for threaded code in a managed environment. It has been ongoing for several years and should be revived and completed in time for Java EE 7.
Java API for JSON Processing (JSR 353) is a parsing API for manipulating (reading or writing) JSON content. Binding (JAXB-style) is not in the scope of this newly submitted JSR.

The exact list of JSRs that will be part of Java EE 7 is up to the expert group to decide. Arun has more details on the status of each JSR.

Monday Dec 05, 2011

JSR 352 is ...?

Yes, it's the "Batch" JSR and it has recently passed the Review Ballot with 12 YES votes, two NO votes (LJC and Twitter), and two non-votes.


Note this is the first Executive Committee vote since the recent election. Comments on the vote results page indicate the reasons for the NO votes. The JSR now has a green light to form an expert group and get down to technical business.

The public project for the JSR work is at

Thursday Oct 27, 2011

javax.batch : new "Batch" JSR

In the batch of new JSRs in the Java EE realm, here's a new one: JSR 352: Batch Applications for the Java Platform. It is submitted by IBM with Chris Vignola as the specification lead.


The goal is to provide a standardized programming model to implement batch applications and an API to submit jobs. The JSR proposal defines the domain area with batch job, step, application, executor, and job manager. It is meant to work with both Java SE and Java EE with additional qualities of service with the latter option (transactions, CDI, ...).

The schedule is quite aggressive with a final version due out by mid 2012. No inclusion in Java EE is planned for the time being.