Monthly Archives: June 2016

Reactions: A First Look at Couchbase

The Philly JUG had a great meeting this week about Couchbase. I casually knew about Couchbase as a NoSQL solution, but there were a couple really cool things that surprised me.

First: There’s a Couchbase Lite that is suitable for running directly on mobile devices. So you could use this instead of SQLite on Android! Using NoSQL on your phone sounded pretty exciting!

Also: There is a Sync Gateway for client-server replication and peer-to-peer replication. From their site, Couchbase Lite “Supports replication with compatible database servers. This gives your app best-of-breed sync capabilities. Not only can the user’s data stay in sync across multiple devices, but multiple users’ data can be synced together. Supports peer-to-peer replication. By adding an extra HTTP listener component, your app can accept connections from other devices running Couchbase Lite and exchange data with them.”

Finally, it’s worth noting that Spring Data supports Couchbase directly. So if you are in the Spring world, it should make using Couchbase even easier.

When a Philly JUG meeting ends with everybody learning something new, I’ll call it a rousing success!


Leave a comment

Filed under Software Engineering

Java 9: Hello World!

Java 9 is scheduled for release in 2017, and is shaping up to have some exciting new features. If you’re excited to try it out too, here are the first steps to compiling some real live Java 9 code!

Download Java 9

First, download Java 9 from OpenJDK. At one point, Project Jigsaw was in a separate branch from the main Java 9 download, but it was merged into the main trunk in March 2016. So rest assured, you are getting the whole ball of wax with this download! Once downloaded, we can set the path to JDK/bin like we can for any other Java installation.

Uh, What Now?

Now, you might be thinking about how to edit or build a Java 9 program since it’s not supported by major IDE’s or build tools yet. Not to worry: for purposes of just seeing what it can do, we can use a good ‘ol text editor and build with the javac command from the command line like we did back in the 90’s 😉 Once the code is written (see below, if you’re eager), we will build and run it like so:

javac; java Main

Hello World

It would be nice to build a “Hello World” with Java 9, but what can we build that we can only do in Java 9? One feature that caught my eye was JEP-102: Process API Updates, which has been sorely missed for years. So using this functionality seems like a nice first step and will let us try something Java-9-only, while still being immediately useful to us when Java 9 is released.

Finally: Java 9 is Here

Here is a complete class, feel free to copy and paste at will, and we will explore it a bit below:

import java.util.concurrent.CompletableFuture;
import java.util.function.BiConsumer;

public class Main {

   public static void main(String[] args) throws Exception {

	System.out.println("Hello Java 9! This process PID is " + ProcessHandle.current().getPid());

	ProcessBuilder builder = new ProcessBuilder("ls");

	Process process = builder.start();

	try (BufferedReader in = new BufferedReader(new InputStreamReader(process.getInputStream()))) {
	 	String line;
		while ((line = in.readLine()) != null) {

	// define a function to call when the child process ends
	// and block until that function completes
		.whenComplete( Main::mainFinished )


   public static void mainFinished(Process p, Throwable t) {
      System.out.println("process " + p.getPid() + " finished.");


What Just Happened?

ProcessHandle is a new class in Java 9, think of it as an extension of the Process class. For reference, you can read up on the Javadocs. ProcessHandle.current() returns the ProcessHandle object representing the current native process running this thread, and getPid() (as you might have guessed) returned the process ID of the native process. So if you want to know the PID of the currently running Java process, just call ProcessHandle.current().getPid(). Easy!

Next, we build a simple process, run it, and retrieve the output of it. This happens like any other Java program… nothing to see here, move along.

Finally, something interesting happens: The Java 9 Process class now provides an onExit() hook so we can execute a lambda when the native process has exited. In this case, we’ll just do something simple like write out the PID of the child process which just exited. Note that the main thread could finish before this lambda gets a chance to run, so we called CompletableFuture.get() to block the current thread until the onExit() lambda finishes.


Java 9 has a lot of new functionality that could prove to be very useful. This post is just to whet your appetite and show you how easy it is to get started with Java 9 TODAY! In future posts we will be exploring more of the functionality in Java 9… stay tuned!

Leave a comment

Filed under Java 9

Using EclipseLink with Spring Boot

The Promise

Spring Boot advertises in its self-introduction that one of its goals is to “Be opinionated out of the box, but get out of the way quickly as requirements start to diverge from the defaults.”

One thing that we might want to change from the defaults is the choice of JPA implementation. Hibernate is Spring Boot’s default JPA implementation, but EclipseLink (which is in fact the JPA Reference Implementation) is a good choice as well, and many people will have compelling reasons to choose it over Hibernate.

Does Spring Boot keep its promise to get out of our way if we want to deviate from the defaults? Let’s find out!

Put It To The Test

At one point there was an issue filed and resolved in the spring data examples project: people wanted an example demonstrating how to use EclipseLink in Spring Boot. So the eclipselink sample that came out of that is probably the best place to start.

It is a good starting point, but if we use Gradle we still have some work to do because the example uses Maven. We can actually start with the JPA project from’s Accessing Data With JPA guide as a starting point, and incorporate the basic changes from the eclipselink sample.
The first thing we’ll need to do is  add some configuration to provide the EclipseLink vendor adaptor. Note that this configuration is for the JpaBaseConfiguration from Spring Boot 1.4 (the class for Spring Boot 1.3 is a little different). In this class, the “eclipselink.weaving” property is set to false to eliminate any weaving configuration. This is maybe not what we’d want to do in production, but it makes the demo a bit simpler.

public class EclipseLinkConfiguration extends JpaBaseConfiguration {

   protected EclipseLinkConfiguration(DataSource dataSource, JpaProperties properties,
                     ObjectProvider<JtaTransactionManager> jtaTransactionManagerProvider) {
      super(dataSource, properties, jtaTransactionManagerProvider);

   protected AbstractJpaVendorAdapter createJpaVendorAdapter() {
      return new EclipseLinkJpaVendorAdapter();

   protected Map<String, Object> getVendorProperties() {

      // Turn off dynamic weaving to disable LTW (Load Time Weaving) lookup in static weaving mode
      return Collections.singletonMap("eclipselink.weaving", "false");

Changes to the build script are essentially excluding the Hibernate implementation of JPA and including the EclipseLink implementation.

dependencies {

   compile("org.springframework.boot:spring-boot-starter-data-jpa:1.4.0.M3") {
      exclude group: "org.hibernate", module: "hibernate-entitymanager"

   // .. other dependencies here

Finally, one issue with the original sample’s JPA Entity is that EclipseLink doesn’t like using a primitive long as a primary key, so we can change it to Long.

You can get all the source for this project the github.


On running, we see initialization output we’d expect, starting with

Building JPA container EntityManagerFactory for persistence unit 'default'
Initialized JPA EntityManagerFactory for persistence unit 'default'

and ending with

Closing JPA EntityManagerFactory for persistence unit 'default'

Running “gradle dependencies” and searching for hibernate in the output shows zero results, while doing the same for eclipselink clearly shows eclipselink being used

gradle dependencies | grep eclipse.persistence 

+--- org.eclipse.persistence:org.eclipse.persistence.jpa:2.6.3
| +--- org.eclipse.persistence:javax.persistence:2.1.1
| +--- org.eclipse.persistence:org.eclipse.persistence.asm:2.6.3
| +--- org.eclipse.persistence:org.eclipse.persistence.antlr:2.6.3
| +--- org.eclipse.persistence:org.eclipse.persistence.jpa.jpql:2.6.3
| \--- org.eclipse.persistence:org.eclipse.persistence.core:2.6.3
| +--- org.eclipse.persistence:org.eclipse.persistence.asm:2.6.3


Spring Boot got out of our way pretty quickly and easily once we wanted to move away from the default technology. We can consider the promise kept!

This is not the end of course. There is more to the configuration if we want our application to be ready for production, but this is a first step to using EclipseLink in a Spring Boot application. We can build on what else you would want to do in a future post!

Leave a comment

Filed under Software Engineering

Smaller Stories, Agile Journeys

This is a story of one company’s continuing journey to discover agility.


Let’s pretend there’s a company that has no concept of a “Story”, small or otherwise. The description of work for the entire software product is “get it done.” Well, there are specs/etc, but you know what I mean. No part of the software is done until EVERYTHING is done. In this world, there are no stories, there’s just “The Thing You’re Working On” and the developers code like crazy until it’s done from their point of view. Then the developers “throw it over the wall” for QA to test it, and hope nothing comes back to bite them.

The result of this situation is that you can’t deliver anything until you can deliver everything. So if something changes or there’s a bug, or something is not done on time… The company is unable to deliver incremental value and they are basically sitting on lost revenue and lost feedback until they can deliver. Obviously this is not good from the company’s point of view. Can they do better?


The company then finds out about “Agile” and “Scrum.” So they start using sprints, user stories, product owners, etc, and everything is great! They even discover that smaller stories are easier to describe and easier to finish, so there is a push to make smaller stories, which is good right? That way you can develop one thing, QA it, develop another thing, QA it, and so on until the sprint is complete.

This is an improvement over waterfall, but they’ve just gone from throwing it over the wall to throwing it over smaller walls. In the beginning of the sprint, QA does not have much to do because they are waiting on development of stories to finish, and at the end of the sprint, developers do not have much to do because they are waiting on any bugs to come back and can’t start work yet on the next sprint. Can they do better?

Episode III: AGILE

Finally, the company finds out how to get the members of its co-located cross-functional teams to actually work together. With smaller well-defined stories in hand, team members with development skills and team members with testing skills are working together on Day One to get each story over the finish line. From they moment the team breaks from sprint planning to begin the sprint, they are engaged together with clarifying edge cases, coding, designing tests, more coding, writing automated tests, and even more coding. They recognize that if they have nothing to do, it’s because they’re missing something in how they should be working and collaborating in their team.


I really recommend reading “What Does QA Do on the First Day of a Sprint?” It paints what I think is a great picture with all the details about what this world can look like.

Which stage is your company in? How do developers and testers work together on your team?

Leave a comment

Filed under Software Engineering