Quali sono i rischi con Project Lombok?
Sto arrivando con obiettivi di prestazioni per il nuovo anno, e ho pensato che sarebbe stato divertente mettere un obiettivo per ridurre le dimensioni della base di codice, in particolare boilerplate. Un'azione che ho trovato per risolvere questo problema è usare Project Lombok per rendere i bean più corti come dovrebbero essere. Ma ho l'abitudine di trascurare gli aspetti negativi di nuovi software e approcci, quindi mi affido alla comunità di Stack Overflow: qualcuno può dirmi perché Lombok è una cattiva idea?
6 answers
Uno svantaggio principale è il supporto IDE. Poiché Lombok non è in realtà un cambiamento di lingua e poiché il tuo IDE comprende solo java, avrai bisogno di un IDE che supporti Lombok per far funzionare le cose correttamente. A partire da ora, questo è solo Eclipse che include Eclipse e IntelliJ. Se usi eclipse potrebbe essere ok, ma ricorda che stai prendendo una decisione anche per i futuri sviluppatori.
Ti suggerirei di considerare di spostare parte del tuo codice in un linguaggio meno cerimoniale come figo. Abbiamo avuto successo spostando alcune delle nostre logiche di business e modelli in groovy e funziona davvero senza intoppi.
Una limitazione di Lombok è il fatto che è strettamente legato al compilatore java. Poiché l'API del processore di annotazione consente solo la creazione di nuovi file durante la compilazione (e non la modifica dei file esistenti) lombok utilizza tale API come punto di ingresso per modificare il compilatore java. Sfortunatamente queste modifiche del compilatore rendono pesante l'uso di API non pubbliche. Usare lombok può essere una buona idea, ma devi essere consapevole che l'aggiornamento del tuo compilatore potrebbe rompere il tuo codice. Il la probabilità è bassa ma mi sento sempre a disagio usando API non pubbliche.
Un potenziale svantaggio di qualcosa come Lombok è che con i setter/getter "mancanti", gli strumenti di origine potrebbero non "riconoscere" aspetti dell'oggetto risultante che gli conferiscono qualità "bean", poiché tali qualità si manifestano solo nella classe compilata.
Un altro svantaggio è che è Ancora un Altro pezzo di "magia nera" all'interno della catena di strumenti. Fortunatamente, sembra essere un pezzo piuttosto benigno (non l'ho usato), e il fatto che accada in fase di compilazione piuttosto che in fase di runtime è in realtà una benedizione (IMHO). Ma non sarai in grado di riutilizzare o condividere il tuo codice senza il progetto poiché aggiunge artefatti alla tua base di codice. Quindi, mentre il file di classe compilato può essere un "POJO", direi che il tuo codice sorgente NON è un POJO.
Nessuno di questi sono svantaggi paralizzanti, piuttosto solo aspetti di cui essere consapevoli.
A mio parere il codice sorgente in "Java+Lombok" non è più il codice sorgente Java. Lo vedo come qualcosa di simile Borland company ha fatto molti anni fa nel loro Borland C++ Builder IDE per VCL-hanno introdotto "proprietà" nel codice C++ introducendo efficacemente una sorta di nuovo linguaggio di programmazione che non era più C++ (non C++ nel senso di standard del linguaggio C++). Le fonti che utilizzano "Java + Lombok" non sono fonti valide nel senso delle specifiche del linguaggio Java. Inoltre penso che le annotazioni non lo fossero progettato per influenzare il linguaggio semantico.
È una libreria di terze parti e ci sono sviluppatori che non la conoscono bene.
IDE dovrebbe supportare l'elaborazione delle annotazioni (ci sono plugin per IDEA ed Eclipse).
Come menzionato sopra, il tuo codice sarà senza getter/setter. Porta a violazioni sonar / checkstyle.
Come sottolineato dall'utente @Jcs in un'altra risposta, vorrei aggiungere altro.
Nel nostro progetto, stiamo usando mapstruct che viene utilizzato per generare classi mapper, prima che il codice venga compilato, usando il comando mvn generate-sources, questo viene fatto in fase di processo usando il plugin del processore maven.
Progetto lombok aggiunge il bytecode per il getter/setter nel file di classe in fase di compilazione.
Poiché la fase del processo viene eseguita prima della compilazione, rileva che non getter / setter disponibile in classe.
Sono disponibili alcune soluzioni alternative per eseguire la fase di compilazione più di una. Vedi questo git hub ticket per maggiori dettagli.
Nota: sto usando STS ide di Spring ed è supportato da lombok :)