Classifying Iris Flowers with Deep Learning, Groovy™ and GraalVM

Deep learning falls under the branches of machine learning and artificial intelligence. It involves multiple layers (hence the "deep") of an artificial neural network. There are lots of ways to configure such networks and the details are beyond the scope of this blog post, but we can give some basic details. We will have four input nodes corresponding to the measurements of our four characteristics. We will have three output nodes corresponding to each possible class (species). We will also have one or more additional layers in between.

Each node in this network mimics to some degree a neuron in the human brain. Again, we’ll simplify the details. Each node has multiple inputs, which are given a particular weight, as well as an activation function which will determine whether our node "fires". Training the model is a process which works out what the best weights should be.

The math involved for converting inputs to output for any node isn’t too hard. We could write it ourselves (as shown here using matrices and Apache Commons Math for a digit recognition example) but luckily we don’t have to. The libraries we are going to use do much of the work for us. They typically provide a fluent API which lets us specify, in a somewhat declarative way, the layers in our network.

Just before exploring our examples, we should pre-warn folks that while we do time running the examples, no attempt was made to rigorously ensure that the examples were identical across the different technologies. The different technologies support slightly different ways to set up their respective network layers. The parameters were tweaked so that when run there was typically at most one or two errors in the validation. Also, the initial parameters for the runs can be set with random or pre-defined seeds. When random ones are used, each run will have slightly different errors. We’d need to do some additional alignment of examples and use a framework like JMH if we wanted to get a more rigorous time comparison between the technologies. Nevertheless, it should give a very rough guide as to the speed to the various technologies. One more caveat since this post was first written: the Encog and DeepLearning4J transcripts below are still the original 2022 runs on a Linux box, while the Deep Netts and GraalVM sections have been re-run on an Apple Silicon machine with Groovy 6.0.0-beta-2 and GraalVM CE 25. Compare numbers within a section, not across them.

Encog is a pure Java machine learning framework that was created in 2008. There is also a C# port for .Net users. Encog is a simple framework that supports a number of advanced algorithms not found elsewhere but isn’t as widely used as other more recent frameworks.

The complete source code for our Iris classification example using Encog is here, but the critical piece is:

When we run the example, we see:

We won’t explain all the stats, but it basically says we have a pretty good model with low errors in prediction. If you see the green and purple points in the notebook image earlier in this blog, you’ll see there are some points which are going to be hard to predict correctly all the time. The confusion matrix shows that the model predicted one flower incorrectly on the validation dataset.

One very nice aspect of this library is that it is a single jar dependency!

Eclipse DeepLearning4j is a suite of tools for running deep learning on the JVM. It has support for scaling up to Apache Spark as well as some integration with python at a number of levels. It also provides integration to GPUs and C/++ libraries for native integration.

The complete source code for our Iris classification example using DeepLearning4J is here, with the main part shown below:

When we run this example, we see:

Again the stats tell us that the model is good. One error in the confusion matrix for our testing dataset. DeepLearning4J does have an impressive range of technologies that can be used to enhance performance in certain scenarios. For this example, I enabled AVX (Advanced Vector Extensions) support but didn’t try using the CUDA/GPU support nor make use of any Apache Spark integration. The GPU option might have sped up the application but given the size of the dataset and the amount of calculations needed to train our network, it probably wouldn’t have sped up much. For this little example, the overheads of putting the plumbing in place to access native C++ implementations and so forth, outweighed the gains. Those features generally would come into their own for much larger datasets or massive amounts of calculations; tasks like intensive video processing spring to mind.

The downside of the impressive scaling options is the added complexity. The code was slightly more complex than the other technologies we look at in this blog based around certain assumptions in the API which would be needed if we wanted to make use of Spark integration even though we didn’t here. The good news is that once the work is done, if we did want to use Spark, that would now be relatively straight forward.

The other increase in complexity is the number of jar files needed in the classpath. I went with the easy option of using the nd4j-native-platform dependency plus added the org.nd4j:nd4j-native:1.0.0-M2:linux-x86_64-avx2 dependency for AVX support. This made my life easy but brought in over 170 jars including many for unneeded platforms. Having all those jars is great if users of other platforms want to also try the example, but it can be a little troublesome with certain tooling that breaks with long command lines on certain platforms. I could certainly do some more work to shrink those dependency lists if it became a real problem.

(For the interested reader, the groovy-data-science repo has other DeepLearning4J examples. The Weka library can wrap DeepLearning4J as shown for this Iris example here. There are also two variants of the digit recognition example we alluded to earlier using one and two layer neural networks.)

Deep Netts is a company offering a range of products and services related to deep learning. Here we are using the free open-source Deep Netts community edition pure java deep learning library. It provides support for the Java Visual Recognition API (JSR381). The expert group from JSR381 released their final spec earlier this year, so hopefully we’ll see more compliant implementations soon.

The complete source code for our Iris classification example using Deep Netts is here and the important part is below:

When we run this command we see:

(We leave the Groovy jar out of -cp here since the groovy launcher already puts it on the classpath; Groovy 6 warns about the duplication if you don’t.)

This run happened to classify the whole test set correctly, and the whole thing — JVM startup, Groovy compilation of the script, 3293 training epochs and evaluation — takes just under a second. This is to be expected given our small data set and isn’t indicative of performance for larger problems.

Another plus is the dependency list. It isn’t quite the single jar situation as we saw with Encog but not far off. There is the Deep Netts jar, the JSR381 VisRec API which is in a separate jar, and a handful of logging jars.

Another technology we might want to consider if performance is important to us is GraalVM. GraalVM is a high-performance JDK distribution designed to speed up the execution of applications written in Java and other JVM languages. We’ll look at creating a native version of our Iris Deep Netts application. We used GraalVM CE 25 (JDK 25) and Groovy 6.0.0-beta-2. We’ll cover just the basic steps but there are other places for additional setup info and troubleshooting help like here, here and here.

Groovy has two natures. Its dynamic nature supports adding methods at runtime through metaprogramming and interacting with method dispatch processing through missing method interception and other tricks. Some of these tricks make heavy use of reflection and dynamic class loading and cause problems for GraalVM which is trying to determine as much information as it can at compile time. Groovy’s static nature has a more limited set of metaprogramming capabilities but allows bytecode much closer to Java to be produced. When this post was first written, the recipe was to compile the script in static mode (groovyc --compile-static) and hope that the libraries in play went along with it.

That step is no longer needed. Groovy 6.0.0-beta-2 added an AOT link mode for invokedynamic dispatch (GROOVY-12234, with GROOVY-12227 covering closures). A native image can’t retarget a call site once it has been linked, and retargeting is exactly how Groovy’s dynamic dispatch installs its inline caches — which is what made dynamic Groovy a non-starter here. In AOT link mode each site instead links once, permanently, and cache freshness travels as data. The mode is detected automatically inside a native image, so there is nothing to switch on. Because it changes linking rather than compilation, it also means already-published indy-compiled jars become native-capable without being recompiled.

So we compile our script the ordinary way — no annotations, no flags, fully dynamic:

Next we run the application once under the native-image-agent, which records the reflective lookups and resource reads Groovy performs while registering its metaclasses. This step is still required — without the generated metadata the binary builds successfully but then fails initializing GroovySystem:

Then we build our native application:

That command is considerably shorter than the one this post used to show. Along with --compile-static, the following have all gone away: --report-unsupported-elements-at-runtime (a no-op for several GraalVM releases now), --no-fallback (now explicitly deprecated: "No effect, no replacement available"), and the two --initialize-at-run-time entries for GrapeIvy and RandomWeights (run-time initialization is the default for application classes these days). The blanket --initialize-at-build-time has to go too, and not merely for tidiness: forcing Groovy’s runtime to initialize at build time pulls its internal state into the image heap, which native-image rejects. On 6.0.0-beta-2 specifically it fails on the call-site cache’s PIC-Cleaner thread — a thread that GROOVY-12142 has since removed entirely — but the general point outlives that particular symptom, since a seeded Random in the image heap is rejected just the same. Run-time initialization is what the AOT link mode expects; just leave the flag off.

Now we are ready to run our application:

(Note that the log level is now passed when running the binary. A -D option given to native-image no longer bakes a system property into the image the way it once did.)

For the same work, on the same machine, that is 48ms against roughly 420ms for the same pre-compiled classes on the JVM, and around 900ms to run the script from source. And unlike the 2022 version of this post, we got there without giving up any of Groovy’s dynamic nature. It is worth being concrete about how much has changed: repeating this exact recipe with Groovy 5.0.6 produces a binary that builds cleanly and then dies on the first dynamic call, and adding --compile-static back doesn’t save it either — it fails inside the tap closure, whose delegate-based property assignment stays dynamic no matter how the enclosing script is compiled:

The honest limit of the new mode is steady-state dispatch rather than startup: with no JIT, every dynamic call site crossed in a native image costs a few microseconds, so a genuinely hot inner loop still wants @CompileStatic (statically compiled code crosses no dynamic sites at all). Training this little network doesn’t come close to that threshold. Runtime compilation — GroovyShell, Eval and friends — and dynamic proxy generation remain off the table in a native image regardless; the AOT link mode addresses dispatch, not code generation.

One caveat from the original version of this post has also expired. Deep Netts has log4j2 as one of its dependencies, and back then there were still issues using log4j2 with GraalVM, so we excluded log4j-core and routed through log4j-to-slf4j to sidestep the problem. log4j-core now ships its own GraalVM reachability metadata, and building this example against the stock dependency works fine. We still make the swap, but now only because slf4j-simple gives us a one-property knob for quietening the training log, as seen above.

We have seen a few different libraries for performing deep learning classification using Groovy. Each has its own strengths and weaknesses. There are certainly options to cater for folks wanting blinding fast startup speeds through to options which scale to massive computing farms in the cloud.