Lombok: [FITUR] Jadikan Lombok kompatibel dengan JDK 16

Saya pikir alasan mengapa itu tidak berfungsi lagi adalah karena mereka menambahkan JEP 396 . Menambahkan --illegal-access=permit akan memperbaiki masalah.

Kami akan membutuhkan perbaikan yang lebih baik untuk jangka panjang. Mereka
menghapus opsi untuk mengakses kelas-kelas ini karena suatu alasan, dan pada titik tertentu
mungkin berhenti bekerja sama sekali.

Pada Selasa, 15 Desember 2020, 16:36 Rawi01 [email protected] menulis:

Saya pikir alasan mengapa itu tidak berfungsi lagi adalah karena mereka menambahkan JEP 396
https://openjdk.java.net/jeps/396 . Menambahkan --illegal-access=izin
harus memperbaiki masalah.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rzwitserloot/lombok/issues/2681#issuecomment-745371095 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AABIERMCDDFPWDOHLDIEGL3SU567BANCNFSM4U4HKVVQ
.

Kita mungkin perlu mendokumentasikan semua add-opens yang perlu ditambahkan oleh pengguna.

https://github.com/rzwitserloot/lombok/blob/f17dd036384242971546bc443749ad527b8cd21c/docker/ant/files/jdk-13/classpath/build.xml#L13 -L23

Bagi siapa pun yang menggunakan Maven, saya dapat membuatnya bekerja dengan konfigurasi plugin kompiler berikut:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.8.1</version>
    <configuration>
        <source>16</source>
        <target>16</target>
        <fork>true</fork>
        <compilerArgs>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED</arg>
        </compilerArgs>
        <annotationProcessorPaths>
            <path>
                <groupId>org.projectlombok</groupId>
                <artifactId>lombok</artifactId>
                <version>1.18.16</version>
            </path>
        </annotationProcessorPaths>
    </configuration>
</plugin>

Perhatikan bahwa <fork>true</fork> diperlukan, jika tidak, Maven tampaknya (diam-diam) mengabaikan opsi -J saat menjalankan kompiler. Sepertinya jdk.compiler/com.sun.tools.javac.jvm juga perlu diekspor di atas apa yang ditautkan @rspilker .

Direproduksi dengan jdk16ea di x64 mac.

Kami telah menemukan solusi yang tidak mengharuskan semua juta pengguna untuk menambahkan semua add-opens ini ke skrip build mereka. Kami akan merilisnya tepat waktu untuk rilis OpenJDK 16 (Pada Maret 2021).

@rzwitserloot itu kabar baik. hanya ingin tahu, apakah ada permintaan tarik terbuka untuk perubahan ini?

@namannigam Tidak, tidak ada. Kami akan menjelaskan alasannya dalam masalah ini setelah jdk16 dirilis secara resmi. Tolong jangan berspekulasi.

Apakah ada solusi untuk masalah ini?

Saya memiliki proyek pakar di IntelliJ IDEA yang perlu dijalankan melalui Tomcat. Tetapi ketika saya menjalankannya, kesalahan serupa diminta:

java: java.lang.IllegalAccessError: class lombok.javac.apt.LombokProcessor (dalam modul tanpa nama @0xddf172a) tidak dapat mengakses kelas com.sun.tools.javac.processing.JavacProcessingEnvironment (dalam modul jdk.compiler) karena modul jdk.compiler melakukannya tidak mengekspor com.sun.tools.javac.processing ke modul tanpa nama @0xddf172a

Lingkungan yang saya gunakan:

1. Java JDK 16
2. IntelliJ IDEA 2020.3.2
3. Apache Maven 3.6.3
4. Lombok 1.18.19

Terima kasih.

@pruidong solusi sementara disebutkan di bawah https://github.com/rzwitserloot/lombok/issues/2681#issuecomment -748616687

@namannigam terima kasih.

Saya menemukan cara yang lebih baik untuk menambahkan variabel lingkungan sistem Windows:

Nama:

_JAVA_OPTIONS

nilai:

--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED --add- opens=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED --add-opens=jdk. compiler/com.sun.tools.javac.model=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED --add-opens=jdk.compiler/com. sun.tools.javac.processing=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools. javac.util=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED

Kami telah menemukan solusi yang tidak mengharuskan semua juta pengguna untuk menambahkan semua add-opens ini ke skrip build mereka. Kami akan merilisnya tepat waktu untuk rilis OpenJDK 16 (Pada Maret 2021).

Saya sangat senang melihat seperti apa solusi ini. Saya bertanya-tanya mengapa ini adalah mengapa rahasia seperti itu dibuat.

@pruidong Perbaikan kami untuk jdk16 juga harus mengatasinya.

Kami menahannya untuk berjaga-jaga jika kami menerbitkan ini menyebabkan rantai peristiwa yang akhirnya menghapus solusi praktis ini dari GA JDK16. Mengingat GA dalam waktu sekitar 10 hari, saya pikir kami siap melakukannya dan akan segera melakukan patch kami untuk dikuasai secara publik.

Sebagai pengembang OpenJDK, izinkan saya menjelaskan bahwa kami sengaja memutuskan (setelah banyak perdebatan) untuk meninggalkan beberapa celah terkenal untuk memberi perpustakaan lebih banyak waktu untuk secara bertahap mempersiapkan realitas baru, dan menjelaskannya, dan mengapa itu terjadi. sangat penting, bagi penggunanya. Celah tersebut dijadwalkan untuk dihapus secara bertahap, satu per satu, dimulai dengan JDK 17, karena 16 sudah memiliki langkah enkapsulasi pertama. Eksploitasi penerbitan tidak akan membuatnya tetap ada atau dihapus cepat atau lambat; penghapusan mereka tidak akan dipercepat atau ditunda. Mereka dihapus sesuai jadwal, dan akan ada pemberitahuan beberapa bulan sebelumnya. Saya akan merekomendasikan penulis perpustakaan menggunakan waktu itu untuk mempersiapkan diri dan penggunanya untuk lingkungan yang lebih baik tetapi berbeda ini .

Singkatnya, strateginya adalah ini: penggunaan internal JDK oleh perpustakaan ditoleransi selama mereka memberi tahu pengguna bahwa mereka melakukannya dengan add-opens . Ini karena perpustakaan tersebut menjadi terikat dengan versi JDK, dan karenanya harus waspada saat memperbarui, dan penggunanya perlu menyadari masalah pemeliharaan yang mungkin ditimbulkan oleh perpustakaan (ada juga masalah keamanan ketika datang ke perpustakaan yang melakukan ini saat runtime ). Jadi, Anda dapat melakukan apa yang Anda suka, tetapi jika Anda memaksakan beban pemeliharaan potensial pada pengguna Anda, Anda harus memberi tahu mereka tentang hal itu. Ketika semua celah ditutup, perpustakaan perlu memutuskan apakah akan tidak menggunakan internal atau menyesuaikan pengguna mereka dengan add-opens. Dalam beberapa bulan tidak akan ada cara — menggunakan Tidak Aman, lampirkan, kode asli, dll. — untuk meretas internal JDK tanpa persetujuan tertulis dari aplikasi.

Tentu saja, ini bukan masalah untuk aplikasi , yang harus menyematkan runtime dan peluncur mereka sendiri dengan bendera apa pun yang mereka suka (atau, ketika datang untuk membangun alat waktu, Anda dapat membuat plugin Maven yang melakukan itu). Intinya adalah bahwa memperkenalkan beban pemeliharaan (dan/atau keamanan) tidak akan mungkin dilakukan tanpa pengguna mengetahuinya dan mengambil beberapa tindakan untuk mengizinkannya secara eksplisit — dengan menggunakan executable tertentu, plugin tertentu, atau menambahkan flag. Ketika pengguna memahami bahwa ini perlu, mereka cenderung sangat akomodatif.

ada juga masalah keamanan ketika datang ke perpustakaan yang melakukan ini saat runtime

@Pron Ini terus dikatakan. Ini tidak masuk akal. Saya sudah meminta klarifikasi sebelumnya, tetapi tidak pernah mendapat jawaban, jadi izinkan saya mengambil kesempatan ini untuk bertanya lagi: _Kamu sedang apa? Bagaimana --add-opens wajib mengatasi masalah keamanan?

Masuk akal untuk menolak plugin (alias kode yang mungkin tidak sepenuhnya Anda percayai) kemampuan untuk hanya menelepon dan berinteraksi dengan API pribadi. Namun, __pembatasan add-opens ini tidak mencapai tujuan itu__: Jika tidak ada manajer keamanan, maka kode yang tidak Anda percaya dapat memanggil API pribadi (selama mereka melakukannya dalam paket yang dibuka). Mereka juga dapat memanggil C:\windows\format.exe dan menghapus direktori home pengguna saat mereka melakukannya. Tidak masuk akal bagi saya untuk membuat klaim tentang 'ini lebih aman di lingkungan di mana tidak ada manajer keamanan yang disetel'. Itu seperti memasang brankas di tengah area yang dipagari oleh tali beludru dan berkata: Di sana! Sekarang tidak ada yang bisa masuk! Sementara semua orang hanya melompati tali.

Jelas Anda harus berbicara tentang perasaan lain 'lebih aman', tapi saya tidak yakin apa, tepatnya, yang Anda maksud.

selama mereka memberi tahu pengguna bahwa mereka melakukannya dengan add-opens.

Ini bukan saran yang bisa diterapkan.

• Sampai _sangat_ baru-baru ini, ini _impossible_ pada maven, karena argumen baris perintah ke VM disimpan oleh maven dalam hashmap, sehingga mencegah kemampuan menggunakan argumen yang sama lebih dari sekali, dan --add-opens perlu diterapkan lebih banyak dari sekali.
• Jumlah --add-opens yang diperlukan di sini sangat besar, sintaksnya berat dan hanya dengan melihat daftar lengkap argumen baris perintah yang diperlukan sepertinya tidak akan membuat sesuatu yang sangat jelas bagi pengguna Java biasa Anda. Mereka tidak tahu apa yang mereka lihat - hanya 'uh, situs ini menyuruh saya untuk menyalin/menempelkan kumpulan barang raksasa ini ke dalam skrip saya. Tidak tahu mengapa atau apa fungsinya, tetapi, CMD+C CMD+VI tebak'.

Saat menyarankan fitur bahasa baru, umumnya proses JEP cenderung melakukan penelitian: Apa dampak dari perubahan ini? Analisis dampak ini mungkin harus memperhitungkan seberapa umum berbagai perpustakaan (dengan kata lain, bencana 'menegaskan' di mana 1.4 menambahkan pernyataan sebagai kata kunci seharusnya tidak pernah terjadi, mengingat junit, pada saat itu, satu-satunya perpustakaan yang paling umum digunakan di seluruh ekosistem, dan 1.4 memecahkannya dengan memperkenalkan perubahan yang tidak kompatibel ke belakang: Itu adalah kesalahan, dan pelajaran telah dipetik).

Tapi ternyata tolok ukur itu tidak diterapkan di sini. Saya ingin melihat tim OpenJDK melihat lebih dekat jalur pemutakhiran yang disarankan ini, menggunakan ide serupa seperti yang sering diminta untuk perubahan bahasa: Alih-alih merusak spesifikasi, pertimbangkan dampak aktual.

Perhatikan bahwa, bahkan hari ini, java8 jauh lebih populer daripada java11. Saya cukup yakin sikap tim OpenJDK sehubungan dengan dampak merugikan yang dimiliki proyek jigsaw pada kompatibilitas antara Java8 dan Java11 adalah penyebab utama hal ini.

Mengingat semua hal ini, saya mohon Anda, bawa ini ke tim OpenJDK dan pertimbangkan kembali rencana untuk --add-opens dan jalur peningkatan yang disarankan. Tujuan Anda yang dinyatakan tidak akan tercapai dengan rencana Anda, dan belum untuk sementara waktu sekarang. Yang Anda lakukan hanyalah memperburuknya:

• Adopsi Java11 telah mundur satu dekade karena rencana Anda.
• Kami terus mengatasinya, dan saya agak ragu itu akan berubah. Kami selalu dapat membuat plugin maven dan gradle, yang mungkin sesuai dengan opsi jalur peningkatan teknis yang Anda nyatakan (pada dasarnya, kami sekarang adalah 'aplikasi'), tetapi tidak mencapai tujuan untuk memperjelas bahwa API internal sedang digunakan sama sekali; jika ada, itu membuat lebih sulit untuk mengetahuinya, tidak lebih mudah, dan itu membuat programmer java lebih mungkin mengalami sakit kepala karena ketidakcocokan.

__Dalam misi Anda untuk memastikan ekosistem java memiliki lebih sedikit masalah dengan inkompatibilitas mundur, Anda malah memperkenalkannya secara agresif. Anda menambah masalah alih-alih menyelesaikannya!__

Untuk pengguna lombok yang mengikuti utas ini: Kami memiliki beberapa celah yang kurang terkenal yang dapat kami gunakan untuk menjembatani beberapa celah. Kami akan mulai mengerjakan plugin gradle dan maven untuk sementara waktu, yang akan menjadi perbaikan jangka panjang.

Enkapsulasi detail implementasi internal adalah mekanisme di mana OpenJDK akan memastikan kesesuaian dengan spesifikasi, yang telah menjadi strategi Java untuk kompatibilitas mundur sejak awal; penggunaan detail implementasi tidak portabel menurut definisi, dan telah ditemukan sebagai rintangan utama untuk kompatibilitas ke belakang dan penyebab luar biasa dari kesulitan untuk meningkatkan dari 8. Selain itu, keamanan platform akan menjadi semakin bergantung pada integritas enkapsulasi . Perpustakaan akan memiliki opsi untuk menargetkan spesifikasi atau meminta izin aplikasi untuk mengandalkan internal melalui add-opens. Karena ini bukan milis OpenJDK, saya hanya memberi tahu Anda tentang keputusan strategis yang telah dibuat. Jika Anda ingin mengajukan banding, jangan ragu untuk menghubungi milis.

@pron menulis:

penyebab luar biasa dari kesulitan untuk meningkatkan dari 8

Itu pernyataan yang menyesatkan.

JDK11 memecahkan banyak __public__ API, seperti memindahkan javax.annotation.Generated , untuk memperbaiki paket yang terpisah. Saya pikir itu panggilan yang tepat, tetapi tidak jujur ​​​​untuk menyarankan bahwa 'perpustakaan yang tidak secara otomatis hanya berfungsi di JDK11, yah, mereka kacau'. Tidak, perbedaan kompatibilitas antara 8 dan 11 adalah, relatif terhadap pembaruan versi Java lainnya, urutan besarnya atau dua lebih besar, dan itu __bukan kesalahan perpustakaan__. Tanggung jawab terletak pada OpenJDK. Sebagian besar 'perpustakaan X bekerja di 8 dan tidak lagi berfungsi di 11, dan itu karena mereka menggunakan API internal' kasus rusak __karena --add-opens ada__, dan bukan karena API internal tersebut benar-benar berubah. Itu juga merupakan situasi di mana kesalahan jatuh setidaknya sebagian pada OpenJDK. Tim OpenJDK membuat keputusan aktif untuk menyebabkan ketidakcocokan ini. Ini tidak kompatibel hanya karena OpenJDK11 rusak .setAccessible . Tujuan untuk kedua jeda ini mungkin dapat dipertahankan, tetapi saya tersinggung dengan sindiran kuat Anda bahwa kesalahan jatuh tepat pada perpustakaan yang menggunakan @Generated atau hal-hal lain yang menghilang dari inti Java di 11, atau pada mereka yang menggunakan API internal. Tidak. Mereka bahu-membahu, mungkin. Tetapi hanya sebagian, sisanya berada di pundak OpenJDK.

Selain itu, keamanan platform akan semakin bergantung pada integritas enkapsulasi.

Dalam analisis keamanan, model ancaman sering kali menjadi titik awal. Kurang lebih naskah film: Putar cerita tentang bagaimana seorang peretas bisa mendapatkan akses ke hal-hal yang seharusnya tidak mereka akses. Berbekal beberapa skrip film ini, Anda sebenarnya dapat 'menguji' langkah-langkah keamanan: Skrip mana yang berhenti, jika ada. Seberapa masuk akal skrip itu berhenti.

Saya sama sekali tidak tahu apa yang Anda bicarakan. Bisakah Anda memberi saya gambaran tentang kompromi keamanan yang akan dikurangi oleh --add-opens ?

Milis mana yang Anda sarankan sebagai sarana terbaik untuk meningkatkan poin ini dengan proyek OpenJDK?

Itu pernyataan yang menyesatkan.

Tidak, bukan. Penyebab luar biasa dari kesulitan migrasi, tidak diragukan lagi, adalah ketergantungan pada detail implementasi internal. Ada juga perubahan pada spesifikasi, tetapi itu menyebabkan persentase masalah yang sangat kecil.

Sebagian besar 'perpustakaan X yang sebenarnya bekerja di 8 dan tidak lagi berfungsi di 11, dan itu karena mereka menggunakan kasus API internal' rusak karena --add-opens ada, dan bukan karena API internal tersebut benar-benar berubah.

Itu salah, belum lagi enkapsulasi modul baru diaktifkan di 16. Bagaimanapun, saya di sini bukan untuk memperdebatkan keputusan, hanya untuk menginformasikannya.

Milis mana yang Anda sarankan sebagai sarana terbaik untuk meningkatkan poin ini dengan proyek OpenJDK?

jigsaw-dev.

@pron

Penyebab luar biasa dari kesulitan migrasi, tidak diragukan lagi , adalah ketergantungan pada detail implementasi internal

Sejujurnya, frasa "tanpa keraguan" terdengar agak aneh di sini. Apakah ada penelitian publik/swasta (baik itu jajak pendapat atau apa pun) yang mendukung hal itu, atau apakah itu hanya semacam tebakan terpelajar?

Terima kasih!

Untuk pengguna lombok yang mengikuti utas ini: Kami memiliki beberapa celah yang kurang terkenal yang dapat kami gunakan untuk menjembatani beberapa celah. Kami akan mulai mengerjakan plugin gradle dan maven untuk sementara waktu, yang akan menjadi perbaikan jangka panjang.

Sebagai pemelihara prosesor anotasi akan menarik untuk melihat bagaimana pendekatan seperti menggunakan plugin maven/gradle.

Beberapa pertanyaan umum lainnya, apakah ada inisiatif untuk menambahkan hal-hal yang dibutuhkan Lombok ke compiler Java, mungkin API tambahan yang memungkinkan Lombok melakukan apa yang dilakukannya. Ada beberapa diskusi di https://twitter.com/gunnarmorling/status/1370687166553161732.

Saya tidak tahu tentang internal Lombok, tetapi jika Java Compiler memungkinkan memasukkan ke dalam pembuatan AST dan memodifikasinya maka saya kira Lombok tidak perlu lagi bergantung pada internal Java.

@siziyman Ini didasarkan pada analisis internal oleh Oracle tentang rintangan yang dihadapi berbagai perusahaan saat memutakhirkan. Jika dan ketika kita pernah meluangkan waktu untuk menulis post-mortem, kita akan membahas ini secara lebih rinci. Tapi saya seharusnya tidak membahas itu sama sekali, dan untuk itu saya minta maaf, karena ini adalah tempat yang tidak pantas untuk memperdebatkan proyek yang sama sekali berbeda, dan saya tidak boleh mengganggu seseorang yang melampiaskan frustrasi, betapapun salah arahnya, di situs proyek mereka sendiri. .

Untuk berbelok ke arah yang lebih konstruktif, pengguna tidak perlu direpotkan dengan banyak add-opens. Pustaka yang relatif sedikit yang membutuhkan internal sama sekali, membutuhkan sangat sedikit, sementara aplikasi, yang secara keseluruhan mungkin membutuhkan banyak, mengontrol peluncuran dan tidak perlu mengganggu penggunanya dengan baris perintah sama sekali. Lombok dapat, misalnya, mengirimkan sebagai aplikasi, lomboc , yang memecah enkapsulasi sebanyak atau sesedikit yang diinginkan.

@pron masalah yang Anda katakan untuk Lombok untuk dikirim sebagai aplikasi tidak semudah itu. Dari pemahaman saya Lombok tidak memerlukan internal apapun selama runtime aplikasi. Itu perlu mengakses internal tertentu selama fase kompilasi, karena API Pemrosesan Anotasi tidak menyediakan cara bagi mereka untuk melakukan apa yang mereka lakukan.

@filiphr Itulah mengapa _can_ dikirimkan sebagai aplikasi, seperti javac . Tapi itu hanya saran. Plugin alat build adalah hal lain.

Saya setuju bahwa ini mungkin bukan tempat untuk membahas pengembangan javac, ada beberapa hal yang ingin saya sebutkan.

Kami memutuskan untuk tidak membuat executable lain, karena yang saat ini baik-baik saja dan didukung dengan baik dalam membangun alat dan IDE.

Mengenai saran untuk membuat biner seperti javac , saya pikir tidak ada yang akan mendapat manfaat dari itu. Parameter baris perintah javac tidak ditentukan atau stabil.

Lombok kompatibel dengan semua JDK mulai dari 1.6. Jika kami akan merilis lombok versi baru, versi javac akan kami terapkan pada pengguna kami?

Kami memilih menggunakan hook in sebagai prosesor anotasi untuk memudahkan pengguna kami. Kami telah menanggung beban untuk kompatibel dengan 11 versi javac , OpenJ9 dan juga beberapa ecj -s. Kami mendukung berbagai macam alat pembangunan seperti semut, Maven, Gradle dan Bazel, serta IDE seperti Eclipse, NetBeans, IntelliJ dan Visual Studio Code.

Apa yang kami tawarkan adalah bahwa pengguna kami mengunduh toples yang lebih kecil dari 2 MB, meletakkannya di classpath mereka, secara eksplisit menunjuk ke prosesor anotasi, dan itu hanya berfungsi.

Akan sangat bagus jika ada cara agar kami dapat mengekspresikan dalam manifes API apa yang akan dibuka jika kami menjalankannya sebagai pemroses anotasi. Sejauh ini, saya tidak dapat membuat ini berhasil, tetapi mungkin saya melewatkan sesuatu.

Saya pribadi juga akan berpikir bahwa "mengkompilasi aplikasi" dan "menjalankan aplikasi dalam produksi di pelanggan" memiliki masalah keamanan yang berbeda. Dan ada banyak argumen bagus untuk memberi pengembang cara mudah untuk menghilangkan peringatan ini selama kompilasi.

Mengenai penggunaan "API pribadi", seperti yang telah disebutkan, akan sangat menyenangkan jika ada API manipulasi AST publik. Baik Reinier dan saya telah membicarakan hal ini 10 tahun yang lalu dengan orang-orang yang bertanggung jawab atas kompiler dan prosesor anotasi. Tanggapan dari mereka yang bertanggung jawab adalah: "Mengerikan, kami tidak akan pernah melakukan itu. Ini akan mencegah pembuatan fitur bahasa baru, dan pemroses anotasi tidak akan pernah diizinkan untuk mengubah perilaku program."

Mengenai "mencegah pembuatan fitur bahasa baru", idenya adalah menambahkan metode ke antarmuka pengunjung akan menjadi perubahan yang tidak kompatibel. Dan meskipun secara teknis benar, argumen yang sama dapat dibuat mengenai JDBC. Dan juga "pertahanan" yang sama berlaku: Hanya ada sejumlah vendor JDBC yang terbatas. Yah, hanya ada sejumlah integrasi kompiler yang terbatas.

Mengenai anotasi yang mengubah perilaku, ini juga tidak lagi hitam dan putih.

Mungkin, gagasan mengenai API publik dan mengizinkan pemroses anotasi untuk memodifikasi bytecode yang dihasilkan telah berubah dalam dekade terakhir. Sejujurnya, Reinier dan saya telah kehilangan harapan itu, tetapi kami sangat bersedia untuk berkolaborasi dengan mereka yang bertanggung jawab atas kompiler untuk melihat bagaimana kami dapat meningkatkan ekosistem java.

Akan sangat bagus jika ada cara agar kami dapat mengekspresikan dalam manifes API apa yang akan dibuka jika kami menjalankannya sebagai pemroses anotasi.

Aturannya adalah bahwa perpustakaan tidak memutuskan enkapsulasi tetapi aplikasi memiliki keputusan akhir (dan default disediakan oleh kode target). Prinsip itu adalah inti dari enkapsulasi. Detail implementasi internal dapat berubah kapan saja, bahkan dalam tambalan, dan konsumen perpustakaan perlu mengetahui bahwa perpustakaan terkait dengan rilis tertentu.

Mengenai penggunaan "API pribadi", seperti yang telah disebutkan, akan sangat menyenangkan jika ada API manipulasi AST publik.

Itu adalah diskusi lain, dan bagus untuk dilakukan, tetapi saya yakin akan ada beberapa perdebatan. Saya tidak terlibat dengan area platform itu sama sekali, tetapi saya percaya bahwa prosesor anotasi sengaja dibatasi, seperti halnya agen Java (dan ada perpustakaan yang juga tidak menyukainya). Platform Java dan bahasa Java harus bebas menentukan cakupan fiturnya dan melarang atau tidak mendukung penggunaan tertentu. Mereka masih memiliki jalan melalui mekanisme yang saya jelaskan, bahkan jika itu berarti lebih banyak pekerjaan.

Bagaimanapun, rencana untuk enkapsulasi telah diselesaikan tiga tahun lalu tetapi enkapsulasi tidak dihidupkan tetapi hanya mengeluarkan peringatan secara tepat untuk memiliki waktu untuk diskusi semacam itu. Tapi, lebih baik terlambat daripada tidak sama sekali, dan sementara saya ragu API baru akan ditambahkan sebelum celah ditutup, jika Anda memiliki beberapa saran kecil, mungkin itu bisa dilakukan. compiler-dev mungkin adalah tempat yang tepat untuk mengambil ini.

Pertanyaan saya adalah, apa strategi jangka panjang lombok untuk mengurangi ketergantungan pada internal JDK? Apakah itu akan terus menerapkan solusi dan peretasan tambahan untuk membobol javac? Pengiriman sebagai plugin pakar sepertinya cara lain untuk mengatasi penguatan enkapsulasi yang dibawa oleh pembaruan JDK baru-baru ini. Akan tiba saatnya ketika internal JDK ini tidak lagi dapat diakses, dan peretasan akan gagal. Entah itu, atau lombok harus terus menggunakan mekanisme seperti add-opens untuk terus mencongkel internal yang terbuka.

Apakah lombok benar-benar berencana untuk mengandalkan internal JDK tanpa batas?

@pron perbedaan filosofis tentang di mana dan apa alat semacam itu harus diizinkan untuk dikesampingkan, pada akhirnya pengguna menggunakan Lombok untuk memecahkan masalah yang sangat terkenal dengan verbositas Java. Ini bukan hanya tentang menghasilkan beberapa kelas data yang tidak dapat diubah. Dapat dimengerti bahwa orang-orang Open JDK tidak ingin mendanai proyek "pengurangan boilerplate" dan sebaliknya akan fokus pada hal-hal seperti Catatan, Valhalla, dan pencocokan pola yang hanya sebagian mengatasi masalah boilerplate. Fitur-fitur ini jauh lebih ambisius dan menarik, jadi tidak heran jika inilah yang diambil tetapi mudah untuk melihat bagaimana proyek "pengurangan boilerplate" akan 10x lebih produktif untuk pengembang selama 10 tahun ke depan daripada hampir semua hal lainnya. Inilah yang coba dialamatkan Lombok kepada orang lain yang pindah ke Kotlin. Semoga orang-orang OpenJDK menyadari ini adalah masalah nyata dan menawarkan cara yang didukung untuk alat seperti Lombok untuk melakukan pekerjaannya ketika bahasa dan alat standar gagal. Saya suka Java dan tidak ingin pindah ke Kotlin tetapi jika saya dipaksa untuk menulis dan mempertahankan boilerplate ini lagi setelah berhasil menghindari begitu lama maka Kotlin jauh lebih menarik bagi saya.

@rspilker @rzwitserloot di beberapa titik Lombok perlu memutuskan apakah ingin terus berada dalam bisnis pengurangan boilerplate Java dan jika demikian mungkin sekarang saatnya untuk memikirkan pendekatan alternatif yang muncul sebelum javac dijalankan alih-alih plugin dalam fase kompilasi yang tampaknya tidak dapat diakomodasi oleh orang-orang OpenJDK.

@namannigam terima kasih.

Saya menemukan cara yang lebih baik untuk menambahkan variabel lingkungan sistem Windows:

Nama:

_JAVA_OPTIONS

nilai:

--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED --add- opens=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED --add-opens=jdk. compiler/com.sun.tools.javac.model=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED --add-opens=jdk.compiler/com. sun.tools.javac.processing=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools. javac.util=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED

Anda cukup mengatur JAVA_TOOL_OPTIONS=--illegal-access=permit

--illegal-access opsi akan segera hilang (tidak digunakan lagi), --add-opens tidak akan (mungkin suatu hari nanti, tetapi tidak segera).
Sudah ada https://openjdk.java.net/jeps/403 yang akan membuat illegal-access no-op (belum ditargetkan).

Tentu, tapi JAVA_TOOL_OPTIONS adalah peretasan sementara

@A248 Lombok akan selalu mengandalkan jdk internal, karena kita harus berpartisipasi dalam proses kompilasi. Kami tidak dapat mengubah kode sebelum kompilasi atau setelah kompilasi.

@pron Alasan saya menyarankan untuk mengizinkan perpustakaan mendeklarasikan add-opens mereka di manifes adalah karena pengelola alat/pustaka tahu apa yang mereka butuhkan. Saya mengerti bahwa mereka ingin terbuka tentang penggunaan API non-publik. Tetapi mereka dapat melakukannya dengan mendeklarasikannya dalam manifes.

Bagaimana dengan parameter baris perintah Java/javac yang memungkinkan pengguna memberi tahu jvm bahwa mereka mempercayai perpustakaan tertentu?

Seperti: java --module-path x.jar --trust x.jar ...

_Teks di bawah ini tidak dimaksudkan sebagai serangan, keluhan, atau apa pun yang menyinggung, tetapi hanya sebagai penjelasan mengapa kami agak sensitif dalam memberikan pengalaman terbaik kepada pengguna kami._

Sebagai catatan, baik Reinier dan saya semuanya mengizinkan pemecahan beberapa API untuk meningkatkan platform. Kami kadang-kadang tidak setuju dengan pilihan kekuatan yang ada, dan sangat sensitif terhadap alasan yang tidak konsisten yang mendukung pendapat dari kekuatan yang ada. Seperti: Kami harus mengubah API ini karena KAMI pikir ini adalah ide yang bagus dan hanya merusak <1% dari program yang ada, tetapi kami tidak akan mendukung permintaan tarik pada topik favorit Anda karena itu dapat merusak kompatibilitas mundur, meskipun < 0,1%.

Atau: Kami tidak akan lagi mengizinkan X, karena itu membuatnya lebih aman untuk skenario Y yang tidak mungkin, tetapi memperbaiki kerentanan Z, itu adalah skenario yang sangat mungkin, kami tidak akan melakukannya, karena beberapa pelanggan kami bergantung pada perilaku itu. Ya, keamanan adalah trade-off. Kami menerima itu, kami menghargai itu. Kami ingin pengguna mengendalikan pertukaran itu. Beri tahu mereka, dan beri mereka alat untuk mengeksekusi keputusan mereka.

Tetapi mereka dapat melakukannya dengan mendeklarasikannya dalam manifes.

Anda memerlukan alat untuk mengumpulkan izin yang diberikan oleh berbagai dependensi transitif. Tapi saya akan mengatakan sekali lagi bahwa ini bukan tempat untuk berdiskusi, dan bagaimanapun juga, saya bukan orang yang tepat untuk diajak berdiskusi.

Bagaimana dengan parameter baris perintah Java/javac yang memungkinkan pengguna memberi tahu jvm bahwa mereka mempercayai perpustakaan tertentu?

Ya. Ini disebut add-opens .

Untuk catatan...

Saya minta maaf karena Anda menganggap tata kelola OpenJDK mengganggu, tetapi pelayan tidak dapat dan tidak perlu selalu menjelaskan keputusan mereka sepenuhnya kepada semua orang, apalagi melakukannya sampai setiap orang yakin. Mungkin juga, seperti semua orang, mereka bisa tidak konsisten, tetapi pemerintahan menempatkan keputusan pada mereka.

Bagaimanapun, tidak masalah mengapa Anda mengandalkan detail implementasi internal; Faktanya adalah bahwa detail tersebut dapat berubah kapan saja (termasuk rilis patch), yang berarti bahwa Anda berkomitmen untuk mengubah perpustakaan Anda sesering yang diperlukan, dan bahwa pengguna Anda perlu secara tegas mengakui bahwa mereka memahami potensi beban pemeliharaan dan menerima dia.

Kami ingin pengguna mengendalikan pertukaran itu. Beri tahu mereka, dan beri mereka alat untuk mengeksekusi keputusan mereka.

Ya, itulah gunanya add-opens.

apakah ada seseorang yang berhasil bekerja dengan IntelliJ ?

@sblantipodi belum, saya melaporkan bug untuk IntelliJ, tetapi mereka bersikeras menunggu rilis lombok. Rupanya --add-opens entah bagaimana tidak berfungsi dengan benar di IntelliJ.

Jadi JDK16 keluar, tetapi 1.18.18 terbaru dan edge-SNAPSHOT masih memiliki masalah dengan pakar:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (java-compile) on project xyz-xyz-abc: Fatal error compiling: java.lang.IllegalAccessError: class lombok.javac.apt.LombokProcessor (in unnamed module @0x527dd738) cannot access class com.sun.tools.javac.processing.JavacProcessingEnvironment (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.processing to unnamed module <strong i="6">@0x527dd738</strong> -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.

Dapatkah seseorang memberikan info sejauh apa yang harus dilakukan? Saya tidak berpikir bahwa solusi dengan 25 argumen kompiler berbeda dapat dipertimbangkan.

Kami berharap untuk merilis versi baru lombok dalam waktu 24 jam.

Kami melakukan banyak pekerjaan, dan sangat dekat dengan rilis. Akan ada rilis tepi terbaru yang tersedia dengan perubahan terbaru kami, kemungkinan dalam beberapa jam.

Jika tidak jelas, beberapa menit setelah @rspilker memposting itu, edge diperbarui dengan dukungan JDK16 penuh (dengan peringatan kami memiliki beberapa pekerjaan yang harus dilakukan pada catatan). Ada beberapa Permintaan Tarik yang ingin kami integrasikan, dan kemudian 1.18.20 akan dirilis; kami menargetkan akhir pekan ini.

@rspilker dan @rzwitserloot tidak yakin pekerjaan apa yang Anda miliki untuk Catatan, tetapi bagaimanapun saya ingin memberi tahu Anda tentang JDK-8258535 , sepertinya ada bug di kompiler javac dan API tidak mengembalikan semuanya dengan benar ketika catatan berada di stoples yang berbeda. Saya tidak tahu apakah Anda terpengaruh oleh ini atau tidak, tetapi saya ingin memberi tahu Anda jika Anda mengalami masalah seperti itu.

apa status 1.18.20 ?

1) Kami sedang menunggu umpan balik dari rilis tepi. Bisakah orang mengonfirmasi bahwa itu berfungsi di java16?
2) Kami masih mengerjakan catatan pendukung sepenuhnya. Dukungan dasar ada di sana, tetapi kami juga menyertakan @NonNull pada bidang rekaman. Kode javac sudah selesai, ecj / Eclipse masih belum selesai.

1. Kami sedang menunggu umpan balik dari rilis tepi. Bisakah orang mengonfirmasi bahwa itu berfungsi di java16?

Bagi saya, ini berfungsi dengan baik menggunakan edge-SNAPSHOT (tidak menggunakan catatan).

Punya 4 layanan mikro yang berfungsi dengan baik dengannya.
Dengan berbagai integrasi dengan Spring JPA dan lainnya, semuanya dengan JDK 16.

Saat ini menambahkannya ke versi SDK beta kami di tempat kerja yang melayani layanan mikro 50ish, karena kami menempatkan cabang beta untuk mendukung JDK 16, dan setidaknya melewati semua pengujian kami.

edge berfungsi pada j16 untuk saya

Juga untuk menyebutkan bahwa dengan Edge, Project build IDEA berfungsi kembali. Bukan dengan --add-opens ditambahkan ke dalam plugin kompiler Maven

@Heatmanofurioso Untuk IntelliJ Anda perlu/perlu mengubah sesuatu yang lain, lihat komentar di https://youtrack.jetbrains.com/issue/IDEA-263241

Ini pada akhirnya akan dibutuhkan ketika JDK memblokir semua lubang.

_[Sunting]: sebenarnya bukan masalah lombok (lebih jelasnya ada di komentar saya yang lain di bawah)._

Untuk bagian saya, saya masih memiliki satu opsi --add-opens untuk disimpan agar kompilasi berhasil dengan versi edge-SNAPSHOT (gradle 6.8.3, openjdk build 16+36 dari AdoptOpenJDK):

  tasks.withType<JavaCompile> {
      options.isFork = true
      options.forkOptions.jvmArgs!!.add("--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED")

Tanpa ini, gagal dengan
> java.lang.IllegalAccessError: class org.gradle.internal.compiler.java.ClassNameCollector (in unnamed module @0x14d45694) cannot access class com.sun.tools.javac.code.Symbol$TypeSymbol (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.code to unnamed module <strong i="11">@0x14d45694</strong>

@krzyk Dengan Edge saya tidak. Setidaknya untuk saat ini dengan JDK 16

Saya mengonfirmasi bahwa saya tidak memiliki dan semuanya berfungsi dengan JDK16, keduanya membangun dengan Maven 3.6.3, dan membangun menggunakan perintah IDEA Build pada IDEA 2021.1 Beta 3, dan pada rilis stabil terbaru

Menggunakan edge, maven, intellij dan JDK 16.

ini adalah kesalahan yang saya miliki:
java: java.lang.IllegalAccessError: class lombok.javac.apt.LombokProcessor (in unnamed module @0x4894d8bd) cannot access class com.sun.tools.javac.processing.JavacProcessingEnvironment (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.processing to unnamed module <strong i="7">@0x4894d8bd</strong>

Saya mendapatkan kesalahan ini dengan OpenJDk1.8? Sepertinya itu harus putus dengan JDK 16. Apakah ada yang perlu saya lakukan di sisi saya untuk memperbaikinya ...

JDK8 tidak memiliki modul, jadi kesalahannya kemungkinan besar akan berbeda. Bisakah Anda memberikan pesan kesalahan lengkap?

@iksnalybok (Menjawab sendiri). Versi lombok edge berfungsi dengan baik.

Kesalahan lebih terlihat seperti masalah gradle: IllegalAccessError melibatkan kelas org.gradle.internal.compiler.java.ClassNameCollector yang merupakan kelas gradle. Sebenarnya, LombokProcessor#init() belum dipanggil saat error terjadi. Jadi jelas bukan masalah lombok.

Solusi di sisi gradle adalah menambahkan yang berikut ini di gradle.properties :

org.gradle.jvmargs=--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED

Mendapatkan kesalahan ini sekarang menggunakan JDK 14 dan 1.18.18 ketergantungan lombok...

[ERROR] Gagal menjalankan tujuan org.apache.maven. plugins:maven-compiler-plugin :3.8.1:compile (default-compile) pada proyek Azure-b2c-service: Kompilasi kesalahan fatal: java.lang.IllegalAccessError: class lombok.javac.apt.LombokProcessor (dalam modul tanpa nama @0x363d3958 ) tidak dapat mengakses kelas com.sun.tools.javac.processing.JavacProcessingEnvironment (dalam modul jdk.compiler) karena modul jdk.compiler tidak mengekspor com.sun.tools.javac.processing ke modul tanpa nama @0x363d395

Mendapatkan kesalahan ini saat membangun proyek dengan tindakan GitHub.
Saya menggunakan OpenJDK 11 dan Lombok 1.18.12.
Semuanya berfungsi di mesin lokal saya.
Kesalahan: Gagal menjalankan tujuan org.Apache.maven.plugins:maven-compiler-plugin:3.5.1:compile (default-compile) pada sumber proyekai: Kompilasi kesalahan fatal: java.lang.IllegalAccessError: class lombok.javac.apt .LombokProcessor (dalam modul tanpa nama @0x39aec833) tidak dapat mengakses kelas com.sun.tools.javac.processing.JavacProcessingEnvironment (dalam modul jdk.compiler) karena modul jdk.compiler tidak mengekspor com.sun.tools.javac.processing ke modul tanpa nama @0x39aec833 -> [Bantuan 1]

Mendapatkan kesalahan ini saat membangun proyek dengan tindakan GitHub.
Saya menggunakan OpenJDK 11 dan Lombok 1.18.12.
Semuanya berfungsi di mesin lokal saya.
Kesalahan: Gagal menjalankan tujuan org.Apache.maven.plugins:maven-compiler-plugin:3.5.1:compile (default-compile) pada sumber proyekai: Kompilasi kesalahan fatal: java.lang.IllegalAccessError: class lombok.javac.apt .LombokProcessor (dalam modul tanpa nama @0x39aec833) tidak dapat mengakses kelas com.sun.tools.javac.processing.JavacProcessingEnvironment (dalam modul jdk.compiler) karena modul jdk.compiler tidak mengekspor com.sun.tools.javac.processing ke modul tanpa nama @0x39aec833 -> [Bantuan 1]

Saya dapat mengonfirmasi hal yang sama (dibangun dengan baik secara lokal, gagal saat penerapan) dengan pipeline Gitlab. Gunakan gambar Docker
oraclelinux7 dan Lombok 1.18.16.

edge-SNAPSHOT berfungsi dengan baik untuk saya ketika mengkompilasi menggunakan Java 16, menggunakan maven, di Fedora 33. Saya tidak menggunakan catatan dalam kode Java saya.

edge-SNAPSHOT juga berfungsi dengan baik untuk saya yang menggunakan Java 16 (aplikasi spring boot 2.4.4), maven 3.6.3, di windows 10. Dengan cemas menunggu rilis 1.18.20.

Bagi siapa pun yang menggunakan Maven, saya dapat membuatnya bekerja dengan konfigurasi plugin kompiler berikut:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.8.1</version>
    <configuration>
        <source>16</source>
        <target>16</target>
        <fork>true</fork>
        <compilerArgs>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED</arg>
        </compilerArgs>
        <annotationProcessorPaths>
            <path>
                <groupId>org.projectlombok</groupId>
                <artifactId>lombok</artifactId>
                <version>1.18.16</version>
            </path>
        </annotationProcessorPaths>
    </configuration>
</plugin>

Perhatikan bahwa <fork>true</fork> diperlukan, jika tidak, Maven tampaknya (diam-diam) mengabaikan opsi -J saat menjalankan kompiler. Sepertinya jdk.compiler/com.sun.tools.javac.jvm juga perlu diekspor di atas apa yang ditautkan @rspilker .

Ini bekerja sangat baik untuk saya. Agar build berfungsi di IntelliJ (2020.3.2) saya baru saja memeriksa ini di pengaturan:

2. We're still working on fully supporting records. The basic support is there, but we're also including `@NonNull` on record fields. The `javac` code is done, `ecj`/`Eclipse` is still not finished.

Tidak membangun untuk kita:

What went wrong:
Execution failed for task ':compileJava'.
> java.lang.IllegalAccessError: class lombok.javac.apt.LombokProcessor (in unnamed module @0x24c0edfd) cannot access class com.sun.tools.javac.processing.JavacProcessingEnvironment (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.processing to unnamed module <strong i="9">@0x24c0edfd</strong>

Menggunakan Gradle 7.0-rc-1,

distributionUrl=https\://services.gradle.org/distributions/gradle-7.0-rc-1-bin.zip
distributionSha256Sum=12b807b5d6b065f05e0e47d8d00e9d55fe26d3cfc6cdb22d6825a93940edec90

toolchain {
    languageVersion = JavaLanguageVersion.of(16)
    vendor = JvmVendorSpec.ADOPTOPENJDK
}



md5-b4861bfec97d39192170a5b3a19162d4



org.projectlombok:lombok:edge-SNAPSHOT



md5-b4861bfec97d39192170a5b3a19162d4



dependencyResolutionManagement {
    repositories {
        mavenCentral()
        maven {
            url "https://projectlombok.org/edge-releases"
        }
    }
}



md5-b4861bfec97d39192170a5b3a19162d4



    options.fork = true
    options.forkOptions.jvmArgs += "--add-opens=jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED"
    options.forkOptions.jvmArgs += "--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED"
    options.forkOptions.jvmArgs += "--add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED"
    options.forkOptions.jvmArgs += "--add-opens=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED"
    options.forkOptions.jvmArgs += "--add-opens=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED"
    options.forkOptions.jvmArgs += "--add-opens=jdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED"
    options.forkOptions.jvmArgs += "--add-opens=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED"
    options.forkOptions.jvmArgs += "--add-opens=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED"
    options.forkOptions.jvmArgs += "--add-opens=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED"
    options.forkOptions.jvmArgs += "--add-opens=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED"



md5-119d24f4445673e314e6f791537b4efd



java.lang.NoSuchMethodError: 'boolean com.sun.tools.javac.code.Symbol$TypeSymbol.isLocal()'
        at lombok.javac.JavacResolution.typeToJCTree0(JavacResolution.java:455)
        at lombok.javac.JavacResolution.typeToJCTree(JavacResolution.java:314)
        at lombok.javac.JavacResolution.typeToJCTree(JavacResolution.java:295)
        at lombok.javac.handlers.HandleDelegate.createDelegateMethod(HandleDelegate.java:343)
        at lombok.javac.handlers.HandleDelegate.generateAndAdd(HandleDelegate.java:223)
        at lombok.javac.handlers.HandleDelegate.handle(HandleDelegate.java:214)
        at lombok.javac.HandlerLibrary$AnnotationHandlerContainer.handle(HandlerLibrary.java:113)
        at lombok.javac.HandlerLibrary.handleAnnotation(HandlerLibrary.java:256)
        at lombok.javac.JavacTransformer$AnnotationVisitor.visitAnnotationOnField(JavacTransformer.java:84)
        at lombok.javac.JavacNode.traverse(JavacNode.java:135)
        at lombok.javac.JavacAST.traverseChildren(JavacAST.java:138)
        at lombok.javac.JavacNode.traverse(JavacNode.java:100)
        at lombok.javac.JavacAST.traverseChildren(JavacAST.java:138)
        at lombok.javac.JavacNode.traverse(JavacNode.java:95)
        at lombok.javac.JavacAST.traverseChildren(JavacAST.java:138)
        at lombok.javac.JavacNode.traverse(JavacNode.java:90)
        at lombok.javac.JavacAST.traverse(JavacAST.java:134)
        at lombok.javac.JavacTransformer.transform(JavacTransformer.java:63)
        at lombok.javac.apt.LombokProcessor.process(LombokProcessor.java:326)
        at lombok.core.AnnotationProcessor$JavacDescriptor.process(AnnotationProcessor.java:187)
        at lombok.core.AnnotationProcessor.process(AnnotationProcessor.java:237)
        at lombok.launch.AnnotationProcessorHider$AnnotationProcessor.process(AnnotationProcessor.java:90)
        at org.gradle.api.internal.tasks.compile.processing.DelegatingProcessor.process(DelegatingProcessor.java:62)
        at org.gradle.api.internal.tasks.compile.processing.IsolatingProcessor.process(IsolatingProcessor.java:50)
        at org.gradle.api.internal.tasks.compile.processing.DelegatingProcessor.process(DelegatingProcessor.java:62)
        at org.gradle.api.internal.tasks.compile.processing.TimeTrackingProcessor.access$401(TimeTrackingProcessor.java:37)
        at org.gradle.api.internal.tasks.compile.processing.TimeTrackingProcessor$5.create(TimeTrackingProcessor.java:99)
        at org.gradle.api.internal.tasks.compile.processing.TimeTrackingProcessor$5.create(TimeTrackingProcessor.java:96)
        at org.gradle.api.internal.tasks.compile.processing.TimeTrackingProcessor.track(TimeTrackingProcessor.java:117)
        at org.gradle.api.internal.tasks.compile.processing.TimeTrackingProcessor.process(TimeTrackingProcessor.java:96)
        at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:1025)
        at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:940)
        at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1269)
        at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1384)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1261)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:935)
        at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:104)
        at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.invocationHelper(JavacTaskImpl.java:152)
        at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:100)
        at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:94)
        at org.gradle.internal.compiler.java.IncrementalCompileTask.call(IncrementalCompileTask.java:77)
        at org.gradle.api.internal.tasks.compile.AnnotationProcessingCompileTask.call(AnnotationProcessingCompileTask.java:94)
        at org.gradle.api.internal.tasks.compile.ResourceCleaningCompilationTask.call(ResourceCleaningCompilationTask.java:57)
        at org.gradle.api.internal.tasks.compile.JdkJavaCompiler.execute(JdkJavaCompiler.java:55)
        at org.gradle.api.internal.tasks.compile.JdkJavaCompiler.execute(JdkJavaCompiler.java:40)
        at org.gradle.api.internal.tasks.compile.daemon.AbstractDaemonCompiler$CompilerWorkAction.execute(AbstractDaemonCompiler.java:135)
        at org.gradle.workers.internal.DefaultWorkerServer.execute(DefaultWorkerServer.java:63)
        at org.gradle.workers.internal.AbstractClassLoaderWorker$1.create(AbstractClassLoaderWorker.java:49)
        at org.gradle.workers.internal.AbstractClassLoaderWorker$1.create(AbstractClassLoaderWorker.java:43)
        at org.gradle.internal.classloader.ClassLoaderUtils.executeInClassloader(ClassLoaderUtils.java:97)
        at org.gradle.workers.internal.AbstractClassLoaderWorker.executeInClassLoader(AbstractClassLoaderWorker.java:43)
        at org.gradle.workers.internal.FlatClassLoaderWorker.run(FlatClassLoaderWorker.java:32)
        at org.gradle.workers.internal.FlatClassLoaderWorker.run(FlatClassLoaderWorker.java:22)
        at org.gradle.workers.internal.WorkerDaemonServer.run(WorkerDaemonServer.java:85)
        at org.gradle.workers.internal.WorkerDaemonServer.run(WorkerDaemonServer.java:55)
        at org.gradle.process.internal.worker.request.WorkerAction$1.call(WorkerAction.java:138)
        at org.gradle.process.internal.worker.child.WorkerLogEventListener.withWorkerLoggingProtocol(WorkerLogEventListener.java:41)
        at org.gradle.process.internal.worker.request.WorkerAction.run(WorkerAction.java:135)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:567)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
        at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182)
        at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:164)
        at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:414)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
        at java.base/java.lang.Thread.run(Thread.java:831)
java.lang.NoSuchMethodError: 'boolean com.sun.tools.javac.code.Symbol$TypeSymbol.isLocal()'
        at lombok.javac.JavacResolution.typeToJCTree0(JavacResolution.java:455)
        at lombok.javac.JavacResolution.typeToJCTree(JavacResolution.java:314)
        at lombok.javac.JavacResolution.typeToJCTree(JavacResolution.java:295)
        at lombok.javac.handlers.HandleDelegate.createDelegateMethod(HandleDelegate.java:308)
        at lombok.javac.handlers.HandleDelegate.generateAndAdd(HandleDelegate.java:223)
        at lombok.javac.handlers.HandleDelegate.handle(HandleDelegate.java:214)
        at lombok.javac.HandlerLibrary$AnnotationHandlerContainer.handle(HandlerLibrary.java:113)
        at lombok.javac.HandlerLibrary.handleAnnotation(HandlerLibrary.java:256)
        at lombok.javac.JavacTransformer$AnnotationVisitor.visitAnnotationOnField(JavacTransformer.java:84)
        at lombok.javac.JavacNode.traverse(JavacNode.java:135)
        at lombok.javac.JavacAST.traverseChildren(JavacAST.java:138)
        at lombok.javac.JavacNode.traverse(JavacNode.java:100)
        at lombok.javac.JavacAST.traverseChildren(JavacAST.java:138)
        at lombok.javac.JavacNode.traverse(JavacNode.java:95)
        at lombok.javac.JavacAST.traverseChildren(JavacAST.java:138)
        at lombok.javac.JavacNode.traverse(JavacNode.java:95)
        at lombok.javac.JavacAST.traverseChildren(JavacAST.java:138)
        at lombok.javac.JavacNode.traverse(JavacNode.java:90)
        at lombok.javac.JavacAST.traverse(JavacAST.java:134)
        at lombok.javac.JavacTransformer.transform(JavacTransformer.java:63)
        at lombok.javac.apt.LombokProcessor.process(LombokProcessor.java:326)
        at lombok.core.AnnotationProcessor$JavacDescriptor.process(AnnotationProcessor.java:187)
        at lombok.core.AnnotationProcessor.process(AnnotationProcessor.java:237)
        at lombok.launch.AnnotationProcessorHider$AnnotationProcessor.process(AnnotationProcessor.java:90)
        at org.gradle.api.internal.tasks.compile.processing.DelegatingProcessor.process(DelegatingProcessor.java:62)
        at org.gradle.api.internal.tasks.compile.processing.IsolatingProcessor.process(IsolatingProcessor.java:50)
        at org.gradle.api.internal.tasks.compile.processing.DelegatingProcessor.process(DelegatingProcessor.java:62)
        at org.gradle.api.internal.tasks.compile.processing.TimeTrackingProcessor.access$401(TimeTrackingProcessor.java:37)
        at org.gradle.api.internal.tasks.compile.processing.TimeTrackingProcessor$5.create(TimeTrackingProcessor.java:99)
        at org.gradle.api.internal.tasks.compile.processing.TimeTrackingProcessor$5.create(TimeTrackingProcessor.java:96)
        at org.gradle.api.internal.tasks.compile.processing.TimeTrackingProcessor.track(TimeTrackingProcessor.java:117)
        at org.gradle.api.internal.tasks.compile.processing.TimeTrackingProcessor.process(TimeTrackingProcessor.java:96)
        at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:1025)
        at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:940)
        at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1269)
        at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1384)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1261)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:935)
        at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:104)
        at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.invocationHelper(JavacTaskImpl.java:152)
        at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:100)
        at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:94)
        at org.gradle.internal.compiler.java.IncrementalCompileTask.call(IncrementalCompileTask.java:77)
        at org.gradle.api.internal.tasks.compile.AnnotationProcessingCompileTask.call(AnnotationProcessingCompileTask.java:94)
        at org.gradle.api.internal.tasks.compile.ResourceCleaningCompilationTask.call(ResourceCleaningCompilationTask.java:57)
        at org.gradle.api.internal.tasks.compile.JdkJavaCompiler.execute(JdkJavaCompiler.java:55)
        at org.gradle.api.internal.tasks.compile.JdkJavaCompiler.execute(JdkJavaCompiler.java:40)
        at org.gradle.api.internal.tasks.compile.daemon.AbstractDaemonCompiler$CompilerWorkAction.execute(AbstractDaemonCompiler.java:135)
        at org.gradle.workers.internal.DefaultWorkerServer.execute(DefaultWorkerServer.java:63)
        at org.gradle.workers.internal.AbstractClassLoaderWorker$1.create(AbstractClassLoaderWorker.java:49)
        at org.gradle.workers.internal.AbstractClassLoaderWorker$1.create(AbstractClassLoaderWorker.java:43)
        at org.gradle.internal.classloader.ClassLoaderUtils.executeInClassloader(ClassLoaderUtils.java:97)
        at org.gradle.workers.internal.AbstractClassLoaderWorker.executeInClassLoader(AbstractClassLoaderWorker.java:43)
        at org.gradle.workers.internal.FlatClassLoaderWorker.run(FlatClassLoaderWorker.java:32)
        at org.gradle.workers.internal.FlatClassLoaderWorker.run(FlatClassLoaderWorker.java:22)
        at org.gradle.workers.internal.WorkerDaemonServer.run(WorkerDaemonServer.java:85)
        at org.gradle.workers.internal.WorkerDaemonServer.run(WorkerDaemonServer.java:55)
        at org.gradle.process.internal.worker.request.WorkerAction$1.call(WorkerAction.java:138)
        at org.gradle.process.internal.worker.child.WorkerLogEventListener.withWorkerLoggingProtocol(WorkerLogEventListener.java:41)
        at org.gradle.process.internal.worker.request.WorkerAction.run(WorkerAction.java:135)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:567)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
        at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182)
        at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:164)
        at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:414)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
        at java.base/java.lang.Thread.run(Thread.java:831)

_[Sunting]: sebenarnya bukan masalah lombok (lebih jelasnya ada di komentar saya yang lain di bawah)._

Untuk bagian saya, saya masih memiliki satu opsi --add-opens untuk disimpan agar kompilasi berhasil dengan versi edge-SNAPSHOT (gradle 6.8.3, openjdk build 16+36 dari AdoptOpenJDK):

  tasks.withType<JavaCompile> {
      options.isFork = true
      options.forkOptions.jvmArgs!!.add("--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED")

Tanpa ini, gagal dengan
> java.lang.IllegalAccessError: class org.gradle.internal.compiler.java.ClassNameCollector (in unnamed module @0x14d45694) cannot access class com.sun.tools.javac.code.Symbol$TypeSymbol (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.code to unnamed module @0x14d45694

konfigurasikan saja ini tidak berfungsi untuk saya

tasks.withType(JavaCompile) { options.fork = true // lombok jdk16 options.forkOptions.jvmArgs.addAll([ "--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED", "--add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED", "--add-exports=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED", "--add-exports=jdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED", "--add-exports=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED", "--add-exports=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED", "--add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED", "--add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED", "--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED", "--add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED", "--add-opens=jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED", ]) }

tetapi mengapa masalah ini ditutup jika Lombok tidak berfungsi dengan JDK16?

@sblantipodi Perbaikan digabungkan dan berfungsi, setidaknya dalam banyak kasus.
@ewirch Ini sepertinya versi edge yang ketinggalan jaman, pastikan Anda menggunakan yang terbaru.

@sblantipodi Perbaikan digabungkan dan berfungsi, setidaknya dalam banyak kasus.
@ewirch Ini sepertinya versi edge yang ketinggalan jaman, pastikan Anda menggunakan yang terbaru.

Menggunakan versi edge terbaru dan masih tidak berfungsi, saya menulis kesalahan saya beberapa posting di atas tetapi hampir sama dengan pembukanya.

Perbaikan untuk "Kebanyakan kasus" seharusnya tidak menutup masalah,
silakan buka kembali masalah sampai benar-benar diperbaiki.

Saya berkomentar di atas bahwa lombok bekerja dengan versi edge-SNAPSHOT menggunakan JDK16.

Namun, delombok TIDAK berfungsi. sepertinya ada perubahan ke core/lombok/javac/apt/LombokProcessor.java untuk jdk16. Komit itu muncul di cabang "master", tetapi bukan "tepi". Bisakah edge-SNAPSHOT dirilis ulang dengan perubahan itu?

Ini adalah komit dengan hash 937a4dfca209d30e567a4c4fcbc9fe868221680a, berlabel "[jdk16] fix delombok (dan test suite, yang bergantung padanya) untuk jdk16"

@Rawi01

@ewirch Ini sepertinya versi edge yang ketinggalan jaman, pastikan Anda menggunakan yang terbaru.

Anda benar, saya tidak memikirkan resolusi konflik ketergantungan. spring-boot-dependencies menarik ketergantungan transitif pada 1.18.16 dan menggantikan persyaratan edge-SNAPSHOT . Menambahkan batasan resolusi Gradle ini memperbaiki bahwa:

dependencies {
    constraints {
        api("org.projectlombok:lombok") {
            version {
                strictly "edge-SNAPSHOT"
            }
            because "Otherwise a transitive dependency might overwrite the edge-SNAPSHOT requirement."
        }
    }
}

Kompilasi dengan JDK 16 berhasil sekarang.

Lombok v1.18.20 dengan dukungan penuh JDK16 (termasuk Eclipse dan pemikiran ulang tentang bagaimana berbagai fitur lombok harus berinteraksi dengan record ) telah dirilis.

Baru saja diuji dengan Java 16 dan semuanya berfungsi dengan baik. Siapa pun yang masih mendapatkan kesalahan, pastikan Anda hanya memiliki ketergantungan pada pom Anda (jika menggunakan pakar), tidak perlu tambahan apa pun karena hanya merusak barang lagi (artinya jika Anda menggunakan penginisialisasi boot pegas, Anda harus menentukan liquibase ke 1.18.20 dalam deklarasi ketergantungan dan hapus deklarasi plugin).

Enam proyek hewan peliharaan ok di Jenkins dengan JDK 16 (sumber level 11) dan Lombok 1.18.20. Saya tidak akan mencoba IDE sebelum beberapa minggu.

Saya upgrade ke IntelliJ 2021.1 dan menggunakan JDK 16. Kemudian saya mengubah versi Lombok.

<path> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>1.18.20</version> </path>

Migrasi berhasil.

Tetap saja... tidak berhasil.. Saya tidak tahu apakah orang lain mengalami masalah yang sama. Inilah kesalahannya:

java: java.lang.IllegalAccessError: class lombok.javac.apt.LombokProcessor (dalam modul tanpa nama @0x2b1cdbd7) tidak dapat mengakses kelas com.sun.tools.javac.processing.JavacProcessingEnvironment (dalam modul jdk.compiler) karena modul jdk.compiler melakukannya tidak mengekspor com.sun.tools.javac.processing ke modul tanpa nama @0x2b1cdbd7

Inilah yang saya miliki:

1. IntelliJ 2021.1
2. Corretto JDK 16
3. Apache Maven 3.6.3
4. Lombok 1.18.20

Tidak bekerja dengan maven-compiler-plugin annotationProcessorPaths

• maven-compiler-plugin 3.8.1
• bukaJDK 16

Ketergantungan berikut tidak berfungsi

 <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <configuration>
                    <excludes>
                        <exclude>
                            <groupId>org.springframework.boot</groupId>
                            <artifactId>spring-boot-configuration-processor</artifactId>
                        </exclude>
                    </excludes>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-failsafe-plugin</artifactId>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>${maven-compiler-plugin.version}</version>
                <configuration>
                    <source>${java.version}</source> <!-- depending on your project -->
                    <target>${java.version}</target> <!-- depending on your project -->
                    <annotationProcessorPaths>
                        <path>
                            <groupId>org.mapstruct</groupId>
                            <artifactId>mapstruct-processor</artifactId>
                            <version>${org.mapstruct.version}</version>
                        </path>
                        <path>
                            <groupId>org.projectlombok</groupId>
                            <artifactId>lombok</artifactId>
                            <version>${lombok.version}</version>
                        </path>
                        <path>
                            <groupId>org.projectlombok</groupId>
                            <artifactId>lombok-mapstruct-binding</artifactId>
                            <version>${lombok-mapstruct-binding.version}</version>
                        </path>
                        <!-- other annotation processors -->
                    </annotationProcessorPaths>
                </configuration>
            </plugin>
        </plugins>
    </build>

Saya pikir mungkin Mapstruct tidak kompatibel dengan lombok 1.18.20

@dvdmtchln , @daniel94104 Jika tidak berhasil, silakan bagikan contoh proyek kecil atau detail tentang build Anda sehingga kami dapat mereproduksi masalahnya.

Tetap saja itu tidak berhasil untuk saya

dependencies {
    compileOnly 'org.projectlombok:lombok:1.18.20'
}

Lingkungan yang saya gunakan:

Java JDK 16
IntelliJ IDEA 2021.1
Tingkat 7.0
Lombok 1.18.20

Terima kasih.

Ketergantungan Anda tidak lengkap. Lihat https://projectlombok.org/setup/gradle.

Plugin gradle telah diperbarui ke 5.3.3.3 untuk bekerja dengan lombok versi terbaru:

plugins {
    id "io.freefair.lombok" version "5.3.3.3"
    id 'java-library'
    id 'idea'
}

@scholnicks
berhasil sekarang terima kasih.

Senang mendengar bahwa Anda baik untuk pergi.

-steve

Pada Sel, 13 Apr 2021 jam 11:43 bekaku @ . * > menulis:

@scholnicks https://github.com/scholnicks
berhasil sekarang terima kasih.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rzwitserloot/lombok/issues/2681#issuecomment-818838415 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AABTKEQ6MJQDQ4FAQW42OMLTIRRBDANCNFSM4U4HKVVQ
.