How static is a static inner class in Java?

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:

As opposed to a true inner (nested) class, you do not need an instance of Outer to create an instance of 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:

An example for (2) is a Builder class:

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

Checking your project dependencies for vulnerabilites

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.

A “synchronized method” bug

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

Consider:

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.

Apache Camel: how a route stops itself at runtime

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

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

So you need to do this async:

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.

Apache Camel: how to stop a message from being further processed

At one point in our latest project using Apache Camel, I wanted to stop a message from being further processed depending on a condition. This is quite easy to do with the route builder, for example:

If you already know that a message needs to be stopped right away in a Processor or a AggregationStrategy, there is an easy way to signal this without a seperate “stop-branch” in the route. You simply set the header ROUTE_STOP to TRUE like this:

And the message will not be further processed.