Designprinciper för Jakarta EE

I detta inlägg kommer vi belysa sju sunda designprinciper från Java EE, som Jakarta EE borde ta tillvara på, utvalda av Java Champion Sebastian Daschner. Jakarta EE, eller som det ibland kallas EE4J, börjar så sakteliga ta form. För den som inte hängt med på de senaste svängarna i Java EE-världen så är Jakarta EE namnet på framtidens Java EE. Namnbytet grundar sig i att Oracle lämnar över rodret för både Java EE 8 samt GlassFish till Eclipse Foundation (men Oracle behåller rättigheterna till namnet Java).

1. Affärslogik först

Jakarta EE bör fortsätta den trend som Java EE satt. Det vill säga en programmeringsmodell som låter utvecklarna fokusera på det de borde fokusera på: affärslogiken. Vi som kodar behöver inte bemöda sig med att utöka API-klasser; vi kan skriva domänlogiken i rena Java-klasser och styra applikationsserverns beteende deklarativt via annoteringar.

Referens-implementationerna å sin sida tar bort mycket av de tekniska krav som finns utöver affärslogiken, som t.ex. trådhantering, transaktioner och HTTP-anropshantering.

2. Konvention över Konfiguration

Se till att fortsätta ha en konvention som innebär minimalt (ingen) med konfiguration för normalfallet, men fortsätt erbjuda konfigurationsmöjligheter för komplexa scenarion.

3. Interoperabilitet mellan specifikationer

Som utvecklare ska jag kunna förvänta sig att separata specifikationer jobbar väl tillsammans, helst utan någon konfiguration. Ett exempel på detta idag är att Bean Validation, JAXB eller JSON-B kan användas i JAX-RS resursklasser utan någon extra konfiguration.

import javax.validation.Valid;
import javax.ws.rs.Consumes;
import javax.ws.rs.Path;
import javax.ws.rs.POST;
import javax.ws.rs.Produces;

@Path("demo")
public class DemoResource {
    
    @POST
    @Produces("application/json")
    @Consumes("application/json")
    public void save(@Valid Demo demo) {
        // do stuff
    }
	...
}

4. Beroendeinjektion (Dependency Injection)

Eftersom JSR-299 Contexts and Dependency Injection for the Java EE Platform samt JSR-330 Dependency Injection for Java redan finns så bör framtida specifikationer, där möjligt, nyttja kraften av dessa och i första hand den enklare JSR-330.

Ett exempel där det finns förbättringspotential är när det gäller att injicera JAX-RS’s UriInfo till resursmetoder. Idag stöds nämligen inte @Inject (från JSR-330) för att injicera denna typ.

5. Deklarativ approach

Dagens Java EE APIer möjliggör definiering av olika funktioner på deklarativ väg genom Inversion of Control. Rent konkret innebär det att vi som utvecklare inte anropar funktionerna direkt utan att det görs via containern baserat på vad som är kodmässigt definierat. Exempel på detta är JAX-RS och JSON-B samt de flesta modernare specifikationer.

6. Installationsstrategier

Att utvecklare jobbar uteslutande mot APIer vilka sedan inte ingår i den artefakt som byggs/installeras kan ses som en stor fördel. Eftersom artefakten hålls tunn så går hela leveranspipelinen snabbare (byggande, publicering och installation).

Idealet vore om artefakten endast innehåller den egna affärslogiken. Runtime implementationer och tredjepartsbibliotek skulle då levereras i ett underliggande lager, t.ex. i applikationsserverns bibliotek som har lagts till i ett tidigare container bygg-steg.

7. Testbarhet

Genom att följa ovan nämnda designprinciper möjliggörs förbättrad testbarhet av affärskoden. Detta eftersom vi utvecklare inte behöver utöka API-klasser eller anropa obskyra funktioner som annars behöver mockas bort på ett eller annat sätt när vi ska skriva våra testfall. Det bli helt enkelt lättare att skriva relevanta testfall.

Slutsats

Välgenomtänkta och väldefinierade designprinciper som spänner över hela Java EE plattformen är en av huvudanledningarna till att Java EE fått så stor spridning världen över. Det är viktigt att Jakarta EE fortsätter på denna inslagna väg för att fortsätta vara konkurrenskraftigt och ett förstahandsval för Enterprise Javautvecklare.

För den vetgirige länkar vi här till den ursprungliga artikeln, Jakarta EE Design Principles, skriven av Sebastian Daschner.

Kanske har ni några ytterligare designprinciper ni tycker borde tas i beaktande? Hör av er till oss!

Tillbaka till bloggen