Lombok Projesi'ni kullanmak güvenli mi? [kapalı]

Eğer bilmiyorsanız Project Lombok Java ek açıklamaları bazı ek açıklamaları ile getters ve setters ve hatta @Data ile basit JavaBean nesil gibi şeyler ile yardımcı olur . Özellikle, alıcılarla oluşturulması ve gizlenmesi gereken 7 farklı alana sahip olduğunuz 50 farklı olay nesnesinde gerçekten yardımcı olabilir. Bununla neredeyse bin satır kod kaldırabilirim.

Ancak, uzun vadede bunun pişman bir karar olacağından endişeleniyorum. Flamewars, bundan ##Java Freenodebahsettiğimde kanalda patlayacak , kod snippet'lerinin olası yardımcıları karıştıracak, insanlar eksik JavaDoc'dan şikayet edecek ve gelecekteki komiserler her şeyi yine de kaldırabilirler. Olumlu olandan gerçekten zevk alırdım, ama olumsuzluktan endişeliyim.

Peki: Lombok'u küçük veya büyük herhangi bir projede kullanmak güvenli midir? Olumlu etkileri olumsuz mu?

Görünüşe göre, Lombok Projesi'nin önerilen yeni projeniz için size önemli teknik avantajlar sağladığına karar verdiniz. (Başlangıçtan itibaren, şu ya da bu şekilde Lombok Projesi hakkında özel bir görüşüm yok.)

Project Lombok'u (ya da başka bir oyun değiştiren teknolojiyi) bazı projelerde (açık kaynak ya da diğer bilge) kullanmadan önce, proje pay sahiplerinin bunu kabul ettiğinden emin olmanız gerekir. Buna geliştiriciler ve önemli kullanıcılar (ör. Resmi veya gayri resmi sponsorlar) dahildir.

Bu olası sorunlardan bahsediyorsunuz:

Flamewars, ## Java Freenode kanalında bahsettiğimde patlayacak,

Kolay. Flamewarları görmezden gelin / katılmayın ya da Lombok'tan bahsetmekten kaçının.

kod snippet'lerinin sağlanması olası yardımcıları karıştırır,

Proje stratejisi Lombok'u kullanmaksa, olası yardımcıların buna alışması gerekecektir.

insanlar JavaDoc'u kaçırmaktan şikayet edecekler,

Bu onların sorunu. Aklı başında hiç kimse, kuruluşunun kaynak kodunu / dokümantasyon kurallarını üçüncü taraf açık kaynaklı yazılımlara katı bir şekilde uygulamaya çalışmaz. Proje ekibi, kullanılan teknolojiye uygun proje kaynak kodu / dokümantasyon standartlarını belirlemekte serbest olmalıdır.

( FOLLOWUP - Lombok geliştiricileri, sentezlenen alıcı ve ayarlayıcı yöntemleri için javadoc yorumları üretmemenin bir sorun olduğunu kabul ediyorlar. )

ve gelecekteki komiteler hepsini zaten kaldırabilir.

Açık değil! Üzerinde mutabık kalınan proje stratejisi Lombok'u kullanmaksa, kodu nezaketle de-Lombok'tan alan komiteler onaylanmamalı ve gerekirse taahhüt hakları geri çekilmelidir.

Tabii ki, bu, geliştiriciler de dahil olmak üzere paydaşlardan satın aldığınız varsayılmaktadır. Ve nedeninizi tartışmaya hazır olduğunuzu ve kaçınılmaz muhalif sesleri uygun şekilde ele aldığınızı varsayar.

Lombok'u bugün kullanmaya başladım. Şimdiye kadar beğendim, ancak bahsetmediğim bir dezavantaj desteği yeniden düzenleme oldu.

Açıklamalı bir sınıfınız varsa @Data, alan adlarına göre sizin için alıcıları ve ayarlayıcıları oluşturur. Başka bir sınıfta bu alıcılardan birini kullanırsanız, alanın adının iyi olmadığına karar verirseniz, bu alıcıların ve ayarlayıcıların kullanımlarını bulamaz ve eski adı yeni adla değiştirmez.

Bunun Lombok aracılığıyla değil, bir IDE eklentisi ile yapılması gerektiğini düşünürdüm.

GÜNCELLEME (22 Ocak 13)
Lombok'u 3 ay kullandıktan sonra hala birçok proje için tavsiye ederim. Ancak, yukarıda listelenene benzer başka bir dezavantaj buldum.

Eğer bir sınıf varsa, demek MyCompoundObject.javahem açıklamalı, yani 2 üye var @Delegatedemek, myWidgetsve myGadgetsAradığınızda, myCompoundObject.getThingies()başka bir sınıftan, bunun için temsilci seçme eğer bilmek imkansızWidget ya da GadgetIDE içinde kaynağına yapabilirsiniz artık atlama çünkü.

Eclipse kullanmak "Delege Yöntemleri Oluştur ..." aynı işlevsellik sağlar, aynı hızlı ve kaynak atlama sağlar. Dezavantajı, kaynağınızı önemli şeylerden odaklanan kazan plakası koduyla keser.

GÜNCELLEME 2 (26 Şubat '13)
5 ay sonra hala Lombok kullanıyoruz, ama başka sıkıntılarım var. Bildirilen bir alıcı ve ayarlayıcı eksikliği, yeni kodu tanımak için zaman zaman sinir bozucu olabilir.

Örneğin, adı verilen bir yöntem görürsem getDynamicCols()ama bunun ne hakkında olduğunu bilmiyorsam, bu yöntemin amacını belirlemek için atlamak için ekstra engellerim var. Bazı engeller Lombok, bazıları Lombok akıllı eklentisinin olmaması. Engelliler şunları içerir:

• JavaDocs eksikliği. Eğer alanı javadoc edersem, alıcı ve pasör o javadocu Lombok derleme adımından devralır.
• Yöntem tanımına atla beni sınıfa atlar, ancak alıcıyı oluşturan özellik değil. Bu bir eklenti sorunudur.
• Açıkçası, yöntemi oluşturmadığınız veya kodlamadığınız sürece bir alıcı / ayarlayıcıda bir kesme noktası ayarlayamazsınız.
• NOT: Bu Referans Arama, ilk düşündüğüm gibi bir sorun değildir. Anahat görünümünü etkinleştiren bir perspektif kullanmanız gerekir. Çoğu geliştirici için sorun değil. Benim sorunum, benim Outlinegörüşümü filtreleyen Mylyn kullanıyordum , bu yüzden yöntemleri görmedim. Referans arama eksikliği. Kimin aradığını görmek getDynamicCols(args...)istersem, referansları arayabilmek için ayarlayıcıyı oluşturmalı veya kodlamalıyım.

GÜNCELLEME 3 (Mar 7 '13)
Eclipse'de bir şeyler yapmanın çeşitli yollarını kullanmayı öğrenmek sanırım. Aslında Lombok tarafından üretilen bir yöntem üzerinde koşullu bir kesme noktası (BP) ayarlayabilirsiniz. OutlineGörünümü kullanarak yöntemi sağ tıklayabilirsiniz Toggle Method Breakpoint. Daha sonra KB'ye bastığınızda Variables, oluşturulan yöntemin parametreleri adlandırdığı (genellikle alan adıyla aynı) ne olduğunu görmek için hata ayıklama görünümünü kullanabilirsiniz ve son olarak, BreakpointsBP'yi sağ tıklayıp Breakpoint Properties...bir koşul eklemek için görünümü kullanın . Güzel.

GÜNCELLEME 4 (16 Ağustos
2013 ) Netbeans, Maven pom'unuzdaki Lombok bağımlılıklarınızı güncellediğinizde hoşlanmıyor. Proje hala derleniyor, ancak Lombok'un oluşturduğu yöntemleri göremediği için dosyalar derleme hataları nedeniyle işaretleniyor. Netbeans önbelleğini temizlemek sorunu çözer. Eclipse'de olduğu gibi bir "Projeyi Temizle" seçeneği olup olmadığından emin değilim. Küçük bir sorun, ama bunu duyurmak istedim.

GÜNCELLEME 5 (17 Ocak 14)
Lombok Groovy ile her zaman iyi oynamaz, ya da en azından groovy-eclipse-compiler. Derleyici sürümünüzü eski sürüme geçirmeniz gerekebilir. Maven Groovy ve Java + Lombok

GÜNCELLEME 6 (26 Haziran 14)
Bir uyarı sözü. Lombok biraz bağımlılık yapar ve bir nedenden ötürü kullanamayacağınız bir proje üzerinde çalışırsanız, işemek sizi rahatsız edecektir. Hiç kullanmamanız daha iyi olabilir.

GÜNCELLEME 7 (23 Temmuz 14)
Bu ilginç bir güncelleme, çünkü OP'nin sorduğu Lombok'u benimseme güvenliğini doğrudan ele alıyor .

Sürüm 1.1'den itibaren, @Delegateek açıklama Deneysel bir duruma indirgenmiştir. Detaylar kendi sitesinde belgelenmiştir ( Lombok Delege Belgeleri ).

Mesele şu ki, bu özelliği kullanıyorsanız, geri çekme seçenekleriniz sınırlıdır. Seçenekleri şöyle görüyorum:

• Manuel olarak kaldır @DelegateEk açıklamaları ve temsilci kodunu oluşturun / el ile kodlayın. Ek açıklama içinde nitelikler kullanıyorsanız bu biraz daha zordur.
• @DelegateEk açıklamaya sahip dosyaları delombok edin ve belki istediğiniz ek açıklamalara geri ekleyin.
• Lombok'u asla güncellemeyin ya da bir çatal bulundurmayın (ya da deneyimsel özellikler kullanarak yaşayın).
• Tüm projenizi delombok edin ve Lombok'u kullanmayı bırakın.

Anlayabildiğim kadarıyla Delombok'un ek açıklamaların bir alt kümesini kaldırma seçeneği yok ; en azından tek bir dosya bağlamında ya hep ya hiç. Delombok bayrakları ile bu özelliği talep etmek için bir bilet açtım , ancak yakın gelecekte bunu beklemem.

GÜNCELLEME 8 (20 Ekim 14)
Sizin için bir seçenekse Groovy, Lombok'un aynı avantajlarının çoğunu ve ayrıca @Delegate dahil olmak üzere diğer özelliklerin bir tekne yükünü sunar . Eğer bu güçlere fikrini satan zor bir zaman olacak düşünüyorsanız, bir göz atın @CompileStaticveya @TypeCheckedo neden yardımcı olmadığını görmek için ek açıklama. Aslında, Groovy 2.0 sürümünün ana odağı statik güvenlikti .

GÜNCELLEME 9 (1 Eylül '15)
Lombok hala aktif olarak sürdürülmekte ve geliştirilmektedir ; @Builder ek açıklamalar sevdiğim yeni özelliklerden biridir.

GÜNCELLEME 10 (17 Kasım 15)
Bu doğrudan OP'nin sorusuyla ilgili değil, paylaşmaya değer görünebilir. Yazdığınız kaynak plakası miktarını azaltmanıza yardımcı olacak araçlar arıyorsanız Google Auto'ya , özellikle de AutoValue'ya da göz atabilirsiniz . Onların slayt güvertesine bakarsanız, Lombok listesi çözmeye çalıştıkları soruna olası bir çözüm olarak. Lombok için listelediği eksiler:

• Girilen kod görünmez (oluşturduğu yöntemleri "göremezsiniz") [ed note - aslında yapabilirsiniz, ancak sadece bir dekompresör gerektirir]
• Derleyici saldırıları standart ve kırılgandır
• "Bizim görüşümüze göre, kodunuz artık gerçekten Java değil"

Değerlendirmelerine ne kadar katıldığımdan emin değilim. Ve slaytlarda belgelenen AutoValue eksilerini göz önüne alındığında, ben Lombok ile yapışacağım (Groovy bir seçenek değilse).

GÜNCELLEME 11 ('16 Şubat 8)
öğrendim Bahar Roo bazılarına sahiptir benzer açıklamalarını . Roo'nun hala bir şey olduğunu öğrenmek için biraz şaşırdım ve ek açıklamalar için doküman bulmak biraz kaba. Kaldırma işlemi de-lombok kadar kolay görünmüyor. Lombok daha güvenli bir seçim gibi görünüyor.

GÜNCELLEME 12 (17 Şubat 16)
Şu anda üzerinde çalıştığım proje için Lombok'u getirmenin neden güvenli olduğuna dair gerekçeler bulmaya çalışırken, bir parça altın buldum v1.14- Konfigürasyon Sistemi ! Bu, bir projeyi ekibinizin güvensiz veya istenmeyen bulduğu belirli özelliklerin kullanılmasına izin vermeyecek şekilde yapılandırabileceğiniz anlamına gelir. Daha da iyisi, farklı ayarlarla dizine özgü yapılandırma da oluşturabilir. Bu harika.

GÜNCELLEME 13 (4 Ekim 16)
Bu tür bir şey sizin için önemliyse , Oliver Gierke , Lombok'u Spring Data Rest'e eklemenin güvenli olduğunu düşündü .

GÜNCELLEME 14 (26 Eylül '17) OP sorusu hakkındaki yorumlarda @gavenkoa
tarafından belirtildiği gibi , JDK9 derleyici desteği henüz mevcut değil (Sayı # 985). Ayrıca Lombok ekibinin dolaşması kolay bir düzeltme olmayacak gibi görünüyor.

GÜNCELLEME 15 (
26.03.2018 ) Lombok changelog v1.16.20'den itibaren " JDK1.9'da lombok derlemek artık mümkün " ifadesini gösteriyor # 985 hala açık .

Bununla birlikte, JDK9'u barındıracak değişiklikler bazı kırılma değişikliklerini gerektirdi; tümü yapılandırma varsayılanlarındaki değişikliklerle yalıtılmıştır. Kırılma değişiklikleri getirmeleri biraz endişe verici, ancak sürüm sadece "Artımlı" sürüm numarasını çarptı (v1.16.18'den v1.16.20'ye kadar). Bu yazı güvenlikle ilgili olduğu için,yarn/npm , otomatik olarak en son artan sürüme yükseltilen benzer bir oluşturma sisteminiz varsa, kaba bir uyanış için olabilirsiniz.

GÜNCELLEME 16 (9 Ocak 1919)

Görünüşe göre JDK9 sorunları çözüldü ve Lombok JDK10 ve hatta JDK11 ile çalışabildiğim kadarıyla çalışıyor.

Güvenlik açısından ilgili olduğunu fark ettiğim bir şey, v1.18.2'den v1.18.4'e değişen değişiklik günlüğünün iki öğeyi BREAKING CHANGE! Bir semver "yama" güncellemesinde nasıl bir değişiklik gerçekleştiğinden emin değilim. Yama sürümlerini otomatik olarak güncelleyen bir araç kullanırsanız sorun olabilir.

Devam edin ve Lombok kullanın, gerekirse daha sonra kodunuzu "delombok" yapabilirsiniz http://projectlombok.org/features/delombok.html

Şahsen (ve dolayısıyla öznel olarak) Lombok kullanmanın, IDE / hashcode & equals gibi karmaşık yöntemlerin uygulamalarına kıyasla elde etmeye çalıştığım şey hakkında kodumu daha anlamlı hale getirdiğini gördüm.

Kullanırken

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

Equals ve HashCode'u tutarlı tutmak ve hangi alanların değerlendirildiğini takip etmek, herhangi bir IDE / kendi uygulamasından daha kolaydır. Bu, özellikle düzenli aralıklarla alan eklerken / kaldırırken geçerlidir.

Aynı durum, @ToStringdahil edilen / hariç tutulan alanlar, alıcıların kullanımı veya alan erişimi ile aranıp aranmayacağı konusunda istenen davranışı açıkça bildiren ek açıklama ve parametreleri için de geçerlidir.super.toString() .

Ve yine, tüm bir sınıfa @Getterveya @Setter(AccessLevel.NONE)(ve isteğe bağlı olarak herhangi bir ıraksak yöntemi geçersiz kılan) açıklama ekleyerek, alanlar için hangi yöntemlerin kullanılabilir olacağını hemen anlarsınız.

Faydaları devam ediyor ..

Zihnimde bu, kodu azaltmak değil, Javadoc veya uygulamalardan anlamak yerine, elde etmek istediğiniz şeyi açıkça iletmekle ilgili. İndirgenmiş kod, tüm ıraksak yöntem uygulamalarını tespit etmeyi kolaylaştırır.

Lombok harika, ama ...

Lombok, yeni kaynak dosyaları üretmemesi nedeniyle ek açıklama işleminin kurallarını ihlal ediyor. Bu, alıcılar / ayarlayıcılar veya başka bir şey olmasını beklerse, başka bir ek açıklama işlemcileriyle kullanılamayacağı anlamına gelir.

Ek açıklama işleme bir dizi turda yapılır. Her turda, her biri koşmak için bir sıra alır. Tur tamamlandıktan sonra yeni java dosyaları bulunursa, başka bir tur başlar. Bu şekilde, ek açıklama işlemcilerinin sırası yalnızca yeni dosyalar oluşturup oluşturmadıkları önemli değildir. Lombok herhangi bir yeni dosya oluşturmadığından, yeni mermiler başlatılmadığından, lombok koduna dayanan bazı AP'ler beklendiği gibi çalışmaz. Bu, mapstruct kullanırken benim için büyük bir acı kaynağıydı ve delombok-ing, satır numaralarınızı günlüklerde yok ettiği için kullanışlı bir seçenek değil.

Sonunda hem lombok hem de mapstruct ile çalışmak için bir komut dosyası hackledim. Ama en azından bu projede ne kadar hileli olduğundan lombok bırakmak istiyorum. Ben lombok'u her zaman başka şeylerde kullanıyorum.

Lombok hakkında bazı görüşler okudum ve aslında bazı projelerde kullanıyorum.

Lombok ile ilk temasta kötü bir izlenim edindim. Birkaç hafta sonra beğenmeye başladım. Ama birkaç ay sonra bunu kullanırken bir sürü ufak problem anladım. Yani, Lombok hakkındaki son izlenim o kadar olumlu değil.

Bu şekilde düşünme nedenlerim:

• IDE eklentisi bağımlılığı . Lombok için IDE desteği eklentiler aracılığıyla. Çoğu zaman iyi çalışsa bile, IDE'lerin gelecekteki sürümlerinde ve hatta dil versiyonunda (Java 10+ dilin gelişimini hızlandıracaktır) her zaman bu eklentilerden bir rehine vardır . Örneğin, Intellij IDEA 2017.3'ten 2018.1'e güncelleme yapmaya çalıştım ve bunu yapamadım çünkü gerçek lombok eklentisi sürümünde bir sorun vardı ve eklentinin güncellenmesini beklemem gerekiyordu ... herhangi bir Lombok eklenti desteği olmayan daha alternatif bir IDE kullanmak istiyor.
• 'Kullanımları bul' sorunu. . Lombok'u kullanarak oluşturulan alıcı, ayarlayıcı, oluşturucu, oluşturucu yöntemleri vb. Görmüyorsunuz. Dolayısıyla, bu yöntemlerin IDE'niz tarafından projenizde nerede kullanıldığını bulmayı planlıyorsanız, bunu sadece görünümlü yapamazsınız. bu gizli yöntemlere sahip olan sınıf için.
• O kadar kolay ki geliştiriciler kapsüllemeyi kırmayı umursamıyor . Lombok'tan bir sorun olmadığını biliyorum. Ancak, geliştiricilerin artık hangi yöntemlerin görünür olması veya olmaması gerektiğini kontrol etmeme eğiliminde olduklarını gördüm. Yani, çoğu zaman @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructor, sınıfın gerçekten hangi yöntemleri ortaya çıkarması gerektiğini düşünmeden ek açıklamaları kopyalayıp yapıştırıyorlar .
• Oluşturucu Takıntısı ©. Bu ismi icat ettim (inin, Martin Fowler). Şakalar, bir Builder oluşturmak o kadar kolaydır ki, bir sınıf sadece iki parametreye sahip olsa bile, geliştiriciler @Builderyapıcı veya statik yapıcı yöntemi yerine kullanmayı tercih ederler . Bazen lombok Builder içinde bir Builder oluşturmaya çalışırlar ve tuhaf durumlar yaratırlar MyClass.builder().name("Name").build().create().
• Yeniden düzenleme sırasındaki engeller . Örneğin a kullanıyorsanız @AllArgsConstructorve yapıcıya bir parametre daha eklemeniz gerekiyorsa, IDE bu ekstra parametreyi sınıfı başlatan tüm yerlere (çoğunlukla testler) eklemenize yardımcı olamaz.
• Lombok'un beton yöntemlerle karıştırılması . Alıcı / ayarlayıcı / vb. Oluşturmak için tüm senaryolarda Lombok'u kullanamazsınız. Yani, bu iki yaklaşımın kodunuzda karışık olduğunu göreceksiniz. Bir süre sonra buna alışırsınız, ancak dilde bir hack gibi hissedersiniz.

Bir başka cevabın söylediği gibi, Java ayrıntısına öfkeli iseniz ve Lombok'u bununla başa çıkmak için kullanıyorsanız, Kotlin'i deneyin.

Uzun vadeli bakım riskleri de vardır. Birincisi, onun geliştiricilerden örneğin bazı cevaplar, Lombok gerçekten nasıl çalıştığı konusunda okumanızı tavsiye ediyorum burada .

Resmi site ayrıca Reinier Zwitserloot'un bu alıntısı da dahil olmak üzere olumsuzlukların bir listesini içerir :

Bu tamamen bir hack. Herkese açık olmayan API kullanma. Küstah döküm (javac'ta çalışan bir ek açıklama işlemcisinin, AnnotationProcessor'un (bir arayüz) dahili uygulaması olan JavacAnnotationProcessor örneğini alacağını bilmek, bu da canlı AST'de almak için kullanılan birkaç ek yönteme sahip olur) .

Tutulmada, tartışmasız daha kötü (ve yine de daha sağlam) - bir java ajanı, elbette tamamen halka açık olmayan API ve tamamen kapalı sınırlar olan eclipse gramer ve ayrıştırıcı sınıfına kod enjekte etmek için kullanılır.

Lombok'un standart API ile yaptığı şeyi yapabilseydiniz, bunu bu şekilde yapardım, ama yapamazsınız. Yine de, değeri için, java 1.6 üzerinde çalışan eclipse v3.5 için eclipse eklentisini geliştirdim ve herhangi bir değişiklik yapmadan java 1.5 üzerinde çalışan eclipse v3.4 üzerinde de çalıştı, bu yüzden tamamen kırılgan değil.

Özet olarak, Lombok size bir miktar geliştirme süresi kazandırabilir, ancak geriye dönük olarak uyumlu olmayan bir javac güncellemesi varsa (örneğin bir güvenlik açığı azaltma) Lombok, geliştiriciler bunların dahili API'lar. Bunun ciddi bir risk olup olmadığı açıkça projeye bağlıdır.

Geç kaldığımı biliyorum, ama günaha karşı koyamam: Lombok'u seven herkes de Scala'ya bakmalı. Lombok'ta bulduğunuz birçok iyi fikir Scala dilinin bir parçasıdır.

Sorunuz üzerine: geliştiricilerinizi Lombok'u denemek Scala'dan daha kolay. Bir deneyin ve hoşuna giderse Scala'yı deneyin.

Tıpkı bir feragatname olarak: Java'yı da seviyorum!

Lombok'u neredeyse tüm projelerimde bir yıl kullandım ama maalesef kaldırdım. Başlangıçta çok temiz bir gelişim yoluydu ama yeni ekip üyeleri için geliştirme ortamını kurmak çok kolay ve anlaşılır değil. Baş ağrısı olduğunda, onu çıkardım. Ancak bu iyi bir iştir ve kurulum için biraz daha basitliğe ihtiyaç duyar.

Projeyi ekibime gösterdiğimde coşku yüksekti, bu yüzden takımın tepkisinden korkmamanız gerektiğini düşünüyorum.

• YG'ye göre, entegre etmek çok kolaydır ve temel biçiminde kod değişikliği gerektirmez. (yalnızca sınıfınıza tek bir açıklama ekleyerek)

• Ve son olarak, fikrinizi değiştirirseniz, çözmeyi çalıştırabilir veya IDE'nizin bu setterleri, alıcıları ve ctorları oluşturmasına izin verebilirsiniz (ki bence hiç kimse pojo'nuzun ne kadar netleştiğini gördükten sonra istemeyecektir)

Lombok'u benim almam sadece bolilerplate Java kodu yazmak için kısayollar sağlaması.
Bolilerplate Java kodu yazmak için kısayollar söz konusu olduğunda, Eclipse'de olduğu gibi IDE tarafından sağlanan bu özelliklere güvenirim, alıcılar ve ayarlayıcılar oluşturmak için Kaynak> Getters ve Setters Oluştur menüsüne gidebiliriz.
Bunun için Lombok gibi bir kütüphaneye güvenmezdim:

1. Kodunuzu alternatif bir sözdizimi dolaylı katmanıyla kirletir (okuma @Getter,@Setter vb ek açıklamalar). Java için alternatif bir sözdizimi öğrenmek yerine, Lombok benzeri sözdizimini yerel olarak sağlayan başka bir dile geçirdim.
2. Lombok, kodunuzla çalışmak için Lombok destekli bir IDE kullanılmasını gerektirir. Bu bağımlılık, önemsiz olmayan herhangi bir proje için önemli bir risk oluşturmaktadır. Açık kaynaklı Lombok projesi, çok çeşitli Java IDE'lerin farklı sürümleri için destek sağlamak için yeterli kaynağa sahip mi?
3. Açık kaynak Lombok projesinin gelecekte çıkacak yeni Java sürümlerine destek sağlamak için yeterli kaynağı var mı?
4. Lombok'un, çalışma zamanında bayt kodunuzla çalışan yaygın olarak kullanılan çerçeveler / kütüphanelerle (Spring, Hibernate, Jackson, JUnit, Mockito gibi) uyumluluk sorunları getirebileceğinden endişeliyim.

Sonuçta ben Java ile Lombok "baharat" tercih etmem.

Lombok'ları kullanmak istedim @ToString ancak yakında Intellij IDEA'da proje yeniden yapılandırmasında rastgele derleme hatalarıyla karşı karşıya kaldı. Artımlı derleme başarı ile tamamlanmadan önce birkaç kez derlemek zorunda kaldı.

Jdk 1.6.0_39 ve 1.6.0_45 altında herhangi bir lombok eklentisi olmadan hem lombok 1.12.2 hem de 0.9.3'ü Intellij IDEA 12.1.6 ve 13.0 ile denedi.

El ile delomboked kaynaktan oluşturulan yöntemleri kopyalamak ve daha iyi zamanlara kadar beklemeye koymak zorunda kaldı.

Güncelleme

Sorun yalnızca paralel derleme etkinken oluşur.

Bir sorun açtı: https://github.com/rzwitserloot/lombok/issues/648

Güncelleme

mplushnikov yorumladı 30 Ocak 2016:

Intellij'in daha yeni sürümünde artık böyle sorunlar yok. Bence burada kapatılabilir.

Güncelleme

Mümkünse Java + Lombok Kotlin için geçiş tavsiye . Başından beri Lombok'un etrafta dolaşmaya çalıştığı tüm Java sorunlarını çözdü.

Lombok ve Jackson CSV ile ilgili bir sorunla karşılaştım , nesnemi (java fasulyesi) bir CSV dosyasına, çoğaltılan sütunlara marshalize ettiğimde, Lombok'un @Data ek açıklamasını kaldırdım ve mareşalleştirme iyi çalıştı.

Ben tavsiye etmiyorum. Eskiden kullanıyordum, ancak NetBeans 7.4 ile çalıştığımda kodlarımı karıştırıyordu. Projelerimdeki tüm dosyalarda lombok'u kaldırmam gerekiyor. Delombok var, ama kodlarımı vidalamayacağından nasıl emin olabilirim. Ben sadece lombok kaldırmak ve sıradan Java stilleri geri gün geçirmek zorunda. Çok baharatlıyım ...

Lombok'u henüz denemedim - listemde bir sonraki / öyleydi, ancak Java 8 önemli sorunlara neden olmuş gibi görünüyor ve iyileştirme çalışmaları bir hafta önce hala sürüyor. Bunun için kaynağım https://code.google.com/p/projectlombok/issues/detail?id=451 .