Apakah aman menggunakan Project Lombok? [Tutup]

Jika Anda tidak tahu Project Lombok membantu dengan beberapa gangguan Jawa dengan hal-hal seperti menghasilkan getter dan setter dengan anotasi dan bahkan generasi seperti JavaBean sederhana dengan @ Data . Ini bisa sangat membantu saya, terutama di 50 objek acara yang berbeda di mana Anda memiliki hingga 7 bidang berbeda yang perlu dibangun dan disembunyikan dengan getter. Saya bisa menghapus hampir seribu baris kode dengan ini.

Namun, saya khawatir bahwa dalam jangka panjang, itu akan menjadi keputusan yang menyesal. Flamewars akan meletus di ##Java Freenodesaluran ketika saya menyebutkannya, memberikan cuplikan kode akan membingungkan para pembantu, orang-orang akan mengeluh tentang kehilangan JavaDoc , dan para komitmen di masa depan mungkin akan menghapus semuanya. Saya akan sangat menikmati yang positif, tetapi saya khawatir tentang yang negatif.

Jadi: Apakah aman menggunakan Lombok pada proyek apa pun, kecil atau besar? Apakah efek positifnya bernilai negatif?

Sepertinya Anda sudah memutuskan bahwa Proyek Lombok memberi Anda keuntungan teknis yang signifikan untuk proyek baru yang Anda usulkan. (Untuk menjadi jelas sejak awal, saya tidak memiliki pandangan khusus tentang Proyek Lombok, satu atau lain cara.)

Sebelum Anda menggunakan Project Lombok (atau teknologi pengubah permainan lainnya) dalam beberapa proyek (open source atau lainnya), Anda perlu memastikan bahwa pemegang saham proyek menyetujui hal ini. Ini termasuk pengembang, dan setiap pengguna penting (mis. Sponsor formal atau informal).

Anda menyebutkan masalah potensial ini:

Flamewars akan meledak di saluran Java Freenode ## ketika saya menyebutkannya,

Mudah. Abaikan / jangan berpartisipasi dalam flamewars, atau cukup menahan diri untuk tidak menyebut Lombok.

memberikan cuplikan kode akan membingungkan calon pembantu,

Jika strategi proyek adalah menggunakan Lombok, maka para pembantu mungkin perlu membiasakan diri dengannya.

orang akan mengeluh tentang kehilangan JavaDoc,

Itu masalah mereka. Tidak ada orang waras yang mencoba menerapkan secara kaku kode sumber / aturan dokumentasi organisasi mereka ke perangkat lunak sumber terbuka pihak ketiga. Tim proyek harus bebas menetapkan kode sumber proyek / standar dokumentasi yang sesuai dengan teknologi yang digunakan.

( FOLLOWUP - Pengembang Lombok menyadari bahwa tidak menghasilkan komentar javadoc untuk metode pengambil dan penyetel yang disintesis adalah masalah. Jika ini merupakan masalah utama bagi proyek Anda, maka salah satu alternatif adalah membuat dan mengirimkan tambalan Lombok untuk mengatasi hal ini. )

dan komitmen di masa depan mungkin akan menghapus semuanya.

Itu tidak aktif! Jika strategi proyek yang disepakati adalah menggunakan Lombok, maka para komisioner yang secara tidak sengaja membatalkan kode tersebut harus dihukum, dan jika perlu hak komitmen mereka ditarik.

Tentu saja, ini mengasumsikan bahwa Anda mendapat dukungan dari para pemangku kepentingan ... termasuk para pengembang. Dan itu mengasumsikan bahwa Anda siap untuk memperdebatkan tujuan Anda, dan secara tepat menangani suara-suara berbeda yang tak terhindarkan.

Baru mulai menggunakan Lombok hari ini. Sejauh ini saya menyukainya, tetapi satu kekurangan yang tidak saya lihat disebutkan adalah dukungan refactoring.

Jika Anda memiliki kelas yang dianotasi @Data, itu akan menghasilkan getter dan setter untuk Anda berdasarkan nama bidang. Jika Anda menggunakan salah satu getter di kelas lain, lalu memutuskan bahwa field tersebut tidak memiliki nama yang baik, ia tidak akan menemukan penggunaan getter dan setter tersebut dan mengganti nama lama dengan nama baru.

Saya akan membayangkan ini harus dilakukan melalui plug-in IDE dan bukan melalui Lombok.

PEMBARUAN (22 Jan '13)
Setelah menggunakan Lombok selama 3 bulan, saya masih merekomendasikannya untuk sebagian besar proyek. Namun, saya menemukan kelemahan lain yang serupa dengan yang tercantum di atas.

Jika Anda memiliki kelas, katakanlah MyCompoundObject.javamemiliki 2 anggota, keduanya beranotasi dengan @Delegate, katakan myWidgetsdan myGadgets, ketika Anda menelepon myCompoundObject.getThingies()dari kelas lain, tidak mungkin untuk mengetahui apakah itu mendelegasikan ke Widgetatau Gadgetkarena Anda tidak lagi dapat melompat ke sumber dalam IDE.

Menggunakan Eclipse "Hasilkan Metode Delegasi ..." memberi Anda fungsionalitas yang sama, sama cepatnya dan memberikan lompatan sumber. Kelemahannya adalah itu mengacaukan sumber Anda dengan kode boilerplate yang mengambil fokus dari hal-hal penting.

UPDATE 2 (26 Feb '13)
Setelah 5 bulan, kami masih menggunakan Lombok, tetapi saya memiliki beberapa gangguan lainnya. Kurangnya pengambil dan penyetel yang dideklarasikan dapat mengganggu saat Anda mencoba membiasakan diri dengan kode baru.

Sebagai contoh, jika saya melihat metode yang disebut getDynamicCols()tetapi saya tidak tahu tentang apa itu, saya memiliki beberapa rintangan ekstra untuk melompat untuk menentukan tujuan dari metode ini. Beberapa rintangannya adalah Lombok, ada juga yang kekurangan plugin pintar Lombok. Rintangan termasuk:

• Kurangnya JavaDocs. Jika saya javadoc lapangan, saya berharap pengambil dan penyetel akan mewarisi javadoc melalui langkah kompilasi Lombok.
• Langsung ke definisi metode melompat saya ke kelas, tetapi bukan properti yang menghasilkan pengambil. Ini adalah masalah plugin.
• Jelas Anda tidak dapat mengatur breakpoint dalam pengambil / penyetel kecuali Anda menghasilkan atau kode metode.
• CATATAN: Pencarian Referensi ini bukan masalah seperti yang saya pikirkan sebelumnya. Anda harus menggunakan perspektif yang memungkinkan tampilan Outline. Bukan masalah bagi kebanyakan pengembang. Masalah saya adalah saya menggunakan Mylyn yang memfilter Outlinepandangan saya , jadi saya tidak melihat metode. Kurangnya referensi pencarian. Jika saya ingin melihat siapa yang menelepon getDynamicCols(args...), saya harus membuat atau memberi kode pada setter untuk dapat mencari referensi.

UPDATE 3 (Mar 7 '13)
Belajar menggunakan berbagai cara untuk melakukan sesuatu di Eclipse kurasa. Anda benar-benar dapat mengatur breakpoint bersyarat (BP) pada metode yang dihasilkan Lombok. Menggunakan Outlinetampilan, Anda dapat mengklik kanan metode untuk Toggle Method Breakpoint. Kemudian ketika Anda menekan BP, Anda dapat menggunakan tampilan debugging Variablesuntuk melihat apa metode yang dihasilkan menamai parameter (biasanya sama dengan nama bidang) dan akhirnya, gunakan Breakpointstampilan untuk mengklik kanan BP dan pilih Breakpoint Properties...untuk menambahkan kondisi. Bagus.

UPDATE 4 (16 Agustus '13)
Netbeans tidak menyukainya ketika Anda memperbarui dependensi Lombok Anda di Maven pom Anda. Proyek masih mengkompilasi, tetapi file ditandai karena memiliki kesalahan kompilasi karena tidak dapat melihat metode yang dibuat Lombok. Menghapus cache Netbeans menyelesaikan masalah. Tidak yakin apakah ada opsi "Bersihkan Proyek" seperti yang ada di Eclipse. Masalah kecil, tetapi ingin membuatnya diketahui.

UPDATE 5 (17 Jan '14)
Lombok tidak selalu bermain baik dengan Groovy, atau setidaknya groovy-eclipse-compiler. Anda mungkin harus menurunkan versi kompiler Anda. Maven Groovy dan Jawa + Lombok

UPDATE 6 (26 Jun '14)
Sebuah kata peringatan. Lombok sedikit membuat ketagihan dan jika Anda mengerjakan suatu proyek di mana Anda tidak dapat menggunakannya karena suatu alasan, Lombok akan mengganggu Anda. Anda mungkin lebih baik tidak pernah menggunakannya sama sekali.

UPDATE 7 (23 Juli '14)
Ini adalah pembaruan yang menarik karena langsung membahas keamanan mengadopsi Lombok yang ditanyakan OP.

Pada v1.14, @Delegateanotasi telah diturunkan ke status Eksperimental. Rinciannya didokumentasikan di situs mereka ( Lombok Delegate Docs ).

Masalahnya adalah, jika Anda menggunakan fitur ini, opsi backout Anda terbatas. Saya melihat opsi sebagai:

• Hapus @Delegateanotasi secara manual dan hasilkan / handcode kode delegasi. Ini sedikit lebih sulit jika Anda menggunakan atribut dalam anotasi.
• Delombok file yang memiliki @Delegateanotasi dan mungkin menambahkan kembali dalam anotasi yang Anda inginkan.
• Jangan pernah memperbarui Lombok atau memelihara garpu (atau hidup dengan menggunakan fitur pengalaman).
• Delombok seluruh proyek Anda dan berhenti menggunakan Lombok.

Sejauh yang saya tahu, Delombok tidak memiliki opsi untuk menghapus subset dari anotasi ; itu semua atau tidak sama sekali setidaknya untuk konteks satu file. Saya membuka tiket untuk meminta fitur ini dengan bendera Delombok, tetapi saya tidak akan mengharapkan itu dalam waktu dekat.

UPDATE 8 (20 Okt '14)
Jika ini merupakan pilihan bagi Anda, Groovy menawarkan sebagian besar manfaat yang sama dari Lombok, plus banyak fitur lainnya, termasuk @Delegate . Jika Anda berpikir Anda akan kesulitan menjual ide kepada kekuatan yang ada, lihat @CompileStaticatau @TypeCheckedanotasi untuk melihat apakah itu dapat membantu perjuangan Anda. Faktanya, fokus utama dari rilis Groovy 2.0 adalah keamanan statis .

UPDATE 9 (Sep 1 '15)
Lombok masih dipelihara dan ditingkatkan secara aktif , yang menjadi pertanda baik untuk tingkat keamanan adopsi. The @Builder penjelasan adalah salah satu fitur favorit saya baru.

UPDATE 10 (17 Nov '15)
Ini mungkin tidak terkait langsung dengan pertanyaan OP, tetapi layak untuk dibagikan. Jika Anda mencari alat untuk membantu Anda mengurangi jumlah kode boilerplate yang Anda tulis, Anda juga dapat memeriksa Google Auto - khususnya AutoValue . Jika Anda melihat slide deck mereka , daftar Lombok sebagai solusi yang mungkin untuk masalah yang mereka coba selesaikan. Kontra yang mereka daftarkan untuk Lombok adalah:

• Kode yang dimasukkan tidak terlihat (Anda tidak dapat "melihat" metode yang dihasilkannya) [ed note - sebenarnya Anda bisa, tetapi itu hanya membutuhkan dekompiler]
• Retasan kompiler tidak standar dan rapuh
• "Dalam pandangan kami, kode Anda tidak lagi benar-benar Java"

Saya tidak yakin seberapa besar saya setuju dengan evaluasi mereka. Dan mengingat kontra dari AutoValue yang didokumentasikan dalam slide, saya akan tetap dengan Lombok (jika Groovy bukan pilihan).

PEMBARUAN 11 (8 Februari '16)
Saya menemukan Spring Roo memiliki beberapa anotasi serupa . Saya sedikit terkejut mengetahui bahwa Roo masih ada dan menemukan dokumentasi untuk penjelasannya agak kasar. Penghapusan juga tidak terlihat semudah de-lombok. Lombok sepertinya pilihan yang lebih aman.

UPDATE 12 (17 Feb '16)
Ketika mencoba mencari pembenaran untuk alasan mengapa aman membawa Lombok untuk proyek yang sedang saya kerjakan, saya menemukan sepotong emas yang ditambahkan dengan v1.14- Sistem Konfigurasi ! Ini artinya Anda dapat mengonfigurasi proyek untuk menonaktifkan fitur tertentu yang dianggap tidak aman atau tidak diinginkan oleh tim Anda. Lebih baik lagi, itu juga dapat membuat konfigurasi direktori khusus dengan pengaturan yang berbeda. Ini LUAR BIASA.

UPDATE 13 (4 Okt '16)
Jika hal seperti ini penting bagi Anda, Oliver Gierke merasa aman untuk menambahkan Lombok ke Spring Data Rest .

UPDATE 14 (Sep 26 '17)
Seperti yang ditunjukkan oleh @gavenkoa dalam komentar pada pertanyaan OPs , dukungan kompiler JDK9 belum tersedia (Masalah # 985). Ini juga terdengar seperti itu tidak akan menjadi perbaikan yang mudah bagi tim Lombok untuk berkeliling.

UPDATE 15 (26 Mar 1818)
Lombok changelog menunjukkan pada v1.16.20 " Kompilasi lombok di JDK1.9 sekarang mungkin " meskipun # 985 masih terbuka.

Namun, perubahan untuk mengakomodasi JDK9 mengharuskan beberapa perubahan; semua diisolasi untuk perubahan dalam konfigurasi standar. Agak memprihatinkan bahwa mereka memperkenalkan pemecahan perubahan, tetapi versi ini hanya menabrak nomor versi "Tambahan" (dari v1.16.18 ke v1.16.20). Karena postingan ini adalah tentang keamanan, jika Anda memiliki sistem yarn/npmseperti build yang secara otomatis ditingkatkan ke versi incremental terbaru, Anda mungkin berada dalam kondisi sulit.

UPDATE 16 (9 Jan '19)

Tampaknya masalah JDK9 telah diselesaikan dan Lombok bekerja dengan JDK10, dan bahkan JDK11 sejauh yang saya tahu.

Satu hal yang saya perhatikan dari aspek keselamatan adalah fakta bahwa log perubahan dari v1.18.2 ke v1.18.4 mencantumkan dua item sebagai BREAKING CHANGE!? Saya tidak yakin bagaimana perubahan yang terjadi terjadi pada pembaruan "tambalan" semver. Bisa jadi masalah jika Anda menggunakan alat yang memperbarui versi tambalan secara otomatis.

Silakan dan gunakan Lombok, Anda dapat jika perlu "delombok" kode Anda setelah itu http://projectlombok.org/features/delombok.html

Secara pribadi (dan karenanya secara subyektif) saya telah menemukan bahwa menggunakan Lombok membuat kode saya lebih ekspresif tentang apa yang saya coba capai bila dibandingkan dengan IDE / implementasi sendiri dari metode yang rumit seperti kode hash & sama dengan.

Ketika menggunakan

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

jauh lebih mudah untuk menjaga Equals & HashCode konsisten dan melacak bidang mana yang dievaluasi, daripada setiap IDE / implementasi sendiri. Ini terutama benar ketika Anda masih menambahkan / menghapus bidang secara teratur.

Hal yang sama berlaku untuk @ToStringanotasi dan parameternya yang dengan jelas mengomunikasikan perilaku yang diinginkan mengenai bidang yang disertakan / dikecualikan, penggunaan getter atau akses bidang dan apakah atau tidak untuk memanggil super.toString().

Dan lagi dengan membubuhi keterangan seluruh kelas dengan @Getteratau @Setter(AccessLevel.NONE)(dan secara opsional mengesampingkan metode yang berbeda) segera jelas metode apa yang akan tersedia untuk bidang.

Manfaat terus dan terus ..

Dalam pikiran saya ini bukan tentang mengurangi kode, tetapi tentang mengkomunikasikan dengan jelas apa yang ingin Anda capai, daripada harus mencari tahu dari Javadoc atau implementasi. Pengurangan kode hanya membuat lebih mudah untuk menemukan implementasi metode divergen.

Lombok bagus, tapi ...

Lombok melanggar aturan pemrosesan anotasi, karena tidak menghasilkan file sumber baru. Ini berarti tidak dapat digunakan dengan prosesor anotasi lain jika mereka mengharapkan getter / setter atau apa pun yang ada.

Pemrosesan anotasi berjalan dalam serangkaian putaran. Di setiap putaran, masing-masing mendapat giliran untuk berlari. Jika ada file java baru ditemukan setelah putaran selesai, putaran lain dimulai. Dengan cara ini, urutan prosesor anotasi tidak masalah jika mereka hanya menghasilkan file baru. Karena lombok tidak menghasilkan file baru, tidak ada babak baru yang dimulai sehingga beberapa AP yang bergantung pada kode lombok tidak berjalan seperti yang diharapkan. Ini adalah sumber rasa sakit yang sangat besar bagi saya saat menggunakan mapstruct, dan delombok-ing bukan pilihan yang berguna karena itu menghancurkan nomor baris Anda dalam log.

Saya akhirnya meretas skrip build untuk bekerja dengan lombok dan mapstruct. Tapi saya ingin menjatuhkan lombok karena betapa ruwetnya - setidaknya dalam proyek ini. Saya menggunakan lombok sepanjang waktu dalam hal-hal lain.

Saya membaca beberapa pendapat tentang Lombok dan sebenarnya saya menggunakannya di beberapa proyek.

Nah, pada kontak pertama dengan Lombok saya mendapat kesan buruk. Setelah beberapa minggu, saya mulai menyukainya. Tetapi setelah beberapa bulan saya menemukan banyak masalah kecil dalam menggunakannya. Jadi, kesan terakhir saya tentang Lombok tidak begitu positif.

Alasan saya berpikir seperti ini:

• Ketergantungan plugin IDE . Dukungan IDE untuk Lombok adalah melalui plugin. Bahkan bekerja dengan baik di sebagian besar waktu, Anda selalu menjadi sandera dari plugin ini untuk dipertahankan di rilis IDE masa depan dan bahkan versi bahasa (Java 10+ akan mempercepat pengembangan bahasa). Misalnya, saya mencoba memperbarui dari Intellij IDEA 2017.3 hingga 2018.1 dan saya tidak bisa melakukan itu karena ada beberapa masalah pada versi plugin lombok yang sebenarnya dan saya perlu menunggu plugin diperbarui ... Ini juga merupakan masalah jika Anda ingin menggunakan lebih banyak IDE alternatif yang tidak memiliki dukungan plugin Lombok.
• Masalah 'Temukan penggunaan'. . Menggunakan Lombok Anda tidak melihat pengambil yang dihasilkan, setter, konstruktor, metode pembangun, dll. Jadi, jika Anda berencana untuk mencari tahu di mana metode ini digunakan dalam proyek Anda oleh IDE Anda, Anda tidak dapat melakukan ini hanya dengan melihat untuk kelas yang memiliki metode tersembunyi ini.
• Sangat mudah sehingga pengembang tidak peduli untuk memecahkan enkapsulasi . Saya tahu itu bukan masalah dari Lombok. Tapi saya melihat kecenderungan yang lebih besar dari pengembang untuk tidak lagi mengontrol metode apa yang perlu terlihat atau tidak. Jadi, sering kali mereka hanya menyalin dan menempel @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructorblok penjelasan tanpa memikirkan metode apa yang benar-benar perlu diekspos oleh kelas.
• Obsesi Pembangun ©. Saya menemukan nama ini (turun, Martin Fowler). Bercanda terpisah, Builder sangat mudah dibuat bahkan ketika kelas hanya memiliki dua parameter, pengembang lebih suka menggunakan @Builderdaripada konstruktor atau metode konstruktor statis. Kadang-kadang mereka bahkan mencoba membuat Builder di dalam lombok Builder, menciptakan situasi yang aneh seperti MyClass.builder().name("Name").build().create().
• Hambatan saat refactoring . Jika Anda menggunakan, misalnya, @AllArgsConstructordan perlu menambahkan satu parameter lagi pada konstruktor, IDE tidak dapat membantu Anda menambahkan parameter tambahan ini di semua tempat (kebanyakan, tes) yang membuat instance kelas.
• Mencampur Lombok dengan metode konkret . Anda tidak dapat menggunakan Lombok di semua skenario untuk membuat pengambil / penyetel / etc. Jadi, Anda akan melihat dua pendekatan ini dicampur dalam kode Anda. Anda terbiasa dengan ini setelah beberapa waktu, tetapi terasa seperti retasan pada bahasa.

Seperti jawaban lain yang dikatakan, jika Anda marah tentang kata kerja Jawa dan menggunakan Lombok untuk menghadapinya, coba Kotlin.

Ada risiko pemeliharaan jangka panjang juga. Pertama, saya akan merekomendasikan membaca tentang bagaimana Lombok sebenarnya bekerja, misalnya beberapa jawaban dari pengembangnya di sini .

Situs resmi juga berisi daftar kerugian , termasuk kutipan dari Reinier Zwitserloot ini:

Ini total hack. Menggunakan API non-publik. Pengecoran sombong (mengetahui bahwa prosesor anotasi yang berjalan di javac akan mendapatkan instance JavacAnnotationProcessor, yang merupakan implementasi internal AnnotationProcessor (antarmuka), yang kebetulan memiliki beberapa metode tambahan yang digunakan untuk mendapatkan AST langsung) .

Pada eclipse, ini bisa dibilang lebih buruk (dan masih lebih kuat) - agen java digunakan untuk menyuntikkan kode ke kelas tata bahasa dan parser gerhana, yang tentu saja sepenuhnya non-publik API dan benar-benar terlarang.

Jika Anda bisa melakukan apa yang lombok lakukan dengan API standar, saya akan melakukannya dengan cara itu, tetapi Anda tidak bisa. Namun, untuk apa nilainya, saya mengembangkan plugin eclipse untuk eclipse v3.5 berjalan di java 1.6, dan tanpa membuat perubahan itu berfungsi pada eclipse v3.4 berjalan di java 1.5 juga, jadi itu tidak sepenuhnya rapuh.

Sebagai rangkuman, sementara Lombok dapat menghemat waktu pengembangan Anda, jika ada pembaruan javac yang tidak kompatibel (misalnya mitigasi kerentanan) Lombok mungkin membuat Anda terjebak dengan versi Jawa yang lama sementara pengembang berebut untuk memperbarui penggunaan mereka atas javac tersebut. API internal. Apakah ini risiko serius jelas tergantung pada proyek.

Saya tahu saya terlambat, tetapi saya tidak bisa menahan godaan: siapa pun yang menyukai Lombok juga harus melihat Scala. Banyak ide bagus yang Anda temukan di Lombok adalah bagian dari bahasa Scala.

Pada pertanyaan Anda: pasti lebih mudah untuk membuat pengembang Anda mencoba Lombok daripada Scala. Cobalah dan jika mereka suka, coba Scala.

Sama seperti penafian: Saya juga suka Jawa!

Saya telah menggunakan Lombok di hampir semua proyek saya selama satu tahun tetapi sayangnya menghapusnya. Pada awalnya itu adalah cara pengembangan yang sangat bersih tetapi menyiapkan lingkungan pengembangan bagi anggota tim baru tidaklah mudah dan langsung. Ketika itu menjadi sakit kepala saya baru saja menghapusnya. Tetapi ini adalah pekerjaan yang bagus dan membutuhkan sedikit kesederhanaan untuk pengaturan.

Ketika saya menunjukkan proyek kepada tim saya, antusiasme tinggi, jadi saya pikir Anda tidak perlu takut dengan respons tim.

• Sejauh ROI, itu adalah snap untuk mengintegrasikan, dan tidak memerlukan perubahan kode dalam bentuk dasarnya. (hanya menambahkan satu anotasi ke kelas Anda)

• Dan terakhir, jika Anda berubah pikiran, Anda dapat menjalankan unlombok, atau membiarkan IDE Anda membuat setter, getter, dan ctors ini, (yang saya pikir tidak ada yang akan meminta begitu mereka melihat seberapa jelas pojo Anda menjadi)

Pandangan saya tentang Lombok adalah bahwa ia hanya menyediakan cara pintas untuk menulis kode Java bolilerplate.
Ketika datang untuk menggunakan cara pintas untuk menulis kode Java bolilerplate, saya akan mengandalkan fitur seperti yang disediakan oleh IDE - seperti di Eclipse, kita dapat pergi ke menu Source> Generate Getters and Setters untuk menghasilkan getter dan setter.
Saya tidak akan bergantung pada perpustakaan seperti Lombok untuk ini:

1. Ini mencemari kode Anda dengan lapisan tipuan dari sintaks alternatif (baca @Getter, @Setter, dll penjelasan). Daripada mempelajari sintaks alternatif untuk Java, saya akan beralih ke bahasa lain yang secara native menyediakan sintaksis seperti Lombok.
2. Lombok membutuhkan penggunaan IDE yang didukung Lombok untuk bekerja dengan kode Anda. Ketergantungan ini menimbulkan risiko yang cukup besar untuk proyek non-sepele. Apakah proyek open source Lombok memiliki sumber daya yang cukup untuk tetap memberikan dukungan untuk berbagai versi berbagai Java IDE yang tersedia?
3. Apakah proyek open source Lombok memiliki sumber daya yang cukup untuk terus memberikan dukungan untuk versi Jawa yang lebih baru yang akan datang di masa depan?
4. Saya juga merasa gugup bahwa Lombok dapat memperkenalkan masalah kompatibilitas dengan kerangka / pustaka yang banyak digunakan (seperti Spring, Hibernate, Jackson, JUnit, Mockito) yang berfungsi dengan kode byte Anda saat runtime.

Secara keseluruhan saya tidak akan memilih untuk "membumbui" Jawa saya dengan Lombok.

Ingin menggunakan lombok @ToStringtetapi segera menghadapi kesalahan kompilasi acak pada proyek yang dibangun kembali di Intellij IDEA. Harus mencapai kompilasi beberapa kali sebelum kompilasi tambahan dapat menyelesaikan dengan sukses.

Mencoba kedua lombok 1.12.2 dan 0.9.3 dengan Intellij IDEA 12.1.6 dan 13.0 tanpa plugin lombok di bawah jdk 1.6.0_39 dan 1.6.0_45.

Harus menyalin metode yang dihasilkan secara manual dari sumber delomboked dan menahan lombok hingga waktu yang lebih baik.

Memperbarui

Masalahnya hanya terjadi dengan kompilasi paralel diaktifkan.

Mengajukan masalah: https://github.com/rzwitserloot/lombok/issues/648

Memperbarui

mplushnikov mengomentari pada 30 Jan 2016:

Versi Intellij yang lebih baru tidak memiliki masalah seperti itu lagi. Saya pikir itu bisa ditutup di sini.

Memperbarui

Saya akan sangat menyarankan untuk beralih dari Jawa + Lombok ke Kotlin jika memungkinkan. Karena telah diselesaikan dari bawah ke atas semua masalah Jawa yang dicoba diatasi oleh Lombok.

Saya telah mengalami masalah dengan Lombok dan Jackson CSV , ketika saya mengarsir objek saya (java bean) ke file CSV, kolom tempat digandakan, kemudian saya menghapus anotasi data @Data dan marshalize bekerja dengan baik.

Saya tidak merekomendasikannya. Saya dulu menggunakannya, tetapi kemudian ketika saya bekerja dengan NetBeans 7.4 itu mengacaukan kode saya. Saya sudah menghapus lombok di semua file di proyek saya. Ada delombok, tapi bagaimana saya bisa yakin itu tidak akan mengacaukan kode saya. Saya harus menghabiskan hari hanya untuk menghapus lombok dan kembali ke gaya Jawa biasa. Aku terlalu pedas ...

Saya belum mencoba menggunakan Lombok - ini adalah yang berikutnya dalam daftar saya, tetapi sepertinya Java 8 telah menyebabkan masalah yang signifikan untuknya, dan pekerjaan perbaikan masih berlangsung sampai seminggu yang lalu. Sumber saya untuk itu adalah https://code.google.com/p/projectlombok/issues/detail?id=451 .