Java News and Code, Episode 13

Posted in Android, Java, Java News and Code with tags , , , , , , on August 16, 2017 by jstevenperry


Welcome to Java News and Code, where I tell you about interesting goings-on in the world of IT in general, and Java in particular.

And there’s always code.

On This Episode:

  • Java Still on top in the Tiobe Index (but falling)
  • Android O Final Preview
  • Code Talkthrough: Android and the Cloud


Java Still on Top (but Falling)

Screen Shot 2017-08-14 at 10.26.31 AM

According to the Tiobe index for August 2017, Java is at #1 and still has a commanding lead over all other languages. But its percentage score has fallen to about 13%, down from just over 19% a year ago.

And Java is not alone: the top 5 are all in decline from a year ago, with C at 6 1/2%, C++ at 5.6%, C# at 4.2%, and Python at 3.7%.

Scroll down on the page to see just how far ahead of the pack Java is:

Screenshot 2017-08-14 15.10.52

From the graph you can see Java had a similar drop back in 2004 from which it rebounded strongly, so maybe this is a temporary trend. Who can say?

If you want to see how the index is put together, you can visit this page.

The Tiobe index is put together during the first week of each month.

Make sure and check out the show notes page, where you can find this story, along with all the links in this episode of Java News and Code.

So be sure to check that out.

Android O Final Preview is Out

On July 24th, Android O Developer Preview 4 was made available.

The announcement on the Android Developer’s Blog, comes one month after the announcement of Developer Preview 3, which I told you about in episode 8 of Java News and Code.

Preview 3 contained some very nice features like simplified settings, battery life optimizations, and per app notifications.

Preview 4 is the final preview before the official O release later this summer:

Screenshot 2017-08-14 15.25.35

Preview 4 is a Release Candidate build of the Android O platform, and while it doesn’t have any new features, it contains the final system behaviors, bug fixes, and the final API (level 26).

Coming soon is also a new release of the Android Testing Support Library. The blog post says to stay tuned for more details coming soon.

And if you want to use Developer Preview 4, it’s recommended that you download Android Studio 3 Canary 1 as well, available in the Canary channel.

The show notes page has links to the blog post, download page, and lots more.

So be sure to check that out.

Code Talkthrough: Android and the Cloud

Finally, in today’s code talk through, I’d like to show you a recipe for building a RESTful web service application, deploying it to the Bluemix cloud as a Cloud Foundry application, and building an Android app to communicate with it.

The code I’ll show you is available in GitHub, and is from a recipe I wrote for IBM developerWorks called Android and the Cloud.

To follow along with the video, you will need a Bluemix account, JDK 8, Eclipse, WebSphere Liberty, and Android studio installed on your computer.

You will need three projects from GitHub also:

In today’s show, I’m just going to show you the high level steps.  The recipe walks you through it step-by-step if you’re interested in reproducing this yourself, which I hope you are.

Let’s get started.

First, clone the code from GitHub for the two web services projects.

git clone
git clone

Now import the code into Eclipse.

With the code in Eclipse, build the oDoTCore JAR file using Maven, specifying the install goal so the JAR file gets installed to your local Maven repository.

Next, build the OdotWrapper WAR file using Maven, specifying the package goal.

Locate the WAR file in the target directory, and copy it to the WebSphere Liberty droppins directory.

Start WebSphere Liberty in Eclipse.

To verify the WebService is working, go to a browser and access this URL


When you see the JSON message, you know you have everything built and packaged correctly.

Now I’ll bundle the WebSphere Liberty server, including the WAR file, and deploy it to Bluemix.

For this part I need my Bluemix credentials, and the route I want to deploy it to.

I’m going over this fast, I know, but this is just an overview. The recipe has all the details.

Once I’ve deployed the application to Bluemix, I can test it and make sure it’s running. Open a browser, and hit this URL:

Again, when I see the JSON message “Hello from the server side!” I know it’s up and running.

Now to build the code for the Android app, run the app in the Android Emulator, and access the Web Service running in Bluemix.

Don’t worry, we’re almost there!

First, pull the code from GitHub:

git clone

Now import the code into Android Studio, and run the code in the Android Emulator. Choose the virtual device you setup when you installed and smoke tested Android Studio. It takes a minute or two for the device to start.

When the device starts, it will load the application. If you don’t see the application, click the Run button again in Android Studio.

Verify that the URL is correct (if not, change the code and run it again), and click the Info floating action button to invoke the Ping method. If you get back a Toast message that looks like this, then you’re good to go:


Under the hood, the Android app receives the JSON message we saw earlier in the browser, and is rendering it as a Toast message.

Now click on the Refresh From Server button, and the list should fill with data:


And that’s how you connect an Android app to an application running in the Cloud!

The developerWorks recipe has the steps broken down in much more detail, so be sure to check that out.

That’s all for this episode of Java News and Code.

Make sure to visit the show notes page, click the subscribe button, and you’ll be notified each time a new episode comes out!


Injecting Parameters into JUnit 5 Unit Tests (@

Posted in Java, JUnit 5, Open Source, Software Development with tags , , , on August 10, 2017 by jstevenperry

Check out my first (hopefully of many!) post at Baeldung.

The post is called: Inject Parameters into JUnit Jupiter Unit Tests

If you’ve been wanting to make the move to JUnit 5, now is the time! JUnit 5 Release Candidate 2 is out (as of this writing), and the final release is getting closer every day!

I love writing about software testing. I believe as developers we don’t pay enough attention to unit testing (myself included), so it’s important to me to get the word out: unit testing is important!

There, I said it.


p.s., Keep checking back here for more information on JUnit, including tutorials, like this one I wrote for IBM developerWorks.

Vaadin 8 + WebSphere Liberty

Posted in Java, Software Development, Vaadin, WebSphere Liberty on July 19, 2017 by jstevenperry

Vaadin 8 is a super easy-to-use UI framework.

WebSphere Liberty is a robust application server.

I’ve mixed them together in this recipe, available from IBM developerWorks:

And check out the accompanying video too:



The JUnit Jupiter API

Posted in JUnit 5, Software Development with tags , , on July 17, 2017 by jstevenperry

Greetings to all. There has never been a better time to dive into JUnit 5 and the JUnit Jupiter API.

Why? Because JUnit is growing ever nearer to a GA release. On July 4th, 2017 JUnit 5 Milestone 5 was released.

So what does that mean for you? Well, if you have wanted to dive into JUnit 5, but have been reluctant, let me guide you.

In my JUnit 5 Tutorial series at IBM developerWorks, you can read all about the JUnit Jupiter API in Part 1, and in Part 2 move on to some of the more advanced features of JUnit.

Very exciting. Yes?

Start here. And enjoy!


Check out the video for Part 1 below:

Big Meaning (er, Big Data)

Posted in Big Data and Analytics, General, Software Development with tags on May 22, 2017 by jstevenperry

You’ve heard of Big Data, sure. But what does the term mean, anyway?

In this developerWorks Blog post, I opine at length (okay, not at length, it’s less than 1,000 words).

Bottom line: Big Data is about the MEANING derived from the data, more than anything else.



Spring Boot Basics

Posted in Java, Open Source, Software Development, Spring, Spring Boot with tags , , , on May 14, 2017 by jstevenperry

Hello, World! Would you like to learn Spring Boot? I have written a new tutorial for IBM developerWorks that shows you how to use Spring Boot.

The tutorial starts off with a simple Hello World (actually, Hello Spring Boot) application.

Then I crank up the volume and show you a more complicated use of Spring Boot with a Spring MVC application called SpringBootDemo.

You can access the tutorial at IBM developerWorks by clicking this link.

A video accompanies the tutorial. You can access it from the tutorial, view it embedded below, or click here to view it on YouTube.

Please let me know what you think. Thanks for reading!


JUnit 5 Demo – Maven

Posted in General, Java, JUnit 5 with tags , , , , on April 26, 2017 by jstevenperry

Greetings, JUnit fans!

Because tool vendors, in order to get the most out of JUnit, used
internal APIs, this caused JUnit maintainers some headaches in moving
JUnit forward, as explained in this article by Nicolai

JUnit 5 breaks new ground mainly because of its
built in separation of concerns into two areas:

  1. An API used to write tests
  2. A mechanism to discover and run those tests.

For that reason, JUnit 5 was split into three sub

  • JUnit Jupiter – the API to write tests
  • JUnit Platform – the API to discover and run tests
  • JUnit Vintage – provide backward compatibility to run JUnit 3 and 4 tests.

For this post, I’ll use Eclipse, but you should be able to use any IDE you like.

The code for this post is available from Github at this link:

I’ll clone the code first:

$ cd ~/home/projects/learn
$ git clone

Next, I’ll start Eclipse, and import the code.

  1. Go to File > Import…
  2. Choose Maven > Existing Maven Projects.
  3. Navigate to the folder where you cloned the github repo (in my case it’s ~/home/projects/learn/JUnit5MavenDemo).
  4. Click Finish.

The class under test is very simple:

package com.makotojava.learn.junit5.demo;

public class App {
  public long add(long[] operands) {
    // Compute the sum
    long ret = 0;
    if (operands == null) {
      throw new IllegalArgumentException("Operands argument cannot be null");
    if (operands.length == 0) {
      throw new IllegalArgumentException("Operands argument cannot be empty");
    for (long operand : operands) {
      ret += operand;
    return ret;

Next, let’s look at the JUnit5App class. I’ll show it in pieces and explain the pieces as I go. Please refer to the full code listing in your IDE if you need more context.

package com.makotojava.learn.junit5.demo;

import static org.junit.jupiter.api.Assertions.assertAll;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertThrows;

import org.junit.jupiter.api.AfterAll;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Nested;
import org.junit.jupiter.api.Test;
import org.junit.platform.runner.JUnitPlatform;
import org.junit.runner.RunWith;

@DisplayName("Testing using JUnit 5")
public class JUnit5AppTest {
  private App classUnderTest;
  public static void init() {
    // Do something before ANY test is run in this class

  public static void done() {
    // Do something after ALL tests in this class are run

  public void setUp() throws Exception {
    classUnderTest = new App();

  public void tearDown() throws Exception {
    classUnderTest = null;

Notice the JUnit package names all begin with org.junit.jupiter.api. The JUnit package names have changed.

Next notice the @RunWith annotation and its JUnitPlatform.class argument. This allows tests written using JUnit Jupiter to run with a tool (like Eclipse) that does not yet natively support JUnit 5.

There is also the @DisplayName annotation, which tells JUnit to use the String argument (e.g., “Testing using JUnit 5”) rather than the default, which is the fully qualified test class name.

Then there are these annotations:

  1. BeforeAll – tells JUnit to run this method once before all test methods have run.
  2. BeforeEach – tells JUnit to run this method before each test method.
  3. AfterEach – tells JUnit to run this method after each test method.
  4. AfterAll – tells JUnit to run this method once after all test methods have run.

Next, let’s look at the testAdd() method:

  @DisplayName("When numbers are > 0")
  public void testAdd() {
        () -> {
          // Test #1
          long[] numbersToSum = { 1, 2, 3, 4 };
          long expectedSum = 10;
          long actualSum = classUnderTest.add(numbersToSum);
          assertEquals(expectedSum, actualSum);
        () -> {
          // Test #2
          long[] numbersToSum = new long[] { 20, 934, 110 };
          long expectedSum = 1064;
          long actualSum = classUnderTest.add(numbersToSum);
          assertEquals(expectedSum, actualSum);
        () -> {
          // Test #3
          long[] numbersToSum = new long[] { 2, 4, 6 };
          long expectedSum = 12;
          long actualSum = classUnderTest.add(numbersToSum);
          assertEquals(expectedSum, actualSum);

First, we tell JUnit that this is a test method by annotating it with the @Test annotation.

Next, notice the assertAll() method. This actually runs three separate tests, each of which calls assertEquals to verify the actual result matches the expected result. No big deal, right? Well, if you’ve used JUnit 4, you know that if the first of these assertEquals() calls fails then the next two are simply not run. This is not the case with assertAll. All of the statements within the lambda are run, and the results are reported as a group.

Finally, I want to point out a new JUnit 5 annotation: @Nested. Take a look at this code from

  @DisplayName("When numbers to add are < 0")
  class NegativeNumbersTest {

    private App classUnderTest;

    public void setUp() throws Exception {
      classUnderTest = new App();

    public void tearDown() throws Exception {
      classUnderTest = null;

    @DisplayName("Three tests with numbers  {
            // Test #1
            long[] numbersToSum = { -1, -2, -3, -4 };
            long expectedSum = -10;
            long actualSum = classUnderTest.add(numbersToSum);
            assertEquals(expectedSum, actualSum);
          () -> {
            // Test #2
            long[] numbersToSum = { -20, -934, -110 };
            long expectedSum = -1064;
            long actualSum = classUnderTest.add(numbersToSum);
            assertEquals(expectedSum, actualSum);
          () -> {
            // Test #3
            long[] numbersToSum = new long[] { -2, -4, -6 };
            long expectedSum = -12;
            long actualSum = classUnderTest.add(numbersToSum);
            assertEquals(expectedSum, actualSum);

This annotation lets us create an inner test class within the main test class. This keeps the code more structured and orderly, while keeping code together that tests the same class under test.

The @DisplayName annotation helps as well, and the results of any tests run in the @Nested class are reported “indented” relative to the main test class.

The nesting can be arbitrary also. So you can create @Nested classes within @Nested classes (within @Nested classes, and so forth) to an arbitrary level of nesting, as you see fit, and as makes sense for what you’re trying to test.

One last thing I want to point out about @Nested classes: they may each have their own @BeforeEach and @AfterEach lifecycle methods. So if you need to do special initialization, for example, you can do that outside of the main class’ @BeforeEach and @AfterEach callbacks (which still run, by the way, so keep that in mind). Because of the way the @Nested inner classes are created, they may NOT have their own @BeforeAll and @AfterAll lifecycle callbacks. Sorry.

I hope you enjoyed this brief look at JUnit 5. Please check out the video below on my YouTube channel for a more complete look at the code.

Thanks for reading!