Lombok: Itu tidak bisa bekerja ketika @NoArgsConstructor dan @Builder dan@Data ditambahkan

Menambahkan juga @AllArgsConstructor harus dilakukan.

berarti ini bug ya? haruskah anotasi builder bekerja sama dengan anotasi NoArgsConstructor?

@huehnerlady saya kira, jadi. @Builder semacam termasuk "lemah @AllArgsConstructor ", yang dimatikan oleh anotasi @XArgsConstructor eksplisit. Karena @Builder tidak dapat bekerja tanpa konstruktor, ini mungkin harus diperkuat:

Itu harus selalu menghasilkan konstruktor yang diperlukan, kecuali konstruktor "bertabrakan" sudah ada (didefinisikan secara eksplisit atau menggunakan anotasi Lombok).

Di sini, "bertabrakan" harus berarti bahwa mendefinisikan yang lain akan membuat kompilasi gagal, tetapi ini tidak selalu memungkinkan, jadi "jumlah argumen yang sama" digunakan (seperti di tempat lain di Lombok juga).

WDYT?

Apa sebenarnya pesan kesalahan yang Anda dapatkan? Apakah ini kesalahan runtime saat Anda membuat serial, atau kesalahan waktu kompilasi?
Jika Anda menggunakan lombok 1.18.2, silakan coba rilis edge terbaru 1.18.3 , karena menyertakan beberapa perbaikan untuk @SuperBuilder yang tidak ada di 1.18.2.

@janrieke Saya beralih ke snakeyaml dan tidak ada masalah lagi.

Senang mendengarnya.
Tapi tolong jangan hapus posting Anda jika seseorang langsung membalasnya, karena itu membuat diskusi sangat sulit untuk diikuti nanti.

@yanjinbin Saya menambahkan dua anotasi: @NoArgsConstructor dan @AllArgsConstructor , itu berfungsi. Semoga beruntung!

Terima kasih, ini bekerja untuk saya

Apa sebenarnya pesan kesalahan yang Anda dapatkan? Apakah ini kesalahan runtime saat Anda membuat serial, atau kesalahan waktu kompilasi?

Saya memiliki kesalahan

Error:(10, 1) java: constructor MdmAttribute in class com.bvn13.moex.mdm.buybackretriever.model.MdmAttribute cannot be applied to given types;
  required: no arguments
  found: java.lang.String,java.lang.String
  reason: actual and formal argument lists differ in length

Kode saya adalah:

<strong i="11">@Builder</strong>
<strong i="12">@Getter</strong>
<strong i="13">@Setter</strong>
<strong i="14">@NoArgsConstructor</strong>
@JacksonXmlRootElement(localName = "Attribute")
public class MdmAttribute {

    @JacksonXmlProperty(localName = "CodeAttr")
    private String codeAttr;

    @JacksonXmlProperty(localName = "ValueAttr")
    private String valueAttr;

    <strong i="15">@Override</strong>
    public String toString() {
        return String.format("Attribute{CodeAttr=%s, ValueAttr=%s}", codeAttr, valueAttr);
    }

}

Juga mencoba dengan @Data alih-alih @Getter + @Setter - menyebabkan kesalahan yang sama.

Hai @ bvn13 Saya pikir itu sama dengan masalah ini juga:
Duplikat https://github.com/rzwitserloot/lombok/issues/816#
semuanya bermuara pada penggunaan @Builder secara umum sementara Menggunakan Konstruktor default new Foo() , tidak masalah jika Anda menambahkan @NoArgsConstructor atau tidak
Solusi tercepat dan paling sederhana adalah seperti yang dikatakan @Maaartinus , menambahkan @AllArgsConstructor ke @NoArgsConstructor

Meskipun menambahkan @AllArgsConstructor adalah solusi, ada masalah desain perangkat lunak utama dengan memiliki konstruktor seperti itu - terutama untuk kelas dengan banyak bidang, dan terlebih lagi ketika ada bidang dengan tipe yang sama. Bayangkan membaca kode seperti ini:

Foo foo = new Foo(1, 2, true, false, 3, false, 5, true);

Bagaimana Anda bisa tahu apa arti semua angka dan bendera ini - bidang apa yang mereka rujuk. Di sinilah pola builder masuk akal:

Foo foo = Foo.builder()
    .minCount(1)
    .maxCount(2)
    .allowGaps(true)
    .allowOutOfRange(false)
   ...etc...

Mengapa anotasi @Builder tidak dapat mengasumsikan/menerapkan @NoArgsConstructor dan kemudian memanggil penyetel yang relevan?. Jika kompatibilitas mundur menjadi masalah, mari buat anotasi baru @SetterBasedBuilder yang menyiratkan perilaku di atas.

Karena mungkin tidak ada setter. Dan bidang final tidak dapat disetel bahkan secara langsung.

Satu-satunya cara adalah beralih ke konstruktor yang menggunakan instance builder sebagai satu-satunya parameternya. Namun, ini tidak kompatibel dan sangat mungkin untuk memecahkan kode yang ada, jadi itu bukan pilihan.
Jika Anda menginginkan pendekatan itu, gunakan @SuperBuilder .

Jika tidak, gunakan konstruktor private . Itu masih jelek, tapi setidaknya tidak terlalu terlihat.

Dalam komentar #1912 ini, @rzwitserloot mengatakan bahwa perilaku ini memang

Menambahkan juga @AllArgsConstructor harus dilakukan.

Menyelamatkan pantatku. Terima kasih.

Ini tampaknya menjadi cacat kritis. Kami tidak dapat menggunakan @Builder pada entitas JPA

Tolong jelaskan mengapa menambahkan @AllArgsConstructor tidak menyelesaikan masalah ini untuk Anda.

Tolong jelaskan mengapa menambahkan @AllArgsConstructor tidak menyelesaikan masalah ini untuk Anda.

Itu memecahkan masalah setelah meletakkan @AllArgsConstructor . Terima kasih untuk bantuannya.
Maksud saya di sini adalah, Mengapa memiliki konstruktor yang tidak perlu yang tidak digunakan.
Hanya untuk menggunakan @Builder kita perlu memiliki @NoArgsConstructor dan @AllArgsConstructor . @janrieke apa pendapat Anda tentang ini?

@cooligc Anda tidak menyatakannya dengan tepat. Satu-satunya @Builder berfungsi, karena ia membuat konstruktornya sendiri. Kehadiran @NoArgsConstructor yang mencegahnya karena anotasi @XConstructor eksplisit menekan @AllArgsConstructor implisit.

Saya tidak yakin, apakah ini harus diubah. Jelas, @Builder tidak dapat melakukan apa pun dengan @NoArgsConstructor , tetapi aturannya sudah rumit.

Sebenarnya, saya tidak mengerti bagaimana @Builder dan @NoArgsConstructor bisa masuk akal bersama. Dengan yang terakhir saya jelas menginginkan objek yang sepenuhnya bisa berubah jadi mengapa saya membutuhkan yang pertama?

Yah, mungkin berguna untuk membuat tes yang lebih bersih dengan @Builder . Saya berakhir dengan objek dengan @Builder , @NoArgsContructor dan @AllArgsContructor

Perlu dicatat bahwa ini masih bug, meskipun menyelesaikan masalah

Perlu dicatat bahwa ini masih bug, meskipun menyelesaikan masalah

Ini bukan bug, tetapi pilihan desain untuk menghormati anotasi yang ditetapkan secara eksplisit yang benar-benar masuk akal.

Saya baru saja mengalami ini dan harus mencari di internet untuk menemukan masalah ini.
Saya mengerti bahwa ini adalah pilihan desain, tetapi sekarang, Anda harus dapat memberi tahu bahwa orang-orang, secara intuitif, akan menggunakan <strong i="6">@Builder</strong> @NoArgsConstructor sebagai pilihan pertama mereka dan mengalami pengecualian ini.

Kemudian mereka harus mencari di internet, membaca utas ini dan akhirnya mengetahui bahwa "dengan desain" pengecualian ini diharapkan.

Bukankah ini merepotkan? Bukankah desain perangkat lunak seharusnya lebih intuitif?

Saya mengerti bahwa ini mungkin pilihan desain, tetapi tampaknya UX-nya kurang. Mungkin, pesan kesalahan bisa lebih deskriptif karena kami tahu ini adalah jebakan umum. Misalnya, "Anda mungkin telah menetapkan @Builder dan @NoArgsContructor bersama-sama. Coba tambahkan @AllArksConstructor untuk menghilangkannya".

Atau lebih baik lagi, biarkan kombinasi @Data dan @Builder digunakan sebagai sinyal bahwa varian konstruktor yang dibutuhkan oleh masing-masing perlu dibangkitkan

Perlu dicatat bahwa ini masih bug, meskipun menyelesaikan masalah

Ini bukan bug, tetapi pilihan desain untuk menghormati anotasi yang ditetapkan secara eksplisit yang benar-benar masuk akal.

Maaf tapi bagaimana ini bukan bug ketika Anda perlu menentukan keduanya? Maksud saya mengapa saya perlu menambahkan @AllArgsConstructor agar @NoArgsConstructor berperilaku? Ini setidaknya melanggar prinsip paling tidak mengejutkan

Perlu dicatat bahwa ini masih bug, meskipun menyelesaikan masalah

Ini bukan bug, tetapi pilihan desain untuk menghormati anotasi yang ditetapkan secara eksplisit yang benar-benar masuk akal.

Maaf tapi bagaimana ini bukan bug ketika Anda perlu menentukan keduanya? Maksud saya mengapa saya perlu menambahkan @AllArgsConstructor agar @NoArgsConstructor berperilaku? Ini setidaknya melanggar prinsip paling tidak mengejutkan

Jika saya ingat dengan benar, Anda perlu @AllArgsConstructor untuk membuat @Builder berperilaku, yang masuk akal, karena Anda secara eksplisit memaksa @NoArgsConstructor yang menimpa default pembangun.

Yah, seperti yang disebutkan di atas, builder dapat dipaksa membuat konstruktor all-args terlepas dari anotasi lain yang tampaknya merupakan ide bagus.