Java on Backend Engineering Strategy Tools

JVM Languages

Wed, 03 Jun 2026 00:00:00 +0000

JVM-hosted languages beyond Java. Each trades something to gain something, and each found a niche where the trade made sense.

Java was enough. It still is. The honest reason to know Groovy, Scala, and Kotlin is not that they are better — it is that the ecosystem puts them in front of you whether you choose them or not. Build tools, CI pipelines, and frameworks make that decision for you.

A practical tell: if the Java code you are reading starts to feel syntactically off — closures where you did not expect them, type inference that seems too aggressive, operators that should not be there — you are probably looking at Groovy, Scala, or Kotlin. Worth knowing enough to recognise each and get things done.

Also worth noting: Java itself has been catching up fast. Virtual threads, records, sealed classes, pattern matching, a faster release cadence — the gap between “Java” and “a more modern JVM language” has narrowed considerably. The case for leaving Java for something else on the JVM is weaker now than it was five years ago.

Groovy

Dynamic, optionally typed JVM language with a syntax that is a superset of Java. Groovy code is often valid Java. The dynamic parts — closures, metaprogramming, GStrings — are what made it popular as a scripting and DSL language.

Where you find it today:

Gradle build scripts: the Groovy DSL is the original Gradle scripting language (now being replaced by Kotlin DSL)
Jenkins pipelines: Groovy is the language of Jenkinsfile declarative and scripted pipelines
Spock framework: expressive BDD-style testing for JVM projects

Groovy’s peak was the early Gradle/Jenkins era. Kotlin has taken over most of the “better Java scripting” use cases. Still found widely in CI/CD tooling — if you work with Jenkins or older Gradle builds, you will write Groovy.

Groovy shows up in Gradle builds and Jenkins pipelines. Know enough to read and modify it; not a reason to seek it out.

Scala

Statically typed functional + OOP hybrid on the JVM. Strong type system, pattern matching, immutable data by default. Compiles to JVM bytecode and interops with Java libraries.

Where you find it today:

Apache Spark: the dominant big data / data engineering platform is written in Scala and has a native Scala API
Akka: actor model concurrency framework
Play Framework: web framework, less common now
SBT: build tool, build definition is Scala code

Scala has a reputation for complexity and a steep learning curve. The community split between Scala 2 and Scala 3 (Dotty) added friction. If you are working with Spark, you will encounter Scala. If you are not, the reasons to choose it over Kotlin or Java are narrower than they used to be. Another case where Java catching up makes the trade less obvious.

Kotlin

JetBrains’ answer to Java’s verbosity. Statically typed, concise, null-safe by design. Full Java interop — Kotlin and Java can call each other in the same project. Official Android development language since 2017.

Where you find it today:

Android development (the default)
Spring Boot (first-class support since Spring 5)
Gradle Kotlin DSL (replacing Groovy as the recommended build script language)
Ktor — Kotlin-native web framework from JetBrains

Kotlin is what you reach for when you want Java but less of it. Coroutines handle async cleanly. The Kotlin DSL in Gradle gives type safety that the Groovy DSL could not.

Kotlin is the cleanest of the JVM alternatives — but again, Java has been closing the gap. Worth knowing if the project is already Kotlin; not a compelling reason to switch from Java.

Jython

Python running on the JVM. Jython implements the Python language but executes on the JVM, meaning Python code can import and use Java classes directly.

Worth knowing it exists. In practice: Jython implements Python 2 (Python 3 support was never completed), which limits its relevance post-2020. Main use case was embedding Python scripting in Java applications. A few enterprise tools and test frameworks still use it.

If you need Python-JVM interop today, consider alternatives: GraalVM’s polyglot API, or just making an HTTP boundary between a Python service and the JVM service.

AWS CDK

Mon, 01 Jan 2024 00:00:00 +0000

AWS CDK (Cloud Development Kit) lets you define infrastructure using real programming languages — Java, TypeScript, Python — rather than a DSL. You write code, CDK synthesizes it into a CloudFormation template, and CloudFormation deploys it to AWS.

The appeal is obvious if your team lives in Java: familiar language, familiar tooling, loops and abstractions, unit tests with JUnit. No HCL to learn.

In practice it is slower and more cumbersome than it looks, and the CloudFormation layer underneath causes real problems.

How it works

Write Java (imperative)
mvn package — compile and run unit tests
cdk synth — generate the CloudFormation template
cdk diff — compare deployed stack with current state (optional)
cdk deploy — deploy stack to AWS via CloudFormation
CloudFormation makes the API calls to AWS

The key thing to understand: CDK does not talk to AWS directly. It generates CloudFormation, and CloudFormation does the work. Everything downstream of cdk synth is CloudFormation behaviour, not CDK behaviour.

The CloudFormation problem

CloudFormation does not track changes made outside of stacks. Someone logs into the console and modifies a security group — CloudFormation does not know, your CDK code does not know, and cdk diff will not show it. That is drift, and it accumulates silently until a deployment overrides something that was manually changed in production, or a cdk destroy removes something that was depended on.

CloudFormation does have a drift detection feature, but it is not part of the normal workflow — you trigger it manually from the console, it shows you the diff, and then expects you to go fix it yourself.

Compared to Terraform, which maintains its own state file and surfaces drift explicitly in terraform plan, this is a meaningful operational weakness.

Cross-stack dependencies

Splitting infrastructure into smaller stacks is the right instinct — smaller blast radius, faster deploys, clearer ownership. The problem is how CloudFormation handles values shared between stacks.

When Stack A exports a value (a VPC ID, a security group ARN) and Stack B imports it, CloudFormation creates a hard dependency. You cannot modify or delete that export while any other stack is consuming it. CloudFormation will block the update and leave you stuck — Stack A cannot deploy because the export is in use, and Stack B may be in a broken state because it depends on something that no longer exists as expected. Getting out requires carefully coordinating the removal of the import before you can change the export.

The fix: use SSM Parameter Store instead of CloudFormation exports.

Stack A writes its outputs to SSM:

StringParameter.Builder.create(this, "VpcIdParam")
 .parameterName("/infra/vpc/id")
 .stringValue(vpc.getVpcId())
 .build();

Stack B reads from SSM at deploy time:

String vpcId = StringParameter.valueForStringParameter(this, "/infra/vpc/id");

No CloudFormation export, no hard dependency, no blocked deployments. Stacks can be updated and deployed independently. SSM also gives you a clean place to browse shared infrastructure values and reference them from outside CDK (application config, scripts, other tools).

Testing

Testing in CDK is limited to validating the synthesized CloudFormation template — you are not testing infrastructure behaviour, you are testing that your code generates the JSON you expect:

Unit tests — JUnit assertions against the synthesized template (e.g. “does this stack contain an S3 bucket with versioning enabled”)
Integration tests — deploy to an isolated environment and validate via AWS SDK
No native plan/apply preview; you must deploy to see what actually happens

Pros

Familiar Java constructs — loops, conditionals, reusable classes
Full IDE support, refactoring, type safety
Unit testing with JUnit
Good for teams already invested in Java who want infrastructure close to application code

Cons

Generates CloudFormation — debugging complex stacks means reading generated JSON/YAML
More boilerplate than HCL for straightforward infrastructure
Drift detection relies on CloudFormation, which has no visibility into out-of-band changes
Importing existing infrastructure can be awkward
Smaller community example base compared to Terraform, especially in Java vs TypeScript/Python
Deployments are slower than Terraform’s direct API approach

vs Terraform

For repeatable, standardised infrastructure with a clear plan/apply workflow and reliable drift detection, Terraform is the stronger choice. CDK makes sense when infrastructure is deeply coupled to application code and the team is committed to a single language across both.

Resources

AWS CDK documentation
AWS CDK API reference
CDK Patterns — community example library
AWS CDK GitHub

Code Quality & Architecture Analysis

Mon, 01 Jan 2024 00:00:00 +0000

Static analysis catches bugs and code smells before they reach production. Architecture analysis catches structural decay before the codebase becomes unmaintainable. SonarQube does the former; Structure101 does the latter.

SonarQube

A code quality and security platform. SonarQube runs static analysis on your codebase and reports bugs, code smells, security hotspots, and test coverage in a web dashboard. It supports 30+ languages; the Java and Kotlin analysis is particularly deep. Integrates into CI pipelines via the SonarScanner — a quality gate can fail the build if new code introduces issues above a configured threshold.

# Run analysis (from project root, after configuring sonar-project.properties)
sonar-scanner \
 -Dsonar.projectKey=my-project \
 -Dsonar.sources=src/main \
 -Dsonar.tests=src/test \
 -Dsonar.host.url=https://sonarqube.example.com \
 -Dsonar.token=$SONAR_TOKEN

Quality gates define the conditions a project must meet — for example: no new critical bugs, test coverage on new code ≥ 80%, no new security hotspots unreviewed. A gate failure blocks the PR merge or CI pipeline. The built-in “Sonar Way” gate is a sensible default; most teams customise it over time.

SonarQube Community Edition is free and covers the core analysis features. Enterprise Edition adds branch analysis, portfolio views, and security reports.

Structure101

An architecture analysis tool for Java projects. Structure101 visualises the dependency structure of a codebase as a layered graph and identifies violations — circular dependencies between packages, classes depending on layers they shouldn’t reach, packages with too many inbound dependencies. It is particularly useful for large, long-lived Java codebases where architectural boundaries have eroded over time.

The key report is the tangle metric: a tangle is a group of packages with circular dependencies, and the tangle percentage measures how much of the codebase is affected. A clean architecture has zero tangles. Structure101 shows exactly which dependencies create each tangle, making it possible to systematically break them.

It integrates with build systems (Maven, Gradle) to enforce architecture rules in CI — build fails if the tangle percentage exceeds a threshold, or if a dependency violates a defined layering rule.

Resources

IntelliJ IDEA

Mon, 01 Jan 2024 00:00:00 +0000

IntelliJ IDEA is JetBrains’ Java and Kotlin IDE. It has the deepest language understanding of any Java IDE — code completion that reasons about types across the entire project, refactoring that updates all call sites, a debugger with expression evaluation, and a profiler integrated into the same window. The free Community Edition covers Java, Kotlin, Groovy, and Scala. The paid Ultimate Edition adds frameworks (Spring, Quarkus, Micronaut), database tools, HTTP client, and built-in support for web technologies.

Key capabilities

Refactoring — rename a class and every reference in every file updates. Extract method, inline variable, move class to a different package, change method signature — all with full project-wide impact analysis before execution.

Navigation — Cmd+Click goes to declaration, Cmd+B shows all usages, Cmd+E opens recent files, Cmd+Shift+F searches across the entire project. In a large codebase, knowing where things are called from matters more than reading the code.

Inspections — real-time static analysis flags potential bugs, code style violations, and anti-patterns as you type, not at build time.

Debugger — set breakpoints, step through code, evaluate arbitrary expressions in the current scope, watch variables, set conditional breakpoints. Remote debugging attaches to a running JVM with a single click.

Plugins

The plugin ecosystem extends IDEA significantly. Notable ones:

IdeaVim — vim key bindings throughout the editor
Kubernetes — YAML editing with schema validation and cluster connectivity
Database tools (Ultimate) — query databases from within the IDE

Remote development

IDEA supports JetBrains Gateway for remote development — the IDE UI runs locally but the indexing and execution happen on a remote machine or container. Useful for developing against large codebases on powerful remote hardware.

Resources

Java

Mon, 01 Jan 2024 00:00:00 +0000

Java is my primary language for backend services. Mature ecosystem, strong tooling, and frameworks like Spring Boot and Quarkus make it productive for building production-grade APIs and microservices.

Tooling

IDE: IntelliJ IDEA — the standard for Java development. Excellent refactoring, code analysis, and framework support (Spring, Quarkus, Jakarta EE). The free Community edition covers most needs; Ultimate adds Spring-specific tooling and database tools.

Build: Gradle or Maven — Gradle is the least bad option; keep the build file focused on compile, test, and package only. See Build Systems for the full take.

Frameworks

Spring Boot — the dominant choice for enterprise Java. Convention over configuration, huge ecosystem, production-ready out of the box.

Quarkus — optimized for containers and GraalVM native compilation. Noticeably faster startup and lower memory footprint than Spring Boot. Worth considering for microservices running in Kubernetes.

Testing with JUnit

JUnit 5 is the standard testing framework. Combine with Mockito for mocking and AssertJ for readable assertions.

@Test
void shouldReturnGreeting() {
 var service = new GreetingService();
 assertThat(service.greet("Manfred")).isEqualTo("Hello, Manfred");
}

Spring Boot’s @SpringBootTest and @WebMvcTest slice annotations make integration testing straightforward without spinning up a full application context.