Languages
Java Development Company
The platform you choose when the system has to still be correct, auditable and changeable in ten years, and somebody will be held responsible if it is not.
Overview
Java has been running production systems continuously since the mid-1990s, and that unbroken record is the entire argument. It is the platform you reach for when software has to keep working long after the team that wrote it has moved on, when a regulator may one day ask exactly what the system did and when, and when an outage is measured in fines and headlines rather than apologies. Underneath the language sits the JVM, which is plausibly the most thoroughly exercised runtime ever built: three decades of real workloads, world-class garbage collectors, a just-in-time compiler that optimises code while it runs, and observability hooks that let you profile a live production incident without taking the system down to do it.
The interesting thing about Java is not novelty. It is that the platform has modernised substantially without breaking the code you wrote a decade ago. Records removed most of the boilerplate from data carriers. Sealed types and pattern matching let you model closed sets of possibilities and handle them exhaustively, with the compiler checking that you did. Virtual threads changed the concurrency calculus outright, so you can write straightforward blocking code that scales like asynchronous code without the callback machinery. A six-month release cadence delivers this steadily, while the backwards-compatibility promise means upgrades are usually boring, which is the highest compliment you can pay an upgrade.
The way to evaluate Java honestly is on total cost over the life of the system rather than on time to first deploy. On day one, almost every popular alternative gets you running faster. Java asks for more ceremony up front: explicit types, a build system, a project structure, a runtime to tune. What it returns is the third year and the fifth. A large Java codebase stays legible because the types tell you what things are. Refactoring across it is safe because the compiler and the tooling genuinely understand the code. The libraries you depend on are still maintained. Security patches still arrive. Engineers who can work on it are still easy to hire. If your software has a short life, that bargain is a bad one and we will say so. If it does not, it is often the most rational choice available.
We treat Java as an operational commitment rather than a line on a capability list. We run JVM services, tune them, page ourselves when they misbehave, and carry the consequences of the architectural decisions we made. That changes what we optimise for. We design for the engineer who inherits the system, for the incident at an inconvenient hour, and for the regulatory question asked two years after the feature shipped. This page is our honest working view of a platform we rate highly and do not recommend for everything.
Best for: Long-lived, high-stakes back-end systems: banking and payments, insurance and claims, large enterprise platforms, high-throughput event and transaction processing, and modernisation of existing JVM estates, where reliability, auditability and maintainability outrank raw time to first deploy.
Why teams choose Java
Failure modes that are already documented
A mature runtime, strong static typing and a catalogue of hardened libraries mean fewer novel surprises in production. When something does go wrong, the behaviour is usually well understood, well documented and has been diagnosed by thousands of engineers before you, which is exactly what you want at two in the morning on a system that moves money.
Verbosity that pays you back as readability
Java asks you to say what you mean. Explicit types, clear structure and tooling that genuinely comprehends the code make a large codebase navigable years later, when nobody remembers why a decision was made. What reads as ceremony in a code review reads as documentation in year four.
Performance that improves while it runs
The JIT compiler observes the running program, identifies the hot paths and recompiles them into tightly optimised machine code informed by real execution profiles. A service that has been warm for a while routinely outperforms its own first minute, and for sustained throughput a warmed JVM is genuinely difficult to beat.
Concurrency without the cognitive tax
Virtual threads let one process carry a very large number of in-flight requests while your code stays simple, sequential and debuggable. You get the scaling characteristics of asynchronous programming without the stack traces that tell you nothing and the control flow you cannot follow.
A supply chain with accountability behind it
Long-term-support releases receive security patches for years, multiple vendors provide builds and formal support contracts, and vulnerabilities are triaged and communicated by people whose job that is. For regulated industries, being able to point at a maintained, patched, contractually supported platform is a real deliverable.
Why businesses choose Java
- The system must be correct, auditable and supportable for years rather than merely functional at launch, and somebody will be formally accountable for that.
- You want a hiring pool measured in millions and a platform that major vendors will support and patch for the long haul.
- You need proven performance under sustained concurrent load rather than fast one-off invocations, and you have the traffic to justify the distinction.
- You operate in a regulated environment where a predictable, documented patch cadence and formal support are part of what you must demonstrate.
- You already have a JVM estate, and building with it rather than beside it avoids a second operational world that somebody has to staff.
- You value boring, predictable upgrades over the excitement of adopting a new runtime every eighteen months.
What we build with Java
The capabilities this technology is genuinely strong at, and what we most often build with it.
The JVM as a tunable platform
World-class garbage collectors, adaptive JIT compilation and deep runtime instrumentation, all configurable against your workload. G1 is a sound balanced default. ZGC and Shenandoah exist for the cases where pause times are non-negotiable and are worth the tuning effort. The point is that the runtime is not a black box: you can measure it, reason about it and change its behaviour deliberately.
Virtual threads
Lightweight threads scheduled by the JVM rather than the operating system, so a single process can hold an enormous number of concurrent blocking operations without exhausting OS threads. This matters more than it sounds: it lets high-concurrency services be written in plain sequential code, which means the stack traces are real, the debugger works, and a new engineer can follow the logic on their first day.
The Spring ecosystem
Spring Boot and the wider portfolio provide dependency injection, data access, security, messaging, batch processing and cloud integration as coherent production-grade components rather than a pile of glued-together packages. We use it heavily and keep it at the edges of the system rather than letting its annotations soak into the domain, because framework independence in the core is what makes the core testable and durable.
A type system that models domains properly
Generics, records, sealed interfaces and pattern matching let you express a domain so that illegal states are hard to represent and exhaustive handling is checked by the compiler. In a payments or claims system that is not academic. It is the difference between a case nobody considered failing at compile time and failing in front of a customer.
Precise decimal and temporal handling
BigDecimal for money, with explicit scale and rounding rather than floating-point approximation, and a date and time API that handles time zones, offsets and durations correctly. These sound unremarkable until you have debugged a financial discrepancy caused by a language that treated currency as a double.
Deep observability
Java Flight Recorder captures detailed runtime behaviour with overhead low enough to leave running in production. JMX exposes live internals. Every major APM vendor has a mature agent. Combined, they mean you can answer "why is this slow right now" with evidence rather than hypothesis, which is a capability many platforms simply do not offer.
Mature testing and integration tooling
JUnit and the surrounding ecosystem, plus Testcontainers for running real PostgreSQL, Kafka or Redis instances inside your test suite. Testing against the actual database rather than an in-memory imitation removes an entire family of bugs that only appear after deployment, and it is a standard we hold to.
Batch and event processing
Spring Batch for large scheduled processing, and first-class Kafka support for event-driven architectures, with the transaction handling and exactly-once semantics these domains demand. A great deal of the world’s overnight financial processing runs on this stack, and it does so because the failure handling is thorough rather than optimistic.
GraalVM native images
Ahead-of-time compilation to a native binary with fast startup and a much smaller memory footprint, at the cost of longer builds, restrictions around reflection and a narrower compatibility surface. We evaluate it honestly per workload rather than treating it as either a silver bullet or a curiosity, because for some services it genuinely changes the economics.
Use cases
Payments, ledgers and settlement
Systems where money moves and every movement must be attributable, reconcilable and provable after the fact. Precise decimal arithmetic, strong transaction handling, mature messaging and a runtime whose behaviour under load is well understood are the reasons this domain settled on Java and has largely stayed there.
Insurance, claims and underwriting platforms
Sprawling domains with intricate rules that change as regulation and products change. Strong typing and clear module boundaries keep these systems modifiable across the years in which the rules will certainly change, and make the impact of a change something the compiler can help you assess.
High-throughput transaction and event processing
APIs and event consumers handling sustained heavy concurrent traffic, where a warmed JVM and mature concurrency primitives keep tail latencies predictable. Tail latency, not average latency, is what customers actually experience, and it is where the JVM’s maturity shows.
Enterprise integration and back-office platforms
ERP-adjacent systems, order management, logistics and supply chain, and the integration layers that connect them to everything else in an estate. Java’s connector and messaging ecosystem is unmatched here, and the systems it links to are frequently JVM-based themselves.
Modernising existing Java estates
Elderly application servers, unsupported JDKs, frameworks past end of life, and a codebase nobody feels safe changing. Incremental modernisation, adding tests around risk, upgrading in stages, extracting components where it genuinely helps, is some of the highest-value work available in this space and a large part of what we do.
Back ends for mobile and partner ecosystems
The server side of products serving mobile clients and third-party integrators, where authentication, versioned contracts, rate limiting and long-term API stability matter, and where sharing models and tooling with a Kotlin Android client removes a translation layer.
When Java is the right choice
- Right when you are building a core system where correctness and auditability outrank shipping this week. Ledgers, payment engines, settlement, risk platforms, claims processing, billing. Domains where a rounding error or a lost message is a reportable event rather than a bug ticket.
- Right when the codebase will outlive its authors and must stay legible and safely changeable for a decade. Static types, explicit structure and tooling that understands the code are what make a large system approachable years after the original context has evaporated.
- Right when you have genuine concurrency: sustained heavy request volumes, long-lived connections, large parallel processing workloads. The JVM’s concurrency primitives are mature, well understood and now considerably easier to use well since virtual threads arrived.
- Right when you already run on the JVM or work in an organisation that standardises on it. Building with the grain of an existing estate, its libraries, its operational knowledge, its security tooling and its hiring, is worth a great deal more than the theoretical superiority of a different language.
- Right when you need formal support arrangements, long-term security patching and a hiring pool measured in millions. In regulated settings the predictability of the supply chain around the platform is often the deciding factor rather than any property of the language itself.
- Wrong for very short-lived processes. Functions that start, do one small thing and exit pay Java’s startup and warm-up cost on every invocation. Unless you invest in native compilation, Go or Node will serve that workload better, and we would rather tell you that than sell you a workaround.
- Wrong for small scripts, glue and exploratory data work. Java’s ceremony earns its keep on large long-lived systems and is pure overhead on a hundred-line job. Python is the better answer there and it is not close.
- Wrong when time to market genuinely dominates everything else and the product may not exist in eighteen months. If you are testing whether anyone wants the thing at all, optimise for finding out, not for the tenth year of a system that may never have one.
Java: pros and cons
Strengths
- Exceptional long-term stability. The backwards-compatibility promise means upgrades rarely break working code, and that turns platform maintenance from a project into routine work.
- The deepest mature library and tooling ecosystem of any back-end platform, with genuine commercial support available where you need it.
- Strong static typing catches whole categories of error at compile time, and makes large-scale refactoring safe rather than frightening.
- Observability is unusually good. Flight Recorder, JMX and mature agents from every major vendor let you see inside a running production system at negligible cost.
- Virtual threads give high-throughput I/O concurrency while keeping code straightforward and stack traces meaningful.
- Precise decimal arithmetic, a rigorous memory model and mature transaction handling, which is a large part of why financial systems keep choosing it.
- A very large hiring pool across every region and seniority level, which materially reduces the risk of owning a long-lived system.
Trade-offs
- It is verbose. Simple things take more lines than they would in Go, Kotlin or TypeScript, and while modern features such as records and pattern matching have narrowed the gap considerably, they have not closed it. On a small system that verbosity is a cost with no corresponding return.
- Startup and warm-up cost real time. A JVM has to load classes, initialise the runtime and let the JIT compiler observe execution before it reaches full speed. For a long-running service this is irrelevant. For a serverless function invoked briefly and often it is a recurring tax, and GraalVM native images are the answer only if you accept longer builds and a narrower compatibility surface.
- Memory footprint is heavy relative to compiled alternatives. A modest Java service will comfortably use more RAM than an equivalent Go binary, and at fleet scale that arrives as an infrastructure bill rather than an error message.
- The JVM needs tuning, and defaults are not always right for your workload. Choosing a garbage collector, sizing the heap, understanding pause behaviour and reading a Flight Recorder profile are real skills. Nothing forces you to acquire them until latency becomes a problem, and by then you are learning under pressure.
- Ecosystem breadth means genuine choices to make, and some corners are dated. There are several ways to do most things, some of them are twenty-year-old conventions kept alive by inertia, and a team without opinions can accumulate an incoherent stack surprisingly quickly.
- Spring is powerful and it is not free. Its dependency injection, auto-configuration and annotation-driven behaviour do a great deal of work implicitly, and when something misbehaves you can find yourself debugging framework magic rather than your own code. Startup time and memory both reflect its weight.
- Distribution licensing needs attention. The runtime is open source, but not every vendor’s build carries the same terms for production use, and organisations have found themselves with an unexpected commercial exposure by installing whichever JDK came to hand. This is a solved problem, but only if somebody solves it deliberately.
- Build times on large projects can be slow enough to affect how the team works. Incremental compilation and build caching help substantially, but a large multi-module Java build is not the fast feedback loop you get from a smaller ecosystem.
Building on the JVM
We design Java systems as layered services with explicit boundaries: a domain core that knows nothing about frameworks, adapters for persistence and messaging, and thin transport layers for HTTP or events. The rule we hold firmly is that Spring annotations do not belong in the domain. The valuable part of the system, the rules that describe how your business actually works, should be testable with a plain unit test, no context to start, no container to boot, no mocking framework required. That single constraint keeps test suites fast, keeps the logic honest, and means the domain survives whichever infrastructure fashion arrives next.
Module structure follows the domain rather than the technical layer. Grouping every controller together and every repository together produces a project where any single feature is scattered across the tree and no boundary means anything. Grouping by capability, with a deliberately narrow interface between capabilities, produces a project where you can reason about a change locally and where extracting a service later is a project rather than an excavation.
The runtime is part of the architecture, not a deployment detail. We choose garbage collectors against the workload profile, size heaps and thread pools against measured behaviour rather than folklore, and set the container memory limits and JVM ergonomics so the two agree with each other, because a JVM that does not know it is in a constrained container will size itself for the whole machine and be killed for it. Where cold start genuinely matters, we assess GraalVM native compilation on its merits, weighing faster startup and smaller footprint against longer builds and reflection constraints.
For data we default to PostgreSQL with connection pooling sized deliberately, real constraints in the schema rather than only in application code, and transactions scoped tightly around the work that must be atomic. For anything asynchronous, Kafka where the ordering and replay semantics earn their keep, with idempotent consumers and a genuine dead-letter strategy designed in from the start. Distributed systems fail in ways monoliths do not, and the failure handling has to be designed rather than discovered.
Performance under sustained load
Java’s performance story is about the long game, and understanding that shapes where it is the right choice. The JIT compiler watches your code execute, identifies the hot paths, and recompiles them into optimised machine code using profile information a static compiler never has access to. It will inline aggressively, eliminate branches it observes are never taken, and specialise for the types actually flowing through. A service that has been under real traffic for a while therefore performs considerably better than its own first minute, and for long-lived processes the JVM lands within touching distance of native code without the memory-safety hazards.
The trade-off is precisely the mirror image, and we are candid about it. Startup and warm-up are real costs. A process that spins up, handles one request and exits pays them in full every time and receives none of the benefit. For that shape of workload, vanilla Java is the wrong tool, and the honest options are native compilation or a lighter runtime. We would rather recommend Go for a particular function than defend a poor fit because it is on our list of capabilities.
Tuning is measurement, never folklore. We profile with Flight Recorder against production-shaped load, look at allocation rates on hot paths because garbage collection cost is mostly a function of how much garbage you create, and examine pause distributions rather than averages, since a good mean with a bad ninety-ninth percentile is what customers actually complain about. Most of the wins we find are not in exotic JVM flags. They are in an N plus one query pattern, an unbounded cache, a thread pool sized wrong, or a synchronous call to a slow dependency sitting in the middle of a request path.
Virtual threads have changed the standard advice for I/O-heavy services meaningfully. Where you previously had to choose between a large thread pool that consumed resources and a reactive stack that consumed comprehensibility, you can now write blocking code and let the runtime multiplex it. That said, they are not a universal upgrade: code holding synchronised locks or calling into native libraries can still pin a carrier thread, and pooling assumptions built around scarce threads need revisiting. It is a genuine improvement that repays being applied deliberately rather than reflexively.
Security and supportability
Enterprise Java benefits from a security ecosystem that few platforms can match. Spring Security handles authentication and authorisation with well-trodden patterns for OAuth, OpenID Connect, SAML and method-level access control. The cryptography libraries are mature and reviewed. Dependency scanning wires into Maven or Gradle so a vulnerable transitive library is caught in the build rather than in a disclosure email. Strong typing quietly removes a category of injection and coercion bug that dynamically typed stacks leave standing.
The supply chain around the platform is as important as the code, and in regulated settings it is often the deciding factor. LTS releases receive security patches for years. Multiple vendors ship builds and offer formal support contracts. Vulnerabilities are triaged and communicated through an established process. We build upgrade and scanning discipline to take advantage of that: staying on a supported LTS, applying patches on a cadence rather than an emergency, and keeping a genuine inventory of what is deployed rather than what the build file suggests.
Java has its own historical sharp edges and we treat them as rules rather than preferences. Native deserialisation of untrusted data is a well-documented remote code execution vector and should not appear in new code at all. Logging frameworks taught the industry an expensive lesson about what a formatting string can be persuaded to do, and the lasting takeaway is that user-controlled data belongs in parameters, never in a format string, and that dependency currency is a security control rather than a hygiene preference. Reflection and dynamic class loading against untrusted input deserve the same suspicion.
For regulated systems we design the surrounding controls as features: audit logs that record who did what to which record and when, in a form that survives a later question. Least-privilege database credentials. Encryption in transit and at rest. Secrets from a managed store, never in configuration committed to a repository, and never printed into a log line during an incident. Retention and deletion implemented rather than intended. None of this is exotic, and all of it is considerably cheaper to build in than to retrofit under audit pressure.
Scaling out and up
Java scales vertically unusually well, and that is worth saying plainly because the industry default assumption is horizontal-only. A single well-tuned JVM instance can saturate a large machine and handle enormous concurrency, particularly now that virtual threads remove the OS thread ceiling on in-flight requests. In practice that often means fewer, sturdier nodes rather than a sprawl of tiny ones, which reduces coordination overhead, cuts the number of network hops in a request path, and makes the system substantially easier to reason about during an incident.
Horizontally, JVM services sit comfortably behind orchestration and cloud autoscalers, and the ecosystem for stateless scale-out is deeply mature: session state externalised, caching in Redis, event streaming through Kafka, connection pooling sized so a growing fleet does not exhaust the database long before it exhausts itself. The usual constraint at scale is not the application tier at all. It is the database connection limit, a shared cache, or a downstream dependency that does not scale with you, and finding that early is a load-testing exercise rather than a design assumption.
Autoscaling deserves a specific caveat with Java. Because the JVM warms up, an instance that has just started is slower than the fleet it joined, so scaling out in response to a traffic spike delivers capacity that is initially cold. If you scale reactively on a sharp spike you can find new instances making things worse before they make them better. We handle this by scaling ahead of predictable load, keeping warm headroom rather than running at the edge, and treating readiness as "warmed and serving well" rather than "process has started".
On architecture we are deliberately conservative about splitting systems. Java handles a well-structured modular monolith extremely well, and a single deployable with clean internal boundaries is easier to operate, easier to keep transactionally correct and easier to reason about than a constellation of services. When a genuine boundary exists, a component with a different scaling profile, a team that must deploy independently, a regulatory separation, we extract it deliberately with a clear contract and honest handling of the distributed failure modes it introduces. We will tell you when we think a split would cost more than it saves, because that is the more common case.
Java integrations & ecosystem
The technologies we most often pair with it. Each links to how we work with it.
How we build in Java
We start from the domain rather than the framework. Before any Spring configuration exists, we agree the model, the invariants and the failure modes, then encode them in types so the compiler enforces what a document otherwise merely asserts. This ordering matters more in Java than almost anywhere else, because the type system is the main thing you are paying for. A project that starts with controllers and works inwards ends up with business rules distributed across request handlers, and no amount of later refactoring fully recovers from that.
Delivery runs in small reviewed increments with a genuine test pyramid: fast unit tests around a framework-free domain core, focused integration tests against real PostgreSQL and Kafka in containers rather than in-memory imitations that behave differently from the real thing, and a deliberately thin layer of end-to-end checks that verify the wiring rather than duplicating the logic. Continuous integration runs all of it on every change, and a build that is slow enough to be routinely skipped is treated as a defect in its own right.
Because we operate what we build, non-functional concerns are part of the definition of done rather than a phase at the end. Structured logging with correlation identifiers so a request can be followed across services. Health and readiness endpoints that mean something. Graceful shutdown so a deploy does not drop in-flight work. Metrics on the things that actually indicate health rather than the things that are easy to count. Load testing against production-shaped data before launch rather than after the first bad day.
We keep dependencies lean and current, automate upgrades so they arrive as a steady trickle rather than an alarming flood, and stay on a supported LTS deliberately rather than by accident. And we leave behind documentation and runbooks pitched at whoever inherits the system, because on the timescales Java is chosen for, that person is not going to be us, and writing for them is part of the job rather than a courtesy.
The service behind it
Delivered throughCustom Software DevelopmentWhat we build with Java
The disciplines this technology most often shows up in, from a first build to taking over and stabilising an existing one.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Weighing up Java?
A short call with engineers who build in it and operate the result. If Java is the wrong tool for what you are doing, we would rather tell you now than bill you later.
Industries we use Java in
Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.
Also in Languages
Why teams choose us for Java
We operate what we build
We carry the pager for our own JVM services, so we design for the third year of production rather than the launch demo. Operability is a design input here: if a system cannot be observed, tuned and safely deployed at an awkward hour, it is not finished, whatever the feature list says.
Senior engineers only
You work directly with people who have shipped and run large JVM systems, including the parts that went wrong. No layers, no juniors billed as specialists, no learning on your budget. The person who models your domain is the person accountable for how it behaves under load.
Modernisation without the big-bang rewrite
A great deal of Java work is inherited rather than greenfield: an old JDK, a framework past support, a codebase nobody feels safe changing. We make change safe before we make it fast, adding tests and instrumentation around the risky parts, then modernise in stages. Rewrites of working software are usually the most expensive option available.
Honest about the trade-offs
If your problem is better served by Go, Node, Kotlin or a native runtime, we will tell you before you spend money. We choose Java when the long-lived, high-stakes properties genuinely matter, and we say plainly when they do not, because a recommendation you cannot trust in one direction is worthless in the other.
Typical timeline
- 01
Discovery
One to three weeks. Domain modelling, architecture, JDK and framework choices, integration and security review, and a costed plan with the genuine risks stated rather than smoothed over.
- 02
Foundations
Two to four weeks. Project structure, build and CI pipeline, observability, database and messaging wiring, and the first thin slice running end to end in an environment that resembles production.
- 03
Delivery
Ongoing iterations. Features built in reviewed increments, integration-tested against real infrastructure in containers, and demonstrated working every cycle rather than described as progressing.
- 04
Hardening
Two to three weeks. Load testing against production-shaped data, JVM and garbage collection tuning informed by profiling, security review, failure-mode testing, and a release plan with a rollback path that has actually been exercised.
- 05
Operate or hand over
Either a move into managed operation with on-call, patching and continued evolution, or a clean handover with runbooks and documentation written for the engineer who inherits it, which on Java timescales is the more important audience.
How pricing works
- A paid discovery and architecture engagement first. Domain modelling, architecture, runtime and framework choices, an integration and security review, and a costed delivery plan with the real risks named. It is fixed-price and it is yours, including if you decide to build it with somebody else.
- Fixed scope and price for a defined outcome where the requirements genuinely support it: a specific service, a migration, an integration, an audited component. Where we can carry the estimation risk fairly, we will.
- A monthly senior engagement for continuing delivery, with scope reviewed each iteration. Senior engineers only, no juniors billed as specialists, and no layer of account management between you and the people writing the code.
- Ongoing operation, patching and evolution priced as a straightforward monthly arrangement sized to the system. Long-lived Java systems need somebody who owns the JDK version, the framework upgrades and the dependency posture over time, and that ownership is cheap compared with a rescue upgrade five years late.
- Third-party costs, cloud infrastructure, managed databases, commercial JDK or middleware licences, monitoring tools, are billed to your own accounts at cost with no mark-up from us. You hold the contracts and the credentials, which also means you are never locked in by us holding them.
Hire Java engineers
Need Java capacity on your own team? We embed named senior engineers into your existing team (reporting to your leads, working in your rituals), so you add capacity without a hiring cycle.
Hire Java engineersCommon questions
Is Java still a sensible choice, or is it a legacy decision?
It is a deliberate choice, and the confusion usually comes from people who last used it many versions ago. The platform has modernised sharply: records, sealed types, pattern matching, virtual threads and a predictable six-month release cadence, all while keeping the backwards-compatibility promise that makes upgrades boring. For systems that must stay correct and supportable for a decade, it is frequently the most rational option on the table precisely because it is not chasing fashion. For a short-lived product where speed of iteration dominates, it is genuinely the wrong pick, and we will say that too.
Java or Kotlin for a new back end?
Both run on the JVM and interoperate freely, so it is rarely a hard fork and you are not locked out of either by choosing one. Kotlin is more concise, has null safety in the type system and is more pleasant for greenfield work, particularly if the team also does Android. Java has the larger hiring pool, the deepest institutional support, and the advantage that any JVM engineer can read it immediately. We help you decide based on your existing estate, your team and, most importantly, who will maintain the system in five years. We build in either without preference.
Which JDK should we run, and are there licensing implications?
Run a supported long-term-support release rather than whatever happened to be installed, and choose your vendor deliberately. Java itself is open source, but the terms attached to different vendors’ builds for production use are not identical, and organisations have found themselves with an unexpected commercial exposure simply by installing the first JDK they downloaded. There are well-maintained builds with straightforward open-source terms, and there are commercially supported ones where a support contract has genuine value in a regulated setting. The important part is that this is a decision somebody makes on purpose, with the answer written down, rather than one that happens by default on a build server.
Is Java too slow to start for serverless?
Vanilla Java is a poor fit for short-lived functions and we will not pretend otherwise, because class loading and JIT warm-up cost real time on every invocation and none of the adaptive optimisation benefit is realised before the process exits. If serverless is central to your architecture, there are two honest routes: compile to a GraalVM native image, which cuts startup dramatically at the cost of longer builds and constraints around reflection, or use a lighter runtime such as Go or Node for that specific workload. We optimise for your problem rather than for keeping everything in one language.
How much JVM tuning does a service actually need?
Less than folklore suggests, and more than the defaults assume in one specific area: containers. The most common real problem we find is a JVM that has not been told about its container memory limit, sizes its heap for the whole machine, and gets killed by the orchestrator under load. Beyond that, pick a garbage collector that matches the workload, G1 for balanced services, ZGC or Shenandoah where pause times are genuinely non-negotiable, and then tune from profiling rather than from a blog post. In our experience most latency problems are not JVM problems at all. They are query patterns, thread pool sizing or a slow synchronous dependency in the request path, and a flag will not fix any of those.
Do virtual threads mean we should stop using reactive frameworks?
For a lot of I/O-bound service code, yes, and that is a genuine relief. Reactive stacks existed largely because OS threads were scarce, and they charged for that scalability in readability, debuggability and stack traces that told you nothing useful. Virtual threads let you write plain blocking code and scale to very high concurrency. The caveats are real though: synchronised blocks and some native calls can pin a carrier thread, and pool sizing assumptions built around scarce threads need revisiting rather than inheriting. Reactive still earns its place where you need backpressure semantics and stream composition as first-class concepts. It is no longer the default price of concurrency.
Can you take over and modernise an existing Java system?
Yes, and it is a substantial part of our work. We start by understanding and instrumenting what exists rather than by proposing a rewrite: the JDK and framework versions and their support status, the dependency vulnerability position, where the tests are and are not, and which parts actually carry the business risk. Then we make change safe before we make it fast, adding characterisation tests around the dangerous areas, before upgrading in stages, retiring dead code and extracting components where doing so genuinely helps. Big-bang rewrites of working software are among the most expensive and highest-risk projects a business can commission, and we will argue against one unless the evidence is overwhelming.
Is Spring Boot always the right choice?
It is usually the right choice and it is not automatic. Spring Boot gives you an enormous amount of production-grade capability coherently assembled, and for most business systems that is exactly what you want. The costs are real: startup time, memory footprint, and a layer of implicit auto-configuration that can turn a simple problem into an afternoon of debugging framework behaviour. For small focused services, particularly where startup and footprint matter, lighter alternatives such as Quarkus, Micronaut or Helidon are worth genuine consideration. Whichever we use, we keep the framework at the edges and the domain free of it, so the choice remains a decision about infrastructure rather than a permanent commitment written through your business logic.
Building on Java?
Tell us what you are building and where it is stuck. A senior engineer reads it and gives you an honest read on whether Java is the right fit for the problem, or what we would reach for instead.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.