Under många år har Java-utveckling ofta betytt att vi lägger till ett ramverk eller bibliotek så fort ett nytt behov uppstår. Det har varit rationellt, och jag har gjort likadant. Men Java-plattformen har vuxit, språket har blivit bättre och priset för mekanisk kod har sjunkit. Därför har jag börjat fundera på en fråga jag inte har ett färdigt svar på: hur mycket av det vi brukar lägga till behöver vi fortfarande?
01 · Tanken
Det här handlar inte om att Spring är problemet
Spring Boot löser många svåra problem, och gör det bra. För publika API:er, säkerhet, avancerad routing, observability och stora integrationsytor är Spring antagligen fortfarande det billigaste alternativet totalt sett.
Men Spring har blivit så självklart att jag misstänker att vi ibland når efter det även när problemet är mindre än lösningen. Det är den misstanken jag vill undersöka här.
En liten intern tjänst behöver kanske bara några HTTP-anrop, en databas, ett utgående anrop och lite affärslogik. I Java 25 finns redan HTTP-klient, JDBC, schemaläggning, records, loggning, JFR/JMX och moderna samtidighetsverktyg. Virtuella trådar gör dessutom vanlig, blockerande kod betydligt mer attraktiv för I/O än den var för några år sedan.
02 · Förvaltningsytan
Kanske är beroenden lite av ett isberg
När vi tittar på en pom.xml eller build.gradle ser vi bara en del av systemets tekniska yta. Under den finns transitiva bibliotek, versionskopplingar, autokonfiguration, proxyer, annotation processing och konventioner som någon behöver förstå den dagen något går fel.
Att räkna JAR-filer känns därför som ett trubbigt mått. En liten extern dependency kan vara mycket billig. Fyrahundra rader egen OAuth-kod kan vara mycket dyr.
Med minimalism menar jag alltså inte minst kod eller noll bibliotek. Snarare mindre onödig semantik – mindre teknik som teamet behöver bära över tid.
03 · Ett förslag på ordning
Tänk om vi frågade i den här ordningen?
I stället för att börja med frågan “vilket bibliotek ska ersätta detta?” skulle man kunna gå igenom fyra steg. Ju längre åt höger vi kommer, desto mer specialiserad semantik väljer vi att låta någon annan äga. Ordningen är ingen sanning – mest ett sätt att göra valet medvetet.
04 · Var Spring kanske passar bäst
Tänk om Spring fick bo vid kanten?
Den idé jag själv tycker är mest intressant handlar inte om att ta bort Spring Boot. Den handlar om att kanske sluta låta Spring vara applikationens huvudsakliga programmeringsmodell.
Min tanke är att om kärnan är fri från Spring blir nästa beslut mindre dramatiskt. En komplex tjänst kan lugnt stanna på avskalat Boot. En liten intern tjänst skulle senare kunna gå längre mot ren JDK. En batch eller worker behövde kanske aldrig Spring från början. Men det är just en tanke – jag vet inte hur väl den håller i era system.
05 · Några saker jag är nyfiken på
Allt behöver nog inte behandlas lika
Lombok och mappare
Records och explicit kod gör att en del av den mekaniska hjälpen känns mindre värdefull än den gjorde tidigare.
Utgående HTTP
JDK HttpClient verkar räcka långt för vanlig service-to-service-kommunikation.
Spring DI
Konstruktorinjektion behöver ingen container. Samtidigt kan en stor och dynamisk objektgraf mycket väl motivera Spring.
JPA / Hibernate
För tydlig SQL och en begränsad modell kan JDBC vara enklare. För rika objektgrafer är ORM antagligen fortfarande billigare.
JSON och säkerhet
Generell JSON-parsning och OAuth/OIDC bär på svår semantik som sällan bör bli egen infrastruktur.
Connection pool
JDBC finns i JDK, men en produktionsmässig pool gör det inte. HikariCP känns som ett självklart kvarvarande beroende.
06 · Vad skulle vi vinna?
Om det stämmer handlar det om förvaltningskostnad
Det som skulle göra idén värd något är inte ett snyggare dependency tree. Det är om teamet över flera år får mindre teknik att koordinera, färre lager att förstå och mindre påverkan när plattformen uppgraderas. Och det är förstås ett antagande som behöver prövas.
| Om vi minskar… | Skulle vi kanske få… | Men bara om… |
|---|---|---|
| Externa dependency families | Färre separata versions- och uppgraderingsspår | Vi inte ersätter dem med stora interna ramverk |
| Spring-typer i domänen | Mindre påverkan av ramverksuppgraderingar och enklare tester | Gränserna mellan kärna och adapters är tydliga |
| Runtime-magi | Synligare kontrollflöde och enklare felsökning | Den explicita koden förblir liten och begriplig |
| Överdriven standardisering i kod | Mindre lokal infrastruktur | Organisationen fortfarande standardiserar viktiga kontrakt och driftbeteenden |
07 · En sak som kan ha ändrats
Mer kod kan ibland betyda mindre system
AI gör det billigare att skapa mekaniska mappare, JDBC row-mappers, config records, adapters, tester och repetitiva decorators. Om det stämmer minskar värdet av abstraktioner vars viktigaste bidrag är att vi slipper skriva några rader.
Samtidigt gör AI knappast protokoll, kryptografi, parsergränsfall, concurrency eller transaktionssemantik mindre farliga. Det går snabbt att generera en anslutningspool. Det betyder inte att teamet borde äga en.
08 · Så här långt har jag kommit
Kanske handlar minimalism mest om att välja ansvar
Jag ser ingen poäng i att göra “noll Spring” till en trosbekännelse. Däremot tror jag att det finns något i att göra varje dependency medveten.
En liten tjänst skulle kanske klara sig på JDK:s HTTP-server. En komplex publik tjänst kan gott stanna på WebMVC och Spring Security. En worker kan kanske vara nästan ren Java. Det gemensamma vore att affärslogiken får vara vanlig Java och att specialistbibliotek hålls vid tydliga gränser.