Many software projects use 3rd party libraries aka “dependencies”. You often want to use the most recent version of these dependencies but how do you know when a new release of a dependency is published? The more dependencies your project have the more tiresome a manual approach to “tracking dependency updates” is.

In this post I explore some solutions that tracks dependency updates for you. I cover broad solutions (libraries.io and dependabot) and Java-only solutions (“artifact listener” and a Gradle/Maven plugin).

Why update?

But why do we want to update dependencies at all?

A new version of a dependency

  • may fix bugs that affects your project
  • may introduce new features that you could use
  • may fix a security issue that affects your project
  • may have other optimizations to the code

Of course there is a risk as well: a new version may introduce a bug that affects your project. Plus, there might be API changes that require changes in your code.

Tracking solutions

Renovate

(update) I now use renovatebot because it integrates nicely with Gitlab CI. Much like dependabot (see below), it scans “dependency files” like “build.gradle”, “pom.xml” or “package.json” and creates merge requests for dependency updates.

Libraries.io

From their own words

Libraries.io can automatically keep track of all of the packages that your repositories depend upon across many different package managers.

Once synced, Libraries.io will email you about new versions of your dependencies, if you add or remove a new dependency it will change the notifications settings for that package as soon as you push to your repositories.

Repositories on Github, Gitlab and Bitbucket are supported. Plus, you can subscribe to dependencies manually, ie without a repository on any of these platforms.

Beside email notifications you can also subscribe to an RSS feed of your dependency updates.

Libraries.io is an open source project.

artifact listener

Artifact Listener is a small service and only available for Java / Maven Central. You can search for libraries and “follow” them. Alternatively you can upload a POM and then choose which dendencies to follow. Updates of libraries you follow are emailed to you.

You can provide additional email adresses to notify, e.g, email addresses of other team members. This is a small but lovely feature for me.

The service is an open source project.

Dependabot

Dependabot checks the “dependency files” (where your dependencies are definied) in your Github repos for updates. If there is an update it creates a PR for it. The PR may contain links, release notes, a list of commits etc.

So this service not only notifies you about an update but even creates a PR that applies it. You just have to merge it (at least if your project is on Github).

Dependabout has been aquired by Github.com and is free of charge.

Gradle plugin

If you are using Gradle (a Java build system) to declare dependencies and build your project you can use the Gradle versions plugin to detect dependency updates and report them. It is easy to use. You just need to execute it on a regular basis.

Maven plugin

Of course, there is a similar plugin for Maven (another Java build system).

Our latest production issue: one morning our app kept crashing. Restart. Crash after some minutes. Out of memory.

It turned out to be a CLOB that was almost 2 GB big and got read when a user triggered a certain action. The 2 GB CLOB ended up in an almost 4 GB big char[] (because char is 16 bit in Java) and this was too much even for 8 GB heap space.

Of course that CLOB was not supposed to be that big!

It took some time to identify the root cause.

Our app runs on a Weblogic server (WLS) and talks to another WLS-hosted app via SOAP-Webservice.

When the other app was patched to a new version, some WS-requests failed indicating that the webservice in the other wanted to JNDI-lookup the previous version of something.

After we restarted our app everything worked fine. But still you don’t want to restart a client when the server was upgraded. Moreover, a spring-boot client did not have these problems.

It turned out that WLS uses a feature called “Context Propagation” that inserts an additional SOAP-Header into the request as well as the response. This header contains a serialized object. It indicated that our app transmits the version of the other app and apperantly the other app somehow uses that information in the JNDI lookup.

How does our app knows about the version number of the other app? Probably because the other apps sends that info in the response. This explains why it worked after we restarted our app: at first it hadn’t that information at all and when it got it, it was about the new version.

What I still can’t explain is that some request were successful before the restart.

The solution is to disable “context propagation” by using a system parameter:
weblogic.wsee.workarea.skipWorkAreaHeader=true

In the last post I reviewed Java lambda expressions. They represent a concise syntax to implement functional interfaces.

Enter Java method references. They represent a concise syntax to implement functional interface using existing methods. Like with lambda expressions, referenced methods are not allowed to throw checked exceptions.

Syntax

It’s simply “class-or-instance name” “::” “method name”, like

Function<String, Integer> string2Int = Integer::valueOf;

Types of method references

Reference to a static method

Static methods are referenced using the class name like in the example above.

Reference to an instance method of a particular object

Methods of a particular object are referenced using the variable name of that object:

Map<Integer, String> aMap = new HashMap<>();
Function<Integer, String> getRef = aMap::get;
// call it
String s = getRef.apply(42);

Reference to an instance method of an arbitary object of a particular type

Instead of using an already existing object you can just state the class and a non-static method. Then the instance is an additional parameter. In the following example toURI is a method with no arguments that returns a String. The function of this method reference takes a File (the object) and returns a String:

Function<File, URI> file2Uri = File::toURI;

Reference to a constructor

Constructors are references using its type and “new”:

Function<String, StringBuffer> bufferFromString = StringBuffer::new;

Here the constructor of StringBuffer with String parameter is referenced. Return type is the type of the constructor, parameters of the function are the parameters of the constructors.

 

 

Lambda expressions in Java represent “functions”, something that take a number of parameters and produce at most one return value.

This could be expressed with anonymous classes but lambda expressions offer a more concise syntax.

Syntax

Lambda expression consist of a parameter list, an “arrow” and a body.

(String s1, String s2) -> s1 + "|" + s2

The parameter list is enclosed in round brackets. Types are optional. When the expression has exactly one parameter, the brackets can be omitted.

s -> s!=null && s.length>0

The body can either be an expression (that returns a value) or a block. A block is a sequence of statements, enclosed in curly braces.

n -> { if (n<10) System.out.println(n); }

Lambda expressions and types

In the Java type system, lambda expressions are instances of “functional interfaces”. A functional interface is an interface with exactly one abstract method.

Functional interfaces in java.util.function

The package java.util.function in the JDK contains a number of functional interfaces:

  • Function<T,U>  represents a function with one parameter of type T and return type U
  • Consumer<T>  represents a function with one parameter of type T and return type void
  • Supplier<T>  represents a function with no parameter and return type T
  • Predicate<T>  represents a function with one parameter of type T and return type boolean

Plus, variants with “Bi” prefix exists that have two parameters, like BiPredicate . More variants exists for using primitive types like DoubleToIntFunction .

User defined function interfaces

Any interface with exactly one abstract method can be used as type of a lambda expression. You mark this interface with @FunctionInterface .

@FunctionalInterface
interface SomeInterface {
  int someBehaviour(String a, String b);
}

SomeInterface geo = (x,y) -> x.length + y.length;

Benefits

For me, the benefits of lambda expression are

  • concise syntax for anonymous classes that represent functional code
  • improved readability
  • encouragement of a more functional programming style

Answer: not static at all. A static inner class behaves like a normal class except that it is in the namespace of the outer class (“for packaging convenience”, as the official Java tutorial puts it).

So as an example:

public class Outer {
  private int x = 0;
  public int y = 1;
  
  static class Inner {
    //...
  }
}

As opposed to a true inner (nested) class, you do not need an instance of Outer to create an instance of Inner:

Outer.Inner inner = new Outer.Inner();

and Inner instances have no special knowledge about Outer instances. Inner class behaves just like a top-level class, it just has to be qualified as “Outer.Inner”.

Why I am writing about this?

Because I was quite shocked that two of my colleagues (both seasoned Java developers) were not sure if a static inner class was about static members and therefore global state.

Maybe they do not use static inner classes.

When do I use static inner classes?

I use a static inner class

  1. when it only of use for the outer class and it’s independent of the (private) members of the outer class,
  2. when it’s conceptionally tied to the outer class (e.g. a Builder class)
  3. for packaging convenience.

Often, the visibility of the static inner class is not public. In this case there is no big difference whether I create a static inner class or a top-level class in the same source file. An alternative for the first code example therefore is:

public class Outer {
  // ...
}
// not really inner any more
class Inner {
  // ... 
}

An example for (2) is a Builder class:

public class Thing {
  //...
  public static class Builder {
     // ... many withXXX methods
     public Thing make() // ...
  }
}

If the Inner instance needs access to (private) members of the Outer instance then Inner needs to be non-static.

In the light of the recent case of introducing malicious code through a popular JavaScript module on npm, I like to mention snyk.io .

In a simple, free of charge scenario, snyk.io scans build or dependencies files on your github or gitlab projects and periodically reports vulnerabilities. Snyk supports Node, Ruby, Java, Scala and Python projects.

If you pay for snyk.io, you get a lot more integrations, CLI and API access etc.

In my own trial I found that even for fairly recent spring boot and apache camel dependency tree there a dozen of high-rated vulnerabilities! (Many of them by using “com.fasterxml.jackson.core:jackson-databind@2.9.1”). So the next question is if it’s advisable to upgrade to a secure patch of – say – jackson-databind although I use it only indirectly – in other words: will the depended framework still work with the secure patch version?

An open-source alternative is OWASP-Dependency-Check. It scans Java and .Net dependencies, has experimental support for Python, Ruby, PHP (composer), and Node.js applications. The tool seems to be JVM-based. There is a SonarQube-plugin. I have not tried it myself.

In Java, a synchronized method is not thread safe if it reads from and writes to one or more static member variables.

Consider:

public class SomeClass {

  static int someCounter = 0;

  synchronized void doSomething() {
    for(int i = 0; i < 20; i++) {
      someCounter++;
      // do something that takes a bit of time, e.g.
      // java.net.InetAddress.getByName("www.wikipedia.org");
      System.out.println("counter="+counter);
    }
  }
}

and assume the access to someCounter is somehow thread safe because of the synchronized keyword on doSomething.
As soon as you call doSomething concurrently on multiple SomeClass instances, it will not print unique numbers. This is because the all instance share the same static member variables. Between the increment of someCounter and printing it, its value might have already changed by another instance.

That particular bug was a bit hidden because a “SomeClass” instance was “cached” in a JEE stateless session bean. Of course the JEE container creates multiple instances of the session bean and hence multiple instances of SomeClass.

If you want to stop the route you are currently using, you can’t do it using

context.stopRoute()

because it will wait for the current “inflight” message to be processed until “the end”.

So you need to do this async:

// ....
  private void shutdownRoute() {
    ShutdownRoute shutdownRoute = new ShutdownRoute(camelContext);
    new Thread(shutdownRoute).start();
    try {
      Thread.sleep(1000); // makes sure route is stop before this message finished 
    } catch (InterruptedException e) {
      // whatever
    }
  }
// ...

class ShutdownRoute implements Runnable {
  /** log instance */
  private Logger log = LoggerFactory.getLogger(ShutdownRoute.class.getName());
  
  private final CamelContext context;
  
  ShutdownRoute(final CamelContext cContext) {
    context = cContext;
    
  }
  
  @Override
  public void run() {
    try {      
      context.stopRoute(YOUR_ROUTE_ID);
    } catch (Exception e) {
      log.error("Failed to stop route",e);
    }
  }
}

We do this when using the circuit breaker pattern. In the error handling processor we check if the circuit breaker goes to the OPEN state. If so, the route stops itself. Via another route we check periodically if the circuit breaker is in the HALF-OPEN state and start the route again.