È sicuro utilizzare Project Lombok? [chiuso]

Nel caso in cui non si conosca Project Lombok aiuta con alcuni dei fastidi di Java con cose come la generazione di getter e setter con annotazioni e persino la semplice generazione di JavaBean come @Data . Potrebbe davvero aiutarmi, specialmente in 50 diversi oggetti evento in cui hai fino a 7 campi diversi che devono essere costruiti e nascosti con getter. Potrei rimuovere quasi mille righe di codice con questo.

Tuttavia, sono preoccupato che a lungo termine sarà una decisione deplorevole. Flamewars esploderà nel ##Java Freenodecanale quando lo menzionerò, fornendo frammenti di codice confonderà possibili aiutanti, le persone si lamenteranno della mancanza di JavaDoc e i futuri committenti potrebbero semplicemente rimuoverlo comunque. Mi piacerebbe molto il positivo, ma sono preoccupato per il negativo.

Quindi: è sicuro usare Lombok su qualsiasi progetto, piccolo o grande? Gli effetti positivi valgono gli aspetti negativi?

Sembra che tu abbia già deciso che Project Lombok ti offre significativi vantaggi tecnici per il tuo nuovo progetto proposto. (Per essere chiari dall'inizio, non ho opinioni particolari sul Progetto Lombok, in un modo o nell'altro.)

Prima di utilizzare Project Lombok (o qualsiasi altra tecnologia che cambia il gioco) in alcuni progetti (open source o altro saggio), è necessario assicurarsi che gli stakeholder del progetto siano d'accordo. Ciò include gli sviluppatori e tutti gli utenti importanti (ad esempio sponsor formali o informali).

Lei menziona questi potenziali problemi:

Flamewars esploderà nel canale ## Java Freenode quando lo menzionerò,

Facile. Ignora / non partecipare alle guerre di fiamma, o semplicemente astieniti dal menzionare Lombok.

fornire frammenti di codice confonderà possibili helper,

Se la strategia del progetto prevede l'uso di Lombok, i possibili aiutanti dovranno abituarsi.

la gente si lamenterà della mancanza di JavaDoc,

Questo è il loro problema. Nessuno nella loro mente giusta cerca di applicare rigidamente il codice sorgente / le regole di documentazione della propria organizzazione a software open source di terze parti. Il team di progetto dovrebbe essere libero di impostare il codice sorgente del progetto / gli standard di documentazione adeguati alla tecnologia utilizzata.

( FOLLOWUP - Gli sviluppatori di Lombok riconoscono che non generare commenti javadoc per metodi getter e setter sintetizzati è un problema. Se questo è un grosso problema per i tuoi progetti, allora un'alternativa è creare e inviare una patch Lombok per risolvere questo problema. )

e i futuri committenti potrebbero semplicemente rimuoverlo comunque.

Non è acceso! Se la strategia di progetto concordata prevede l'uso di Lombok, i committenti che de-Lombok devono gratuitamente castigare il codice e, se necessario, far ritirare i propri diritti di commit.

Naturalmente, questo presuppone che tu abbia ottenuto il buy-in dagli stakeholder ... inclusi gli sviluppatori. E presume che tu sia pronto a discutere la tua causa e a gestire in modo appropriato le inevitabili voci di dissenso.

Ho appena iniziato a usare Lombok oggi. Finora mi piace, ma uno svantaggio che non ho visto menzionato era il supporto al refactoring.

Se hai una classe annotata con @Data, genererà i getter e i setter per te in base ai nomi dei campi. Se usi uno di quei getter in un'altra classe, poi decidi che il campo ha un nome mediocre, non troverà gli usi di quei getter e setter e sostituirà il vecchio nome con il nuovo nome.

Immagino che questo dovrebbe essere fatto tramite un plug-in IDE e non tramite Lombok.

AGGIORNAMENTO (22 gennaio 13)
Dopo aver usato Lombok per 3 mesi, lo consiglio ancora per la maggior parte dei progetti. Tuttavia, ho trovato un altro svantaggio simile a quello sopra elencato.

Se si dispone di una classe, dire MyCompoundObject.javache ha 2 membri, sia annotata con @Delegate, diciamo myWidgetse myGadgets, quando si chiama myCompoundObject.getThingies()da un'altra classe, è impossibile sapere se si tratta di delegare al Widgeto Gadgetperché non è più possibile saltare alla fonte all'interno dell'IDE.

L'uso di Eclipse "Genera metodi delegati ..." offre le stesse funzionalità, è altrettanto rapido e consente di saltare alla fonte. Il rovescio della medaglia è che ingombra la tua fonte con codice boilerplate che toglie l'attenzione alle cose importanti.

AGGIORNAMENTO 2 (26 febbraio 13)
Dopo 5 mesi stiamo ancora usando Lombok, ma ho altri fastidi. La mancanza di un getter e setter dichiarati può diventare fastidiosa a volte quando stai cercando di familiarizzare con il nuovo codice.

Ad esempio, se vedo un metodo chiamato getDynamicCols()ma non so di cosa si tratta, ho alcuni ostacoli extra da saltare per determinare lo scopo di questo metodo. Alcuni degli ostacoli sono Lombok, alcuni sono la mancanza di un plug-in intelligente Lombok. Gli ostacoli includono:

• Mancanza di JavaDocs. Se avessi javadoc sul campo, spererei che il getter e il setter ereditassero quel javadoc attraverso la fase di compilazione di Lombok.
• Passa alla definizione del metodo mi porta alla classe, ma non alla proprietà che ha generato il getter. Questo è un problema con il plugin.
• Ovviamente non puoi impostare un breakpoint in un getter / setter a meno che non generi o codifichi il metodo.
• NOTA: questa ricerca di riferimento non è un problema come pensavo per la prima volta. Tuttavia, è necessario utilizzare una prospettiva che abiliti la vista Struttura. Non è un problema per la maggior parte degli sviluppatori. Il mio problema era che sto usando Mylyn che stava filtrando la mia Outlinevista, quindi non ho visto i metodi. Ricerca mancanza di riferimenti. Se voglio vedere chi sta chiamando getDynamicCols(args...), devo generare o codificare il setter per poter cercare riferimenti.

AGGIORNAMENTO 3 (7 marzo 13)
Imparando a usare i vari modi di fare le cose in Eclipse, credo. Puoi effettivamente impostare un breakpoint condizionale (BP) su un metodo generato da Lombok. Utilizzando la Outlinevista, è possibile fare clic con il tasto destro del mouse sul metodo Toggle Method Breakpoint. Quindi, quando si preme il BP, è possibile utilizzare la Variablesvista di debug per vedere come il metodo generato ha chiamato i parametri (di solito lo stesso nome del campo) e, infine, utilizzare la Breakpointsvista per fare clic con il pulsante destro del mouse sul BP e selezionare Breakpoint Properties...per aggiungere una condizione. Bello.

AGGIORNAMENTO 4 (16 agosto 13) A
Netbeans non piace quando aggiorni le tue dipendenze Lombok nel tuo pom Maven. Il progetto viene ancora compilato, ma i file vengono contrassegnati per errori di compilazione perché non sono in grado di vedere i metodi che Lombok sta creando. Svuotare la cache di Netbeans risolve il problema. Non sono sicuro se esiste un'opzione "Pulisci progetto" come in Eclipse. Problema minore, ma volevo farlo conoscere.

AGGIORNAMENTO 5 (17 gennaio 14)
Lombok non gioca sempre bene con Groovy, o almeno con groovy-eclipse-compiler. Potrebbe essere necessario eseguire il downgrade della versione del compilatore. Maven Groovy e Java + Lombok

AGGIORNAMENTO 6 (26 giugno 14)
Un avvertimento. Lombok è un po 'avvincente e se lavori su un progetto in cui non puoi usarlo per qualche motivo, ti infastidirà. Potresti stare meglio semplicemente non usarlo affatto.

AGGIORNAMENTO 7 (23 luglio 14)
Questo è un aggiornamento un po 'interessante perché riguarda direttamente la sicurezza dell'adozione di Lombok di cui l'OP ha chiesto.

A partire dalla versione 1.14, l' @Delegateannotazione è stata ridotta a uno stato Sperimentale. I dettagli sono documentati sul loro sito ( Lombok Delegate Docs ).

Il fatto è che se si utilizzava questa funzione, le opzioni di backout sono limitate. Vedo le opzioni come:

• Rimuovere manualmente le @Delegateannotazioni e generare / codificare a mano il codice delegato. Questo è un po 'più difficile se stavi usando gli attributi all'interno dell'annotazione.
• Delombok i file che hanno l' @Delegateannotazione e forse possono essere aggiunti nuovamente nelle annotazioni desiderate.
• Non aggiornare mai Lombok o mantenere un fork (o vivere con l'utilizzo di funzionalità esperienziali).
• Delombok l'intero progetto e smetti di usare Lombok.

Per quanto ne so, Delombok non ha un'opzione per rimuovere un sottoinsieme di annotazioni ; è tutto o niente almeno per il contesto di un singolo file. Ho aperto un biglietto per richiedere questa funzione con le bandiere Delombok, ma non me lo sarei aspettato in un prossimo futuro.

AGGIORNAMENTO 8 (20 ottobre 14)
Se è un'opzione per te, Groovy offre la maggior parte degli stessi vantaggi di Lombok, oltre a un carico di altre funzionalità, tra cui @Delegate . Se pensi che avrai difficoltà a vendere l'idea ai poteri che sono, dai un'occhiata alle annotazioni @CompileStatico @TypeCheckedper vedere se ciò può aiutare la tua causa. In effetti, l'obiettivo principale della versione Groovy 2.0 era la sicurezza statica .

AGGIORNAMENTO 9 (1 settembre 15)
Lombok è ancora attivamente mantenuto e migliorato , il che fa ben sperare per il livello di sicurezza dell'adozione. Le annotazioni di @Builder sono una delle mie nuove funzionalità preferite.

AGGIORNAMENTO 10 (17 novembre 15)
Potrebbe non sembrare direttamente correlato alla domanda del PO, ma vale la pena condividerlo. Se stai cercando strumenti che ti aiutino a ridurre la quantità di codice della caldaia che scrivi, puoi anche consultare Google Auto , in particolare AutoValue . Se guardi il loro mazzo di diapositive , elenca Lombok come una possibile soluzione al problema che stanno cercando di risolvere. I contro che elencano per Lombok sono:

• Il codice inserito è invisibile (non puoi "vedere" i metodi che genera) [ndr: in realtà puoi, ma richiede solo un decompilatore]
• Gli hack del compilatore sono non standard e fragili
• "A nostro avviso, il tuo codice non è più realmente Java"

Non sono sicuro di quanto concordi con la loro valutazione. E visti i contro di AutoValue che sono documentati nelle diapositive, starò con Lombok (se Groovy non è un'opzione).

AGGIORNAMENTO 11 (8 febbraio 16)
Ho scoperto che Spring Roo ha annotazioni simili . Sono stato un po 'sorpreso di scoprire che Roo è ancora una cosa e trovare documentazione per le annotazioni è un po' approssimativo. Anche la rimozione non sembra facile come de-lombok. Lombok sembra la scelta più sicura.

AGGIORNAMENTO 12 (17 febbraio 16)
Mentre cercavo di fornire giustificazioni sul perché sia ​​sicuro portare Lombok per il progetto al quale sto lavorando, ho trovato un pezzo d'oro che è stato aggiunto con v1.14- The Configuration System ! Ciò significa che è possibile configurare un progetto in modo da non consentire determinate funzionalità che il team ritiene non sicure o indesiderabili. Meglio ancora, può anche creare una configurazione specifica della directory con impostazioni diverse. Questo è bellissimo.

AGGIORNAMENTO 13 (4 ottobre 16)
Se questo genere di cose è importante per te, Oliver Gierke ritiene sicuro aggiungere Lombok a Spring Data Rest .

AGGIORNAMENTO 14 (26 settembre '17)
Come sottolineato da @gavenkoa nei commenti sulla domanda dei PO, il supporto del compilatore JDK9 non è ancora disponibile (Numero 985). Sembra anche che non sarà una soluzione facile per il team Lombok aggirare.

AGGIORNAMENTO 15 (26 marzo 18)
Il log delle modifiche di Lombok indica a partire dalla v.1.16.20 "La compilazione di lombok su JDK1.9 è ora possibile " anche se # 985 è ancora aperto.

Le modifiche per adattarsi a JDK9, tuttavia, hanno richiesto alcune modifiche sostanziali; tutto isolato alle modifiche alle impostazioni predefinite di configurazione. È un po 'preoccupante il fatto che abbiano introdotto modifiche di rottura, ma la versione ha solo superato il numero di versione "Incrementale" (passando da v1.16.18 a v1.16.20). Dato che questo post riguardava la sicurezza, se avessi un yarn/npmsistema di compilazione simile che si è automaticamente aggiornato all'ultima versione incrementale, potresti avere un brusco risveglio.

AGGIORNAMENTO 16 (9 gennaio 19)

Sembra che i problemi di JDK9 siano stati risolti e Lombok funzioni con JDK10 e persino con JDK11 per quanto ne so.

Una cosa che ho notato, tuttavia, che riguardava un aspetto della sicurezza è il fatto che il registro delle modifiche che va dalla v1.18.2 alla v1.18.4 elenca due voci come BREAKING CHANGE!? Non sono sicuro di come si verifichi un cambiamento sostanziale in un aggiornamento "patch" semver. Potrebbe essere un problema se si utilizza uno strumento che aggiorna automaticamente le versioni della patch.

Vai avanti e usa Lombok, puoi eventualmente "delombok" il tuo codice in seguito http://projectlombok.org/features/delombok.html

Personalmente (e quindi soggettivamente) ho scoperto che l'uso di Lombok rende il mio codice più espressivo su ciò che sto cercando di ottenere rispetto a IDE / implementazioni proprie di metodi complessi come hashcode e uguali.

Quando si usa

@EqualsAndHashCode(callSuper = false, of = { "field1", "field2", "field3" })

è molto più facile mantenere coerenti Equals & HashCode e tenere traccia dei campi valutati rispetto a qualsiasi IDE / propria implementazione. Ciò è particolarmente vero quando stai ancora aggiungendo / rimuovendo regolarmente i campi.

Lo stesso vale per l' @ToStringannotazione e i suoi parametri che comunicano chiaramente il comportamento desiderato per quanto riguarda i campi inclusi / esclusi, l'uso di getter o l'accesso ai campi e se o non chiamare super.toString().

E ancora annotando un'intera classe con @Gettero @Setter(AccessLevel.NONE)(e facoltativamente sovrascrivendo qualsiasi metodo divergente) è immediatamente chiaro quali metodi saranno disponibili per i campi.

I vantaggi continuano ...

Nella mia mente non si tratta di ridurre il codice, ma di comunicare chiaramente ciò che desideri ottenere, piuttosto che doverlo capire da Javadoc o dalle implementazioni. Il codice ridotto semplifica l'individuazione di implementazioni con metodi divergenti.

Lombok è fantastico, ma ...

Lombok infrange le regole dell'elaborazione delle annotazioni, in quanto non genera nuovi file sorgente. Ciò significa che non può essere utilizzato con altri processori di annotazione se si aspettano che i getter / setter o qualsiasi altra cosa esistano.

L'elaborazione delle annotazioni viene eseguita in una serie di round. In ogni round, ognuno ottiene un turno per correre. Se vengono trovati nuovi file java dopo il completamento del round, inizia un altro round. In questo modo, l'ordine dei processori di annotazione non importa se generano solo nuovi file. Poiché lombok non genera alcun nuovo file, non vengono avviati nuovi round, quindi alcuni AP che si basano sul codice lombok non vengono eseguiti come previsto. Questa è stata un'enorme fonte di dolore per me durante l'utilizzo di mapstruct, e delombok-ing non è un'opzione utile poiché distrugge i numeri di riga nei registri.

Alla fine ho hackerato uno script di build per lavorare sia con lombok che con mapstruct. Ma voglio abbandonare lombok a causa di quanto sia caotico - almeno in questo progetto. Uso sempre lombok in altre cose.

Ho letto alcune opinioni su Lombok e in realtà lo sto usando in alcuni progetti.

Bene, nel primo contatto con Lombok ho avuto una brutta impressione. Dopo alcune settimane, ho iniziato a piacermi. Ma dopo alcuni mesi ho scoperto molti piccoli problemi nell'usarlo. Quindi, la mia impressione finale su Lombok non è così positiva.

I miei motivi per pensare in questo modo:

• Dipendenza del plugin IDE . Il supporto IDE per Lombok è tramite plugin. Anche se funziona bene nella maggior parte del tempo, sei sempre un ostaggio di questi plugin da mantenere nelle versioni future degli IDE e persino nella versione del linguaggio (Java 10+ accelererà lo sviluppo del linguaggio). Ad esempio, ho provato ad aggiornare da Intellij IDEA 2017.3 a 2018.1 e non potevo farlo perché c'era qualche problema sulla versione attuale del plugin lombok e dovevo aspettare che il plugin fosse aggiornato ... Anche questo è un problema se tu vorrebbe usare un IDE più alternativo che non ha alcun supporto per il plugin Lombok.
• Problema "Trova usi". . Usando Lombok non vedi il getter, il setter, il costruttore, i metodi di generazione e così via generati, quindi, se hai intenzione di scoprire dove questi metodi vengono utilizzati nel tuo progetto dal tuo IDE, non puoi farlo solo guardando per la classe proprietaria di questi metodi nascosti.
• Così facile che agli sviluppatori non interessa rompere l'incapsulamento . So che non è un problema per Lombok. Ma ho visto una maggiore tendenza da parte degli sviluppatori a non controllare più quali metodi devono essere visibili o meno. Quindi, molte volte stanno solo copiando e incollando il @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructorblocco delle annotazioni senza pensare ai metodi di cui la classe ha davvero bisogno per essere esposta.
• Builder Obssession ©. Ho inventato questo nome (scendere, Martin Fowler). Scherzi a parte, un Builder è così facile da creare che anche quando una classe ha solo due parametri, gli sviluppatori preferiscono usare @Builderinvece del costruttore o un metodo di costruzione statico. A volte provano persino a creare un Builder all'interno di lombok Builder, creando situazioni strane come MyClass.builder().name("Name").build().create().
• Ostacoli al refactoring . Se, ad esempio, stai utilizzando un @AllArgsConstructore devi aggiungere un altro parametro sul costruttore, l'IDE non può aiutarti ad aggiungere questo parametro aggiuntivo in tutti i punti (principalmente, i test) che stanno istanziando la classe.
• Mescolando Lombok con metodi concreti . Non puoi usare Lombok in tutti gli scenari per creare un getter / setter / ecc. Quindi, vedrai questi due approcci mescolati nel tuo codice. Ci si abitua dopo un po 'di tempo, ma sembra un hack sulla lingua.

Come ha detto un'altra risposta, se sei arrabbiato con la verbosità di Java e usi Lombok per affrontarlo, prova Kotlin.

Ci sono anche rischi di manutenzione a lungo termine. Innanzitutto, consiglierei di leggere come funziona effettivamente Lombok, ad esempio alcune risposte dai suoi sviluppatori qui .

Il sito ufficiale contiene anche un elenco di aspetti negativi , tra cui questa citazione di Reinier Zwitserloot:

È un hack totale. Utilizzo di API non pubbliche. Casting presuntuoso (sapendo che un processore di annotazioni in esecuzione in javac otterrà un'istanza di JavacAnnotationProcessor, che è l'implementazione interna di AnnotationProcessor (un'interfaccia), che quindi ha un paio di metodi extra che vengono utilizzati per accedere all'AST live) .

Su eclipse, è probabilmente peggiore (e tuttavia più robusto): un agente java viene utilizzato per iniettare codice nella classe di grammatica e parser di eclissi, che è ovviamente API completamente non pubblica e totalmente off limits.

Se potessi fare ciò che lombok fa con l'API standard, lo farei in quel modo, ma non puoi. Tuttavia, per quello che vale, ho sviluppato il plug-in eclipse per eclipse v3.5 in esecuzione su Java 1.6, e senza apportare modifiche ha funzionato anche su eclipse v3.4 in esecuzione anche su Java 1.5, quindi non è completamente fragile.

In sintesi, mentre Lombok potrebbe farti risparmiare un po 'di tempo di sviluppo, se è disponibile un aggiornamento javac non compatibile all'indietro (ad esempio una mitigazione della vulnerabilità), Lombok potrebbe rimanere bloccato con una vecchia versione di Java mentre gli sviluppatori si affrettano ad aggiornare il loro uso di quelli API interne. Se questo sia un rischio serio dipende ovviamente dal progetto.

So di essere in ritardo, ma non posso resistere alla tentazione: chiunque ami Lombok dovrebbe anche dare un'occhiata a Scala. Molte buone idee che trovi in ​​Lombok fanno parte del linguaggio Scala.

Sulla tua domanda: è sicuramente più facile convincere i tuoi sviluppatori a provare Lombok che Scala. Provalo e, se gli piace, prova Scala.

Proprio come una dichiarazione di non responsabilità: mi piace anche Java!

Ho usato Lombok in quasi tutti i miei progetti per un anno, ma sfortunatamente l'ho rimosso. All'inizio era un modo di sviluppo molto pulito, ma creare un ambiente di sviluppo per i nuovi membri del team non è molto semplice e diretto. Quando è diventato un mal di testa l'ho appena rimosso. Ma è un buon lavoro e ha bisogno di un po 'più di semplicità per l'installazione.

Quando ho mostrato il progetto al mio team l'entusiasmo è stato alto, quindi penso che non dovresti avere paura della risposta del team.

• Per quanto riguarda il ROI, è semplicissimo da integrare e non richiede alcuna modifica del codice nella sua forma base. (basta aggiungere una singola annotazione alla tua classe)

• E infine, se cambi idea, puoi eseguire unlombok o lasciare che il tuo IDE crei questi setter, getter e ctors (che penso che nessuno chiederà quando vedranno quanto diventa chiaro il tuo pojo)

La mia opinione su Lombok è che fornisce semplicemente scorciatoie per scrivere codice Java bolilerplate.
Quando si tratta di utilizzare le scorciatoie per scrivere codice Java bolilerplate, mi affido a tali funzionalità fornite da IDE - come in Eclipse, possiamo andare al menu Fonte> Genera Getter e setter per la generazione di getter e setter.
Non farei affidamento su una libreria come Lombok per questo:

1. Inquina il codice con uno strato indiretto di sintassi alternativa (leggi @Getter ,@Setter ecc annotazioni). Piuttosto che imparare una sintassi alternativa per Java, passerei a qualsiasi altra lingua che fornisca nativamente la sintassi simile a Lombok.
2. Lombok richiede l'uso di un IDE supportato da Lombok per funzionare con il tuo codice. Questa dipendenza presenta un rischio considerevole per qualsiasi progetto non banale. Il progetto Lombok open source ha risorse sufficienti per continuare a fornire supporto per diverse versioni di una vasta gamma di IDE Java disponibili?
3. Il progetto Lombok open source ha abbastanza risorse per continuare a fornire supporto per le nuove versioni di Java che arriveranno in futuro?
4. Sono anche nervoso che Lombok possa introdurre problemi di compatibilità con framework / librerie ampiamente utilizzati (come Spring, Hibernate, Jackson, JUnit, Mockito) che funzionano con il tuo codice byte in fase di esecuzione.

Tutto sommato non preferirei "ravvivare" la mia Java con Lombok.

Volevo usare lombok's @ToString ma presto affrontato casualmente sulla ricostruzione del progetto in Intellij IDEA. Ho dovuto eseguire la compilazione più volte prima che la compilazione incrementale potesse completarsi con successo.

Ho provato sia lombok 1.12.2 che 0.9.3 con Intellij IDEA 12.1.6 e 13.0 senza alcun plugin lombok in jdk 1.6.0_39 e 1.6.0_45.

Ho dovuto copiare manualmente i metodi generati dalla fonte delomboked e mettere lombok in attesa fino a tempi migliori.

Aggiornare

Il problema si verifica solo con la compilazione parallela abilitata.

Ha presentato un problema: https://github.com/rzwitserloot/lombok/issues/648

Aggiornare

mplushnikov ha commentato il 30 gennaio 2016:

La versione più recente di Intellij non presenta più tali problemi. Penso che possa essere chiuso qui.

Aggiornare

Consiglio vivamente di passare da Java + Lombok a Kotlin, se possibile. Come ha risolto da zero tutti i problemi Java che Lombok tenta di aggirare.

Ho riscontrato un problema con Lombok e Jackson CSV , quando ho marshalizzato il mio oggetto (java bean) in un file CSV, le colonne sono state duplicate, quindi ho rimosso l'annotazione @Data di Lombok e il marshalizing ha funzionato bene.

Non lo consiglio. Lo usavo, ma poi quando lavoro con NetBeans 7.4 stava rovinando i miei codici. Devo rimuovere lombok in tutti i file nei miei progetti. C'è delombok, ma come posso essere sicuro che non rovinerebbe i miei codici. Devo passare giorni solo per rimuovere lombok e tornare ai normali stili Java. Sono troppo piccante ...

Non ho ancora provato ad usare Lombok - è / era il prossimo nella mia lista, ma sembra che Java 8 abbia causato problemi significativi per esso, e il lavoro di riparazione era ancora in corso da una settimana fa. La mia fonte per questo è https://code.google.com/p/projectlombok/issues/detail?id=451 .