Project Lombok er et lille bibliotek, der kan bruges til at reducere mængden af Java-kogeplade, der ofte skrives til Java-klasser. Project Lombok gør dette via annoteringer, der kan føjes til Java-klassen, som almindelige metoder ønskes for. De fleste af kommentarerne er selvbeskrivende i deres navne: @Getter, @Setter, @EqualsAndHashCode, @ToString og @NoArgsConstructor er eksempler. I dette indlæg demonstrerer jeg, at jeg anvender enkle Lombok-kommentarer til at tilføje disse almindeligt skrevne metoder til en Java-klasse.
Her er en enkel klasse uden foruddefineret tilsidesat version af toString ().
toString-less Person.java
pakke dustin. eksempler; / ** * Enkel personklasse uden kedelplade. * * @forfatter Dustin * / offentlig klasse Person {privat streng efternavn; privat streng fornavn; } Når ovenstående klasse genereres, og dens implicit implicerede nedarvede (fra Object) tilString () -metode kaldes, ser output ud som det, der vises i det næste billede.
Vi kunne skrive en eksplicit toString () -metode eller bruge Project Lombok. Det næste kodestykke demonstrerer tilgangen til Project Lombok.
Person.java med Lomboks @ToString-kommentar
pakke dustin. eksempler; importere lombok.ToString; / ** * Enkel personklasse uden kedelplade. * * @forfatter Dustin * / @ToString offentlig klasse person {privat streng efternavn; privat streng fornavn; } Resultatet fra udskrivning af denne klasses indhold med en Lombok-leveret toString () vises derefter.
Der er en bedre repræsentation af toString () af personobjektet nu, men dets felter initialiseres stadig ikke, så vi ser kun nulværdier. Vi kan bruge Lombok igen til at oprette konstruktøren.
Person.java med Lomboks @AllArgsConstructor-kommentar
pakke dustin. eksempler; importere lombok.AllArgsConstructor; importere lombok.ToString; / ** * Enkel personklasse uden kedelplade. * * @forfatter Dustin * / @ToString @AllArgsConstructor offentlig klasse person {privat streng efternavn; privat streng fornavn; } Jeg kan nu (faktisk skal) overføre parametre ved instantiering af personobjektet. Resultaterne vises i det næste skærmbillede. I dette tilfælde viser min klientkode (Main.java) en kompileringstidsfejl i NetBeans, fordi NetBeans ikke mener, at der er en konstruktør i Person, der accepterer to strenge. På trods af de røde, skæve mærker bygger koden, når jeg beder NetBeans om at bygge den.
En klasse som Person.java er ofte en dataklasse, der skal bruges til sammenligninger og muligvis hashCode-baserede samlingsnøgler. Det er vigtigt at oprette lige (Object) og hashCode () -implementeringer korrekt og sørge for, at de oprettes sammen. Da der er standard lig og hashCode-metoder leveret af den overordnede objektklasse, vil Java-kode ved hjælp af Person-forekomster være i stand til at udføre lig og / eller hashCode, men de er sandsynligvis ikke det, man virkelig vil have. Når den primære eksekverbare klasse ændres til den næste kodeliste, ser vi output efter det, der fortæller os, at lighedssammenligningen udføres fuldstændigt baseret på identitet snarere end på indhold.
Main.java That Tests er lig med () Implementering
pakke dustin. eksempler; importere statisk java.lang.System.out; / ** * Simple Main til anvendelser Klasser fra Project Lombok. * * @forfatter Dustin * / offentlig klasse Main {public static void main (final String [] argumenter) {// final Person person = new Person (); endelig person person = ny person ("Miles", "Linda"); out.println (person); final String sameLastName = "Smith"; final String sameFirstName = "Sam"; endelig person person1 = ny person (sameLastName, sameFirstName); endelig person person2 = ny person (sameLastName, sameFirstName); hvis (person1.equals (person2)) {out.println ("Samme person!"); } andet {out.println ("Forskellige mennesker!"); }}} 
Dette er næsten aldrig det, der ønskes her. I stedet kræves en eksplicit lig med implementering. Jeg kan godt lide det faktum, at Lombok-kommentaren til dette, @EqualsAndHashCode, kun genererer begge disse sammen, fordi det ikke giver mening at udtrykkeligt tilsidesætte dem individuelt. Klasselisten Person.java vises derefter med tilføjelsen af @EqualsAndHashCode-kommentaren.
Person.java med @EqualsAndHashCode
pakke dustin. eksempler; importere lombok.AllArgsConstructor; importere lombok.EqualsAndHashCode; importere lombok.ToString; / ** * Enkel personklasse uden kedelplade. * * @forfatter Dustin * / @ToString @AllArgsConstructor @EqualsAndHashCode offentlig klasse Person {privat streng efternavn; privat streng fornavn; } Outputtet er bedre nu.
Jeg har stadig ikke en god måde at få adgang til hvert offentligt felt separat, hvis det er nødvendigt. For eksempel, hvis jeg ville gøre noget i min kode baseret på efternavn, har jeg ikke en god måde at komme til det uden at tage drastiske skridt. Jeg kan bruge Lombok her igen.
I dette eksempel antager vi, at vi antog, at kun personens efternavn kan ændre sig. På grund af denne antagelse giver vi kun en Lombok @Setter-kommentar til efternavn, men med en @Getter-kommentar for begge felter. Den ændrede personkode vises derefter.
Person.java med @Getter og @Setter
pakke dustin. eksempler; importere lombok.AllArgsConstructor; importere lombok.EqualsAndHashCode; import lombok.Getter; import lombok.Setter; importere lombok.ToString; / ** * Enkel personklasse uden kedelplade. * * @forfatter Dustin * / @ToString @AllArgsConstructor @EqualsAndHashCode offentlig klasse Person {@Getter @Setter privat String efternavn; @Getter privat streng fornavn; } Her er den opdaterede hovedklasse til at køre dette eksempel:
Main.java, der gør brug af New Setter / Getter
pakke dustin. eksempler; importere statisk java.lang.System.out; / ** * Simple Main til anvendelser Project Lombok-powered klasser. * * @forfatter Dustin * / public class Main {public static void main (final String [] argumenter) {// final Person person = new Person (); endelig person person = ny person ("Miles", "Linda"); out.println (person); final String sameLastName = "Smith"; final String sameFirstName = "Sam"; endelig person person1 = ny person (sameLastName, sameFirstName); endelig person person2 = ny person (sameLastName, sameFirstName); hvis (person1.equals (person2)) {out.println ("Samme person!"); } andet {out.println ("Forskellige mennesker!"); } endelig person tilgængeligPerson = ny person ("Garzminski", "Gary"); out.println ("Efternavnet er" + accessiblePerson.getLastName ()); out.println ("Fornavnet er" + accessiblePerson.getFirstName ()); //accessiblePerson.setFirstName("Grady "); accessiblePerson.setLastName ("Garfunkel"); out.println ("Det nye efternavn er" + accessiblePerson.getLastName ()); }} Jeg var nødt til at kommentere opkaldet for at indstille personens fornavn, så koden ville bygge. Det kører nu som vist i næste skærmbillede.
Det er sandsynligt, at denne samling af Lombok-annoteringer ville være almindeligt ønsket, især for dataorienterede klasser. Af denne grund leverer Project Lombok aggregerede kommentarer som @Data, der giver en samling af disse kommentarer. I dette tilfælde kunne jeg have fået meget lignende opførsel til de adskillige individuelle kommentarer, jeg leverede ved at bruge @Data. @Data-kommentaren fører til, at Lombok anvender @Getter i alle felter og @Setter i alle ikke-endelige felter. Den anden store forskel fra det, jeg brugte, er at den bruger @RequiredArgsConstructor snarere end @AllArgsConstructor.
En af de bedste måder at se, hvad Project Lombok har gjort med den kompilerede .class-fil, er at bruge javap. Dette vises i det næste skærmbillede.
Vi ser i denne output, at en masse af de metoder, der ofte ses en kedelpladekode, er tilgængelige i den kompilerede Person.class. Der er en to-argumenteret parameteriseret konstruktør, hashCode (), er lig med (Object), toString () og de forventede metoder til get og set.
Project Lombok er ikke uden bekymringer og begrænsninger. Mange af disse er formuleret som svar på Hamlet D'Arcy's indlæg Java Without the Boilerplate - Project Lombok. En begrænsning er den reducerede support i andre IDE'er end Eclipse (selvom der er anstændig NetBeans-støtte og javac understøttes). En bekymring er behovet for, at andre bruger og vedligeholder koden for at have en ny afhængighed af Lombok. Denne bekymring kan mildnes noget ved brug af delombok, som kan bruges i byggeprocessen, hvis det er nødvendigt.
Andre artikler og blogindlæg, der dækker Project Lombok, inkluderer Project Lombok - skriv aldrig Java Boilerplate-koden igen, Java uden kedelpladen - Project Lombok, Project Lombok: Bye Bye Boilerplate, Java Posses Project Lombok Interview, Project Lombok: Sæt en stopper for Java-ordligheden , Project Lombok - Et must-have i din Java Toolkit, Project Lombok: Interessante bønnegenveje med annotationsprocessor, Interview: Reinier og Roel på Lombok, Reduktion af kedelpladekode med Project Lombok, hurtig udvikling med Lombok, Lombok reducerer din kogepladekode og Bedre alternativ til Getters og Setters.
Denne historie, "Common Java Object Functionality with Project Lombok" blev oprindeligt udgivet af JavaWorld.
