E 'sicuro da usare progetto Lombok? [chiuso]

StackOverflow https://stackoverflow.com/questions/3852091

  •  27-09-2019
  •  | 
  •  

Domanda

Nel caso in cui tu non sai Progetto Lombok aiuta con alcuni dei fastidi di Java con roba come generare getter e setter con annotazioni e anche semplice JavaBean come generazione con @Data . Si potrebbe davvero aiutarmi, soprattutto in 50 diversi oggetti evento dove avete fino a 7 diversi campi che hanno bisogno di essere costruito e nascosto con getter. Potrei rimuovere quasi un migliaio di righe di codice con questo.

Comunque, io sono preoccupato che a lungo andare, sarà una decisione di rimpianto. Flame scoppieranno nel canale ##Java Freenode quando dico che, fornendo frammenti di codice confonderà possibili aiutanti, persone si lamentano di perdere JavaDoc , e commiters futuri potrebbero semplicemente rimuovere tutto comunque. Mi piace molto il positivo, ma sono preoccupato per il negativo.

Quindi: E 'sicuro da usare Lombok su qualsiasi progetto, piccolo o grande? Sono la pena effetti positivi i negativi?

È stato utile?

Soluzione

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

Prima di utilizzare Progetto Lombok (o qualsiasi altra tecnologia che cambia gioco) in qualche progetto (open source o altro saggio), è necessario fare in modo che le parti interessate del progetto d'accordo a questo. Questo include gli sviluppatori, e gli eventuali importanti utilizzatori (ad esempio, formale o informale sponsor).

Si parla di questi potenziali problemi:

  

Flamewars scoppierà nel ## canali Java Freenode quando dico che,

Facile. Ignora / non partecipare ai flame, o semplicemente astenersi dal menzionare Lombok.

  

fornendo frammenti di codice confonderà possibili aiutanti,

Se la strategia del progetto è quella di utilizzare Lombok, quindi avrà bisogno di abituarsi ad esso i possibili aiutanti.

  

la gente si lamenterà di JavaDoc mancante,

Questo è un problema loro. Nessuno nei loro tentativi di mente diritto di applicare rigidamente le regole del codice sorgente / documentazione della propria organizzazione per il software open source di terze parti. Il team di progetto deve essere libero di impostare la sorgente del progetto standard di codice / di documentazione che sono appropriati alla tecnologia utilizzata.

( FOLLOWUP -. Gli sviluppatori Lombok riconoscono che commenti Javadoc non generano per i metodi getter e setter sintetizzata è un problema se questo è un problema importante per il progetto (s), poi un alternativa è quella di creare e inviare una patch Lombok per affrontare questo.)

  

e future commiters potrebbe semplicemente rimuovere tutto comunque.

Non è su! Se la strategia di progetto concordato è di utilizzare Lombok, poi commiters che gratuitamente de-Lombok il codice dovrebbe essere castigato, e, se necessario, i loro diritti di commit ritirato.

Naturalmente, questo presuppone che hai buy-in dalle parti interessate ... compresi gli sviluppatori. E si presume che si sono preparati a sostenere la vostra causa, e in modo adeguato di gestire le voci dissenzienti inevitabili.

Altri suggerimenti

appena iniziato a usare Lombok oggi. Finora mi piace, ma uno svantaggio non ho visto già detto era il refactoring di supporto.

Se si dispone di una classe annotata con @Data, genererà i getter e setter per voi in base ai nomi dei campi. Se si utilizza uno di questi getter in un'altra classe, poi decidere il campo è poco chiamato, non troverà usi di quei getter e setter e sostituire il vecchio nome con il nuovo nome.

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

UPDATE (22 gennaio '13)
Dopo aver utilizzato Lombok per 3 mesi, mi raccomando ancora che per la maggior parte dei progetti. Ho, tuttavia, trovare un altro inconveniente che è simile a quello di cui sopra.

Se si dispone di una classe, dire MyCompoundObject.java che ha 2 componenti, sia annotato con @Delegate, myWidgets diciamo e myGadgets, quando si chiama myCompoundObject.getThingies() da un'altra classe, è impossibile sapere se si tratta di delegare al Widget o Gadget perché non è possibile più salto alla fonte all'interno dell'IDE.

Uso della Eclipse "Genera metodi delegato ..." vi offre le stesse funzionalità, è altrettanto veloce e fornisce salto fonte. Il lato negativo è che ingombra la vostra fonte con codice standard che prende il fuoco fuori le cose importanti.

UPDATE 2 (26 febbraio '13)
Dopo 5 mesi, stiamo ancora usando Lombok, ma ho alcuni altri fastidi. La mancanza di un getter e setter dichiarato può diventare fastidioso, a volte, quando si sta 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 in più per saltare per determinare lo scopo di questo metodo. Alcuni degli ostacoli sono Lombok, alcuni sono la mancanza di una smart plugin di Lombok. Ostacoli includono:

  • mancanza di JavaDocs. Se io javadoc il campo, mi auguro il getter e setter avrebbe ereditato che javadoc attraverso la fase di compilazione Lombok.
  • Vai alla definizione del metodo mi salta alla classe, ma non la proprietà che ha generato il getter. Questo è un problema di plugin.
  • Ovviamente non sono in grado di impostare un punto di interruzione in un getter / setter a meno che non si genera o il codice del metodo.
  • Nota: questa ricerca di riferimento non è un problema, come ho pensato che fosse. Si ha bisogno di utilizzare una prospettiva che permette la vista Struttura però. Non è un problema per la maggior parte degli sviluppatori. Il mio problema era che sto usando Mylyn che è stato filtrando mio avviso Outline, quindi non ho visto i metodi. mancanza di riferimenti cercare. Se voglio vedere chi sta chiamando getDynamicCols(args...), devo per generare il codice o il setter di essere in grado di cercare i riferimenti.

UPDATE 3 (7 marzo '13)
Imparare ad usare i vari modi di fare le cose in Eclipse immagino. Si può effettivamente impostare un punto di interruzione condizionale (BP) su un metodo di Lombok generato. Usando la vista Outline, è possibile fare clic con il metodo per Toggle Method Breakpoint. Poi, quando si colpisce la BP, è possibile utilizzare la vista Variables debug per vedere ciò che il metodo generato chiamato i parametri (di solito lo stesso come il nome del campo) e, infine, utilizzare la vista Breakpoints a fare clic con il BP e selezionare Breakpoint Properties... aggiungere una condizione. Nizza.

UPDATE 4 (16 agosto '13)
Netbeans non piace quando si aggiornano le dipendenze Lombok nel pom Maven. Il progetto compila ancora, ma i file di ottenere fermato in posizione di avere errori di compilazione perché non può vedere i metodi di Lombok sta creando. Svuotare la cache Netbeans risolve il problema. Non so se c'è un opzione "Clean Progetto" che ci sia in Eclipse. problema minore, ma ha voluto farlo conoscere.

UPDATE 5 (17 gennaio '14)
Lombok non sempre gioca sempre pulito con Groovy, o almeno la groovy-eclipse-compiler. Potrebbe essere necessario declassare la versione del compilatore. Maven Groovy e Java + Lombok

UPDATE 6 (26 giugno '14)
Una parola di avvertimento. Lombok è leggermente dipendenza e se si lavora su un progetto in cui non è possibile utilizzare per qualche motivo, si infastidire il culo fuori di voi. Si può essere meglio solo non usarlo affatto.

UPDATE 7 (23 luglio '14)
Questo è un po 'di un aggiornamento interessante perché affronta direttamente la sicurezza di adottare Lombok che il PO ha chiesto circa.

Come di v1.14, l'annotazione @Delegate è stato retrocesso a uno stato sperimentale. I dettagli sono documentate sul loro sito ( Lombok Delegato Docs ).

La cosa è, se si sta utilizzando questa funzione, le opzioni sono limitate backout. Vedo le opzioni come:

  • rimuovere manualmente le annotazioni @Delegate e generare / handcode il codice delegato. Questo è un po 'più difficile se si stesse utilizzando attributi all'interno di annotazione.
  • Delombok i file che hanno l'annotazione @Delegate e magari aggiungere nuovamente nelle annotazioni che si desidera utilizzare.
  • Non aggiornare Lombok o mantenere una forchetta (o dal vivo con l'utilizzo di caratteristiche esperienziali).
  • Delombok l'intero progetto e smettere di usare Lombok.

Per quanto posso dire, 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 bandiere Delombok, ma non mi aspetto che in un prossimo futuro.

UPDATE 8 (20 ottobre '14)
Se è un'opzione per voi, offerte Groovy maggior parte degli stessi vantaggi di Lombok, oltre a un battello carico di altre funzioni, tra cui @Delegate . Se pensi di avere un momento difficile vendere l'idea di poteri che essere, date un'occhiata al @CompileStatic o @TypeChecked annotazione per vedere se questo può aiutare la vostra causa. In realtà, l'obiettivo primario del rilascio Groovy 2.0 era la sicurezza statica .

UPDATE 9 (1 settembre '15)
Lombok è ancora in fase attivamente mantenuto e valorizzato , che fa ben sperare per il livello di sicurezza di adozione. Il @Builder annotazioni è uno dei miei preferiti nuove funzionalità.

UPDATE 10 (17 novembre '15)
Questo può non sembrare direttamente correlata alla domanda del PO, ma vale la pena condividere. Se siete alla ricerca di strumenti per aiutare a ridurre la quantità di codice boilerplate si scrive, si può anche verificare Google Auto - in particolare Valore automatico . Se si guarda alla loro slitta ponte , il elencare Lombok come una possibile soluzione al problema che stanno cercando di risolvere. I contro sono lista per Lombok sono:

  • Il codice introdotto è invisibile (non si può "vedere" i metodi che genera) [ndr - in realtà è possibile, ma solo requires un decompilatore]
  • Gli hack compilatore sono non standard e fragile
  • "A nostro avviso, il codice non è più davvero Java"

Non sono sicuro di quanto sono d'accordo con la loro valutazione. E visti i contro del Valore automatico che sono documentati nelle diapositive, sarò incastrata con Lombok (se Groovy non è un'opzione).

UPDATE 11 (8 febbraio '16)
Ho scoperto Spring Roo ha alcune annotazioni simili . Ero un po 'sorpreso di scoprire Roo è ancora una cosa e trovare documentazione per le annotazioni è un po' ruvido. La rimozione, inoltre, non sembra così facile come de-Lombok. Lombok sembra la scelta più sicura.

UPDATE 12 (17 febbraio '16)
Durante il tentativo di trovare giustificazioni per il motivo per cui è sicuro di portare a Lombok per il progetto su cui sto attualmente lavorando su, ho trovato un pezzo d'oro che è stato aggiunto con v1.14 - Il Configurazione del sistema ! Questo è significa che è possibile configurare un progetto da dis-consentire alcune caratteristiche che la vostra squadra ritenga pericoloso o indesiderato. Meglio ancora, si può anche creare config specifica directory con impostazioni diverse. Questo è impressionante.

UPDATE 13 (4 ottobre '16)
Se questo genere di cose è importante per voi, Oliver Gierke ritenuto che fosse sicuro di aggiungi Lombok a primavera dati riposo .

UPDATE 14 (26 settembre '17)
Come sottolineato da @gavenkoa nei commenti sulla questione PO, supporto del compilatore JDK9 non è ancora disponibile (Issue # 985). Suona anche come non sta andando ad essere una soluzione semplice per la squadra Lombok per andare in giro.

UPDATE 15 (26 marzo '18)
Il changelog Lombok indica come di v1.16.20 " Compilazione Lombok su JDK1.9 è ora possibile ", anche se # 985 è ancora aperto.

Le modifiche per ospitare JDK9, tuttavia, ha reso necessario qualche cambiamento di rottura; tutti isolati ai cambiamenti di impostazioni predefinite di configurazione. E 'un po' per quanto riguarda che hanno introdotto cambiamenti di rottura, ma la versione urtato solo il numero di versione "incrementale" (che va da v1.16.18 a v1.16.20). Dal momento che questo messaggio è stato per la sicurezza, se si ha un yarn/npm come il sistema di compilazione che automaticamente aggiornato alla versione più recente incrementale, si potrebbe essere in un brusco risveglio.

UPDATE 16 (9 gennaio '19)

i problemi sono stati risolti JDK9 e Lombok lavora con JDK10, e anche JDK11 per quanto posso raccontare.

Una cosa che ho notato però che riguardava dal punto di vista della sicurezza è il fatto che il registro delle modifiche che va da v1.18.2 a v1.18.4 liste due articoli come BREAKING CHANGE !? Io non sono sicuro di come un cambiamento di rottura avviene in un aggiornamento semver "patch". Potrebbe essere un problema se si utilizza uno strumento che le versioni aggiornamenti automatici delle patch.

Vai avanti e l'uso di Lombok, è possibile, se necessario "delombok" il codice di seguito http://projectlombok.org/features/delombok .html

Personalmente (e quindi soggettivamente) ho trovato che l'uso di Lombok rende il mio codice più espressivo di quello che sto cercando di realizzare rispetto a IDE / proprie implementazioni di metodi complicati come il codice hash e uguali.

Quando si utilizza 

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

è molto più facile mantenere Equals & HashCode coerente e tenere traccia di quali campi vengono valutati, di qualsiasi IDE propria implementazione /. Ciò è particolarmente vero quando si sta ancora aggiunta / rimozione di campi regolari.

Lo stesso vale per l'annotazione @ToString ed i suoi parametri che comunicano chiaramente il comportamento desiderato per quanto riguarda inclusi campi / escluse, uso di getter o l'accesso di campo e castrato o no alla chiamata super.toString().

E ancora annotando un'intera classe con @Getter o @Setter(AccessLevel.NONE) (ed eventualmente sovrascrivendo i metodi divergenti) è immediatamente chiaro che cosa saranno disponibili per i campi metodi.

I benefici andare avanti e avanti ..

Nella mia mente non è di ridurre il codice, ma di comunicare in modo chiaro ciò che si desidera raggiungere, piuttosto che dover capirlo da Javadoc o implementazioni. Il codice ridotta rende solo più facile da individuare eventuali implementazioni divergenti-metodo.

Lombok è grande, ma ...

Lombok rispetta le regole del processo di annotazione, in quanto non genera nuovi file di origine. Questo significa che cant essere utilizzato con altri processori di annotazione se si aspettano i getter / setter o qualsiasi altra cosa di esistere.

funzionamenti di elaborazione di annotazione in una serie di turni. In ogni turno, ognuno ottiene un turno per l'esecuzione. Se i nuovi file Java si trovano dopo il round è completato, un altro giro inizia. In questo modo, l'ordine di processori di annotazione non importa se essi generano solo i nuovi file. Dal momento che Lombok non genera nuovi file, nessun nuovo round vengono avviati in modo un po 'AP che si basa sul codice Lombok non eseguito come previsto. Questa è stata una grande fonte di dolore per me durante l'utilizzo mapstruct e delombok-zione non è un'opzione utile in quanto distrugge i numeri di riga nei registri.

Alla fine ho violato uno script di build di lavorare sia con Lombok e mapstruct. Ma voglio far cadere Lombok a causa di come hacky è - in questo progetto, almeno. Io uso Lombok per tutto il tempo in altre cose.

Ci sono a lungo termine di manutenzione rischi pure. In primo luogo, vi consiglio la lettura di come funziona realmente Lombok, per esempio alcune risposte dai suoi sviluppatori qui .

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

  

E 'un hack totale. Utilizzando API non pubbliche. Presuntuoso fusione (sapendo   che un processore di annotazione esecuzione in javac ottenere un'istanza   JavacAnnotationProcessor, che è l'implementazione interna di   AnnotationProcessor (un'interfaccia), che così succede di avere una coppia   di metodi aggiuntivi che vengono utilizzati per arrivare alla AST dal vivo).

     

su Eclipse, è senza dubbio peggiore (e ancora più robusto) - un agente java   è usato per iniettare codice nella grammatica eclisse e la classe di parser,   che è di API naturalmente interamente non pubblico e totalmente interdetta.

     

Se si potesse fare quello che Lombok fa con le API standard, avrei fatto   in questo modo, ma non si può. Eppure, per quanto il suo valore, ho sviluppato il   Plug-in Eclipse per Eclipse v3.5 in esecuzione su Java 1.6, e senza   apportare alcuna modifica ha funzionato su Eclipse v3.4 in esecuzione su Java 1.5 come   bene, quindi non è del tutto fragile.

In sintesi, mentre Lombok si può risparmiare un po 'di tempo di sviluppo, se c'è un aggiornamento javac non compatibile (ad esempio, una mitigazione della vulnerabilità) Lombok potrebbe ottenere bloccato con una vecchia versione di Java, mentre gli sviluppatori scramble per aggiornare il loro uso di tali API interne. Se questo è un rischio serio, ovviamente, dipende dal progetto.

ho letto alcune opinioni su l'Lombok e in realtà lo sto usando in alcuni progetti.

Bene, nel primo contatto con Lombok ho avuto una cattiva impressione. Dopo alcune settimane, ho cominciato a piacermi. Ma dopo alcuni mesi ho dato un sacco di problemi piccoli usarlo. Quindi, la mia impressione finale su Lombok non è così positivo.

Le mie ragioni per pensare in questo modo:

  • IDE plugin di dipendenza . Il supporto IDE per Lombok è attraverso i plugin. Anche lavorando bene ins maggior parte del tempo, si è sempre un ostaggio da questo plug-in deve essere mantenuta nelle versioni future di IDE e anche la versione in lingua (Java 10+ accelererà lo sviluppo del linguaggio). Per esempio, ho provato ad aggiornare da Intellij IDE 2017,3-2018,1 e non potevo farlo perché c'è qualche problema sul Lombok reale plug-in versione e ho bisogno di aspettare il plugin essere aggiornato ... Anche questo è un problema se si vorrebbe usare un IDE più alternativo che non hanno alcun supporto plugin di Lombok.
  • 'Trova usi' problema. . Utilizzando Lombok non vedi i getter, setter, costruttore, metodi costruttore generati ed ecc Quindi, se avete intenzione di scoprire quali di questi metodi vengono utilizzati nel progetto per il vostro IDE, non si può fare solo in questo alla ricerca per la classe che possiede i metodi questo nascoste.
  • Così facile che gli sviluppatori non si preoccupano di rompere l'incapsulamento . So che non è davvero un problema da Lombok. Ma ho visto una tendenza più grande per gli sviluppatori non controlla più cosa esigenze metodi sia visibile o meno. Così, molte volte sono solo copiare e incollare le annotazioni @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructor senza pensare che cosa metodi che la classe ha realmente bisogno di esporre.
  • Builder Obssession ©. Ho inventato questo nome (scendere, Martin Fowler). Scherzi a parte, un Builder è così facile da creare che anche quando una classe hanno solo due parametri che gli sviluppatori preferiscono utilizzare @Builder invece di costruttore o di un metodo costruttore statico. A volte anche provare a creare un cantiere all'interno del Lombok Builder, creando situazioni strane come MyClass.builder().name("Name").build().create().
  • Barriere durante il refactoring . Se si sta utilizzando, per esempio, un @AllArgsConstructor ed è necessario aggiungere un parametro più sul costruttore, l'IDE non può fare di aggiungere questo parametro in più in tutti i luoghi (per lo più, test) che sono istanziare la classe.
  • Mix Lombok con metodi concreti . Non è possibile utilizzare Lombok in tutti gli scenari per creare un getter / setter / etc. Quindi, si vedrà questi due approcci misti nel codice. Ci si abitua a questo dopo qualche tempo, ma si sente come un hack sulla lingua.

Come un'altra risposta, ha detto, se si è arrabbiato per la prolissità Java e Lombok utilizzare per trattare il caso, provare Kotlin.

Lo so, sono in ritardo, ma non riesco a resistere alla tentazione: nessuno simpatia Lombok dovrebbe anche avere uno sguardo a Scala. Molte buone idee che si trovano a Lombok sono parte del linguaggio Scala.

Sulla tua domanda: è decisamente più facile per ottenere gli sviluppatori che cercano di Lombok Scala. Fate una prova e se piace, provate a Scala.

Proprio come un disclaimer: Ho come Java, anche

ho usato Lombok in quasi tutti i miei progetti per un anno, ma purtroppo rimosso. In principio era un modo molto pulito di sviluppo, ma alla configurazione dell'ambiente di sviluppo per nuovi membri del team non è molto facile e semplice. Quando è diventato un mal di testa ho appena rimosso. Ma si tratta di un buon lavoro e ha bisogno di un po 'di semplicità per la creazione.

Quando ho mostrato il progetto per la mia squadra l'entusiasmo era alto, quindi penso che non si deve aver paura della risposta della squadra.

  • Per quanto riguarda il ROI, è un gioco da ragazzi per integrare, e non richiede alcuna modifica del codice nella sua forma base. (Solo l'aggiunta di un singolo un'annotazione alla classe)

  • E per ultimo, se si cambia idea, è possibile eseguire l'unlombok, o lasciare che il vostro IDE creare queste setter, getter, e ctors, (che credo nessuno si chiederà una volta che vedono come svuotare la POJO diventa)

Volevo @ToString uso di Lombok, ma ben presto affrontati errori di compilazione casuale sul progetto di ricostruire in IntelliJ IDEA. Ha dovuto colpire di compilazione più volte prima della compilazione incrementale ha potuto completare con successo.

provato sia Lombok 1.12.2 e 0.9.3 con IntelliJ IDEA 12.1.6 e 13.0 senza alcun plug-in Lombok sotto JDK 1.6.0_39 e 1.6.0_45.

Dovuto metodi copiare manualmente generati dalla sorgente delomboked e mettere lombok in attesa fino a tempi migliori.

Aggiorna

Il problema si verifica solo con compilazione parallelo abilitato.

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

Aggiorna

  

mplushnikov ha commentato il 30 gen 2016:

     

versione più recente di Intellij   non ha più questi problemi. Penso che possa essere chiuso qui.

Aggiorna

consiglio vivamente di passare da Java + Lombok a Kotlin se possibile. Come è risolto da zero tutti i problemi Java che Lombok cerca di risolvere.

Il mio assumere Lombok è che si limita a fornire i collegamenti per la scrittura di codice Java bolilerplate.
Quando si tratta di utilizzare le scorciatoie per la scrittura di codice Java bolilerplate, vorrei fare affidamento su tali caratteristiche fornite dal IDE - come in Eclipse, siamo in grado di andare al menu Source> Generare getter e setter per la generazione di getter e setter
. Non vorrei fare affidamento su una libreria come Lombok per questo:

  1. E 'inquina il codice con uno strato di indirezione di sintassi alternativa (@Getter lettura, @Setter, ecc annotazioni). Piuttosto che imparare una sintassi alternativa per Java, vorrei passare a qualsiasi altro linguaggio che nativamente fornisce Lombok come sintassi.
  2. Lombok richiede l'utilizzo di un Lombok supportato IDE per il lavoro con il codice. Questa dipendenza introduce un rischio considerevole per ogni progetto non banale. Fa il progetto Lombok open source ha abbastanza risorse per continuare a fornire il supporto per diverse versioni di una vasta gamma di Java IDE disponibili?
  3. Fa il progetto Lombok open source ha abbastanza risorse per continuare a fornire il supporto per le versioni più recenti di Java che arriveranno in futuro?
  4. I sento anche nervoso che Lombok può introdurre problemi di compatibilità con diffusi framework / librerie (come Spring, Hibernate, Jackson, JUnit, Mockito), che opera con il codice di byte in fase di esecuzione.

Tutto sommato non sarebbe preferirebbe "vivacizzare" il mio Java con Lombok.

Ho incontrato un problema con la Lombok e Jackson CSV , quando ho marshalized mio oggetto (Java Bean) in un file CSV, colonne in cui duplicato, poi ho tolto Lombok di annotazione @Data e marshalizing bene funzionato.

Non sto consiglio. Ho usato per usarlo, ma poi quando lavoro con NetBeans 7.4 è dovuto vedermela miei codici. Ho rimuovere Lombok in tutti i file nei miei progetti. C'è delombok, ma come posso essere sicuro che non sarebbe avvitare i miei codici. Devo trascorre giorni solo per rimuovere Lombok e di nuovo a stili ordinari Java. Ho appena troppo piccante ...

Non ho provato ad utilizzare ancora Lombok - è / era accanto alla mia lista, ma suona come se Java 8 ha causato problemi significativi per esso, e lavori di riparazione era ancora in corso di una settimana fa. La mia fonte di ciò è https://code.google.com/p/ projectlombok / temi / dettaglio? id = 451 .

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top