Có an toàn khi sử dụng Project Lombok không? [đóng cửa]

Trong trường hợp bạn không biết Project Lombok giúp giải quyết một số phiền toái của Java với các công cụ như tạo getters và setters với chú thích và thậm chí JavaBean đơn giản như thế hệ với @Data . Nó thực sự có thể giúp tôi, đặc biệt là trong 50 đối tượng sự kiện khác nhau, nơi bạn có tới 7 trường khác nhau cần được xây dựng và ẩn bằng getters. Tôi có thể loại bỏ gần một ngàn dòng mã với điều này.

Tuy nhiên, tôi lo lắng rằng về lâu dài, đó sẽ là một quyết định đầy tiếc nuối. Chim hồng hạc sẽ nổ ra trong ##Java Freenodekênh khi tôi đề cập đến nó, việc cung cấp các đoạn mã sẽ gây nhầm lẫn cho những người trợ giúp có thể, mọi người sẽ phàn nàn về việc JavaDoc bị mất và những người cam kết trong tương lai có thể xóa tất cả. Tôi thực sự sẽ thích sự tích cực, nhưng tôi lo lắng về sự tiêu cực.

Vì vậy: Có an toàn khi sử dụng Lombok cho bất kỳ dự án nào, dù nhỏ hay lớn? Là những tác động tích cực có giá trị tiêu cực?

Có vẻ như bạn đã quyết định rằng Project Lombok mang lại cho bạn những lợi thế kỹ thuật quan trọng cho dự án mới được đề xuất của bạn. (Để rõ ràng từ đầu, tôi không có quan điểm cụ thể nào về Dự án Lombok, bằng cách này hay cách khác.)

Trước khi bạn sử dụng Project Lombok (hoặc bất kỳ công nghệ thay đổi trò chơi nào khác) trong một số dự án (nguồn mở hoặc khôn ngoan khác), bạn cần đảm bảo rằng những người nắm giữ cổ phần của dự án đồng ý với điều này. Điều này bao gồm các nhà phát triển và bất kỳ người dùng quan trọng nào (ví dụ: nhà tài trợ chính thức hoặc không chính thức).

Bạn đề cập đến những vấn đề tiềm năng:

Chim hồng hạc sẽ phun trào trong kênh ## Java Freenode khi tôi đề cập đến nó,

Dễ dàng. Bỏ qua / không tham gia vào flamewar, hoặc đơn giản là không đề cập đến Lombok.

cung cấp đoạn mã sẽ gây nhầm lẫn cho người trợ giúp có thể,

Nếu chiến lược của dự án là sử dụng Lombok, thì những người trợ giúp có thể sẽ cần phải làm quen với nó.

mọi người sẽ phàn nàn về việc thiếu JavaDoc,

Đó là vấn đề của họ. Không ai trong tâm trí của họ cố gắng áp dụng cứng nhắc các quy tắc tài liệu / mã nguồn của tổ chức của họ cho phần mềm nguồn mở của bên thứ ba. Nhóm dự án nên được tự do thiết lập các tiêu chuẩn tài liệu / mã nguồn dự án phù hợp với công nghệ đang được sử dụng.

( FOLLOWUP - Các nhà phát triển Lombok nhận ra rằng việc không tạo ra các bình luận javadoc cho các phương thức getter và setter được tổng hợp là một vấn đề. )

và những người cam kết trong tương lai có thể loại bỏ tất cả.

Đó không phải là trên! Nếu chiến lược dự án đã được thống nhất là sử dụng Lombok, thì những người cam kết vô cớ hủy bỏ mã này sẽ bị trừng phạt và nếu cần thiết hãy rút lại quyền cam kết của họ.

Tất nhiên, điều này giả định rằng bạn đã mua từ các bên liên quan ... bao gồm cả các nhà phát triển. Và nó giả định rằng bạn đã sẵn sàng để tranh luận nguyên nhân của bạn, và xử lý thích hợp những tiếng nói bất đồng không thể tránh khỏi.

Mới bắt đầu sử dụng Lombok ngày hôm nay. Cho đến nay tôi thích nó, nhưng một nhược điểm tôi không thấy đề cập đến là tái cấu trúc hỗ trợ.

Nếu bạn có một lớp được chú thích @Data, nó sẽ tạo ra các getters và setters cho bạn dựa trên tên trường. Nếu bạn sử dụng một trong những getters đó trong một lớp khác, sau đó quyết định trường được đặt tên kém, nó sẽ không tìm thấy cách sử dụng của các getters và setters đó và thay thế tên cũ bằng tên mới.

Tôi sẽ tưởng tượng điều này sẽ phải được thực hiện thông qua một trình cắm thêm IDE chứ không phải thông qua Lombok.

CẬP NHẬT (ngày 22 tháng 1 năm 13)
Sau khi sử dụng Lombok trong 3 tháng, tôi vẫn giới thiệu nó cho hầu hết các dự án. Tôi đã làm, tuy nhiên, tìm thấy một nhược điểm khác tương tự như được liệt kê ở trên.

Nếu bạn có một lớp, giả sử MyCompoundObject.javacó 2 thành viên, cả hai được chú thích @Delegate, nói myWidgetsvà myGadgetskhi bạn gọi myCompoundObject.getThingies()từ một lớp khác, không thể biết liệu nó có được ủy quyền cho Widgethoặc Gadgetbởi vì bạn không còn có thể chuyển sang nguồn trong IDE.

Sử dụng Eclipse "Tạo các phương thức đại biểu ..." cung cấp cho bạn chức năng tương tự, cũng nhanh như vậy và cung cấp nhảy nguồn. Nhược điểm của nó là làm tắc nghẽn nguồn của bạn với mã soạn sẵn để lấy trọng tâm ra khỏi những thứ quan trọng.

CẬP NHẬT 2 (ngày 26 tháng 2 năm 13)
Sau 5 tháng, chúng tôi vẫn đang sử dụng Lombok, nhưng tôi có một số phiền toái khác. Việc thiếu một getter & setter được khai báo có thể gây khó chịu vào những lúc bạn đang cố gắng làm quen với mã mới.

Ví dụ: nếu tôi thấy một phương thức được gọi getDynamicCols()nhưng tôi không biết nó là gì, tôi có một số trở ngại thêm để xác định mục đích của phương pháp này. Một số trở ngại là Lombok, một số là thiếu plugin thông minh Lombok. Rào cản bao gồm:

• Thiếu JavaDocs. Nếu tôi javadoc trường, tôi sẽ hy vọng getter và setter sẽ kế thừa javadoc đó thông qua bước biên dịch Lombok.
• Chuyển đến định nghĩa phương thức đưa tôi đến lớp, nhưng không phải là thuộc tính đã tạo ra getter. Đây là một vấn đề plugin.
• Rõ ràng là bạn không thể đặt điểm dừng trong getter / setter trừ khi bạn tạo hoặc mã hóa phương thức.
• LƯU Ý: Tìm kiếm Tham khảo này không phải là vấn đề như tôi nghĩ đầu tiên. Bạn cần phải sử dụng một phối cảnh cho phép xem Outline mặc dù. Không phải là một vấn đề cho hầu hết các nhà phát triển. Vấn đề của tôi là tôi đang sử dụng Mylyn đang lọc Outlinechế độ xem của tôi , vì vậy tôi đã không thấy các phương pháp. Thiếu tìm kiếm tài liệu tham khảo. Nếu tôi muốn xem ai đang gọi getDynamicCols(args...), tôi phải tạo hoặc mã bộ setter để có thể tìm kiếm tài liệu tham khảo.

CẬP NHẬT 3 (Mar 7 '13)
Học cách sử dụng các cách làm khác nhau trong Eclipse tôi đoán. Bạn thực sự có thể đặt điểm dừng có điều kiện (BP) trên phương thức được tạo bởi Lombok. Sử dụng Outlinechế độ xem, bạn có thể nhấp chuột phải vào phương thức Toggle Method Breakpoint. Sau đó, khi bạn nhấn BP, bạn có thể sử dụng Variableschế độ xem gỡ lỗi để xem phương thức được tạo có tên các tham số (thường giống với tên trường) và cuối cùng, sử dụng Breakpointschế độ xem để nhấp chuột phải vào BP và chọn Breakpoint Properties...để thêm một điều kiện. Đẹp.

CẬP NHẬT 4 (16 tháng 8 '13)
Netbeans không thích nó khi bạn cập nhật các phụ thuộc Lombok trong Maven pom của bạn. Dự án vẫn biên dịch, nhưng các tệp bị gắn cờ vì có lỗi biên dịch vì không thể thấy các phương thức mà Lombok đang tạo. Xóa bộ nhớ cache Netbeans giải quyết vấn đề. Không chắc chắn nếu có tùy chọn "Dự án sạch" như trong Eclipse. Vấn đề nhỏ, nhưng muốn làm cho nó được biết đến.

CẬP NHẬT 5 (17 tháng 1, 14)
Lombok không phải lúc nào cũng chơi đẹp với Groovy, hoặc ít nhất là groovy-eclipse-compiler. Bạn có thể phải hạ cấp phiên bản trình biên dịch. Maven Groovy và Java + Lombok

CẬP NHẬT 6 (ngày 26 tháng 6 năm 14)
Một lời cảnh báo. Lombok hơi gây nghiện và nếu bạn làm việc trong một dự án mà bạn không thể sử dụng nó vì một số lý do, nó sẽ gây khó chịu cho bạn. Bạn có thể tốt hơn là không bao giờ sử dụng nó cả.

CẬP NHẬT 7 (23/07/14)
Đây là một chút cập nhật thú vị vì nó trực tiếp giải quyết vấn đề an toàn của việc áp dụng Lombok mà OP đã hỏi.

Kể từ v1,14, @Delegatechú thích đã bị hạ cấp thành trạng thái Thử nghiệm. Các chi tiết được ghi lại trên trang web của họ ( Tài liệu đại biểu Lombok ).

Vấn đề là, nếu bạn đang sử dụng tính năng này, các tùy chọn sao lưu của bạn bị hạn chế. Tôi thấy các tùy chọn như:

• Xóa thủ công @Delegatecác chú thích và tạo / mã hóa mã số đại biểu. Điều này khó hơn một chút nếu bạn đang sử dụng các thuộc tính trong chú thích.
• Delombok các tệp có @Delegatechú thích và có thể thêm lại vào các chú thích mà bạn muốn.
• Không bao giờ cập nhật Lombok hoặc duy trì một ngã ba (hoặc sống với việc sử dụng các tính năng trải nghiệm).
• Delombok toàn bộ dự án của bạn và ngừng sử dụng Lombok.

Theo như tôi có thể nói, Delombok không có tùy chọn để xóa một tập hợp các chú thích ; tất cả hoặc không có gì ít nhất là đối với ngữ cảnh của một tệp. Tôi đã mở một vé để yêu cầu tính năng này với cờ Delombok, nhưng tôi không mong đợi điều đó trong tương lai gần.

CẬP NHẬT 8 (ngày 20 tháng 10 năm 14)
Nếu đó là một lựa chọn cho bạn, Groovy cung cấp hầu hết các lợi ích tương tự của Lombok, cộng với một số lượng lớn các tính năng khác, bao gồm cả @Delegate . Nếu bạn nghĩ rằng bạn sẽ gặp khó khăn trong việc bán ý tưởng cho các quyền lực, hãy xem @CompileStatichoặc @TypeCheckedchú thích để xem liệu điều đó có thể giúp ích cho bạn không. Trên thực tế, trọng tâm chính của phiên bản Groovy 2.0 là an toàn tĩnh .

CẬP NHẬT 9 (ngày 1 tháng 9 năm 15)
Lombok vẫn đang được tích cực duy trì và nâng cao , điều này báo hiệu tốt đến mức độ an toàn của việc áp dụng. các @Builder chú thích là một trong những tính năng mới yêu thích của tôi.

CẬP NHẬT 10 (17/11/2015)
Điều này có vẻ không liên quan trực tiếp đến câu hỏi của OP, nhưng đáng để chia sẻ. Nếu bạn đang tìm kiếm các công cụ để giúp bạn giảm số lượng mã soạn sẵn mà bạn viết, bạn cũng có thể kiểm tra Google Auto - cụ thể là AutoValue . Nếu bạn nhìn vào sàn trượt của họ , danh sách Lombok là một giải pháp khả thi cho vấn đề họ đang cố gắng giải quyết. Nhược điểm họ liệt kê cho Lombok là:

• Mã được chèn là vô hình (bạn không thể "nhìn thấy" các phương thức mà nó tạo ra) [ed note - thực sự bạn có thể, nhưng nó chỉ cần một trình dịch ngược]
• Các hack trình biên dịch là không chuẩn và dễ vỡ
• "Theo quan điểm của chúng tôi, mã của bạn không còn thực sự là Java"

Tôi không chắc mình đồng ý với đánh giá của họ đến mức nào. Và với những nhược điểm của AutoValue được ghi lại trong các slide, tôi sẽ gắn bó với Lombok (nếu Groovy không phải là một lựa chọn).

CẬP NHẬT 11 (8/2/2016)
Tôi phát hiện ra Spring Roo có một số chú thích tương tự . Tôi hơi ngạc nhiên khi phát hiện ra rằng Roo vẫn còn là một điều và việc tìm tài liệu cho các chú thích hơi khó hiểu. Việc loại bỏ cũng không dễ dàng như de-lombok. Lombok có vẻ như là sự lựa chọn an toàn hơn.

CẬP NHẬT 12 (17/2/2016)
Trong khi cố gắng đưa ra những lời biện minh cho lý do tại sao việc mang lại Lombok cho dự án mà tôi hiện đang làm việc lại an toàn, tôi đã tìm thấy một miếng vàng được thêm vào v1.14- Hệ thống cấu hình ! Điều này có nghĩa là bạn có thể định cấu hình dự án để cho phép các tính năng nhất định mà nhóm của bạn cho là không an toàn hoặc không mong muốn. Tốt hơn nữa, nó cũng có thể tạo cấu hình thư mục cụ thể với các cài đặt khác nhau. Điều này thật tuyệt.

CẬP NHẬT 13 (ngày 4 tháng 10 năm 16)
Nếu loại điều này quan trọng với bạn, Oliver Gierke cảm thấy an toàn khi thêm Lombok vào Spring Data Rest .

CẬP NHẬT 14 (ngày 26 tháng 9 năm 17)
Như @gavenkoa đã chỉ ra trong các nhận xét về câu hỏi OP, hỗ trợ trình biên dịch JDK9 chưa khả dụng (Vấn đề # 985). Có vẻ như nó sẽ không phải là một sửa chữa dễ dàng cho nhóm Lombok để có được xung quanh.

CẬP NHẬT 15 (26/03/18)
Thay đổi Lombok cho biết kể từ v1.16.20 " Biên dịch lombok trên JDK1.9 hiện có thể thực hiện được " mặc dù # 985 vẫn mở.

Tuy nhiên, những thay đổi để phù hợp với JDK9, đòi hỏi một số thay đổi đột phá; tất cả bị cô lập với những thay đổi trong mặc định cấu hình. Có một chút liên quan đến việc họ đã giới thiệu các thay đổi vi phạm, nhưng phiên bản chỉ có số phiên bản "Tăng dần" (đi từ v1.16.18 đến v1.16.20). Vì bài đăng này là về sự an toàn, nếu bạn có một yarn/npmhệ thống xây dựng tương tự tự động nâng cấp lên phiên bản gia tăng mới nhất, bạn có thể sẽ bị đánh thức một cách thô lỗ.

CẬP NHẬT 16 (ngày 9 tháng 1 năm 19)

Có vẻ như các vấn đề về JDK9 đã được giải quyết và Lombok hoạt động với JDK10, và thậm chí JDK11 theo như tôi có thể nói.

Một điều tôi nhận thấy mặc dù liên quan đến khía cạnh an toàn là thực tế là nhật ký thay đổi đi từ v1.18.2 đến v1.18.4 liệt kê hai mục là BREAKING CHANGE!? Tôi không chắc chắn làm thế nào một thay đổi đột phá xảy ra trong một bản cập nhật "bản vá". Có thể là một vấn đề nếu bạn sử dụng một công cụ tự động cập nhật các phiên bản vá lỗi.

Hãy tiếp tục và sử dụng Lombok, bạn có thể nếu cần "delombok" mã của mình sau đó http://projectlombok.org/features/delombok.html

Cá nhân (và do đó một cách chủ quan) Tôi đã thấy rằng việc sử dụng Lombok làm cho mã của tôi rõ ràng hơn về những gì tôi đang cố gắng đạt được khi so sánh với việc triển khai IDE / riêng của các phương thức phức tạp như hashcode & bằng.

Khi đang sử dụng

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

việc giữ Equals & HashCode dễ dàng hơn nhiều và theo dõi các trường nào được đánh giá, hơn bất kỳ triển khai IDE / riêng nào. Điều này đặc biệt đúng khi bạn vẫn thêm / xóa các trường thường xuyên.

Điều tương tự cũng xảy ra đối với @ToStringchú thích và các tham số của nó, trong đó truyền đạt rõ ràng hành vi mong muốn liên quan đến các trường được bao gồm / loại trừ, sử dụng getters hoặc truy cập trường và wether hoặc không gọi super.toString().

Và một lần nữa bằng cách chú thích toàn bộ một lớp bằng @Getterhoặc @Setter(AccessLevel.NONE)(và tùy ý ghi đè bất kỳ phương thức phân kỳ nào), ngay lập tức rõ ràng phương thức nào sẽ có sẵn cho các trường.

Những lợi ích cứ lặp đi lặp lại ..

Trong tâm trí tôi không phải là về việc giảm mã, mà là truyền đạt rõ ràng những gì bạn mong muốn đạt được, thay vì phải tìm ra nó từ Javadoc hoặc các triển khai. Mã giảm chỉ giúp dễ dàng phát hiện bất kỳ triển khai phương thức phân kỳ nào.

Lombok rất tuyệt, nhưng ...

Lombok phá vỡ các quy tắc xử lý chú thích, trong đó nó không tạo ra các tệp nguồn mới. Điều này có nghĩa là nó không thể được sử dụng với các bộ xử lý chú thích khác nếu họ mong đợi các getters / setters hoặc bất cứ thứ gì khác tồn tại.

Xử lý chú thích chạy trong một loạt các vòng. Trong mỗi vòng, mỗi người được một lượt để chạy. Nếu bất kỳ tệp java mới nào được tìm thấy sau khi vòng hoàn thành, vòng khác sẽ bắt đầu. Theo cách này, thứ tự của bộ xử lý chú thích không thành vấn đề nếu chúng chỉ tạo các tệp mới. Vì lombok không tạo ra bất kỳ tệp mới nào, không có vòng mới nào được bắt đầu nên một số AP dựa trên mã lombok không chạy như mong đợi. Đây là một nguồn đau đớn lớn đối với tôi khi sử dụng mapitectt và delombok-ing không phải là một lựa chọn hữu ích vì nó phá hủy số dòng của bạn trong nhật ký.

Cuối cùng tôi đã hack một tập lệnh xây dựng để làm việc với cả lombok và mapitectt. Nhưng tôi muốn bỏ lombok do nó bị hack - ít nhất là trong dự án này. Tôi sử dụng lombok mọi lúc trong những thứ khác.

Tôi đã đọc một số ý kiến ​​về Lombok và thực sự tôi đang sử dụng nó trong một số dự án.

Chà, trong lần tiếp xúc đầu tiên với Lombok tôi đã có ấn tượng xấu. Sau vài tuần, tôi bắt đầu thích nó. Nhưng sau vài tháng, tôi phát hiện ra rất nhiều vấn đề nhỏ khi sử dụng nó. Vì vậy, ấn tượng cuối cùng của tôi về Lombok không quá tích cực.

Lý do của tôi để suy nghĩ theo cách này:

• IDE phụ thuộc plugin . Hỗ trợ IDE cho Lombok là thông qua các plugin. Ngay cả khi hoạt động tốt trong hầu hết thời gian, bạn luôn là con tin từ các plugin này được duy trì trong các phiên bản tương lai của IDE và thậm chí phiên bản ngôn ngữ (Java 10+ sẽ đẩy nhanh sự phát triển của ngôn ngữ). Ví dụ: tôi đã cố cập nhật từ Intellij IDEA 2017.3 đến 2018.1 và tôi không thể làm điều đó vì có một số vấn đề trên phiên bản plugin lombok thực tế và tôi cần đợi plugin được cập nhật ... Đây cũng là một vấn đề nếu bạn muốn sử dụng một IDE thay thế khác không có bất kỳ hỗ trợ plugin Lombok nào.
• Vấn đề 'Tìm tập quán'. . Sử dụng Lombok, bạn không thấy các phương thức getter, setter, constructor, builder được tạo và v.v. cho lớp sở hữu phương thức ẩn này.
• Dễ dàng đến mức các nhà phát triển không quan tâm đến việc phá vỡ đóng gói . Tôi biết rằng đó không thực sự là vấn đề từ Lombok. Nhưng tôi đã thấy một xu hướng lớn hơn từ các nhà phát triển là không kiểm soát nữa phương thức nào cần phải được nhìn thấy hay không. Vì vậy, nhiều lần họ chỉ sao chép và dán @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructorkhối chú thích mà không nghĩ phương thức nào mà lớp thực sự cần phải được đưa ra.
• Quan sát người xây dựng ©. Tôi đã phát minh ra cái tên này (xuống xe, Martin Fowler). Nói đùa, Builder rất dễ tạo ra nên ngay cả khi một lớp chỉ có hai tham số, các nhà phát triển thích sử dụng @Builderthay vì constructor hoặc phương thức constructor tĩnh. Đôi khi, họ thậm chí còn cố gắng tạo một Builder bên trong Builder lombok, tạo ra những tình huống kỳ lạ như thế MyClass.builder().name("Name").build().create().
• Rào cản khi tái cấu trúc . Nếu bạn đang sử dụng, ví dụ, a @AllArgsConstructorvà cần thêm một tham số trên hàm tạo, IDE không thể giúp bạn thêm tham số bổ sung này ở tất cả các vị trí (chủ yếu là các bài kiểm tra) đang khởi tạo lớp.
• Trộn Lombok với phương pháp bê tông . Bạn không thể sử dụng Lombok trong tất cả các kịch bản để tạo getter / setter / etc. Vì vậy, bạn sẽ thấy hai cách tiếp cận này được trộn lẫn trong mã của bạn. Bạn đã quen với điều này sau một thời gian, nhưng cảm thấy như bị hack ngôn ngữ.

Giống như một câu trả lời khác đã nói, nếu bạn tức giận về tính dài dòng của Java và sử dụng Lombok để đối phó với nó, hãy thử dùng Kotlin.

Có những rủi ro bảo trì dài hạn là tốt. Đầu tiên, tôi khuyên bạn nên đọc về cách Lombok thực sự hoạt động, ví dụ như một số câu trả lời từ các nhà phát triển của nó ở đây .

Trang web chính thức cũng chứa một danh sách các nhược điểm , bao gồm cả trích dẫn này từ Reinier Zwitserloot:

Đó là một hack hoàn toàn. Sử dụng API không công khai. Truyền giả định (biết rằng bộ xử lý chú thích đang chạy trong javac sẽ nhận được một phiên bản của JavacAnnotationProcessor, đây là triển khai bên trong của AnnotationProcessor (một giao diện), do đó tình cờ có một vài phương thức bổ sung được sử dụng để có được AST trực tiếp) .

Về nhật thực, nó còn tệ hơn (và mạnh mẽ hơn) - một tác nhân java được sử dụng để tiêm mã vào lớp ngữ pháp và trình phân tích cú pháp nhật thực, tất nhiên là API hoàn toàn không công khai và hoàn toàn vượt quá giới hạn.

Nếu bạn có thể làm những gì lombok làm với API tiêu chuẩn, tôi sẽ làm theo cách đó, nhưng bạn không thể. Tuy nhiên, với giá trị của nó, tôi đã phát triển plugin nhật thực cho nhật thực v3 chạy trên java 1.6 và không thực hiện bất kỳ thay đổi nào khi nó hoạt động trên nhật thực v3.4 chạy trên java 1.5, vì vậy nó không hoàn toàn dễ vỡ.

Tóm lại, trong khi Lombok có thể giúp bạn tiết kiệm thời gian phát triển, nếu có một bản cập nhật javac không tương thích ngược (ví dụ: giảm thiểu lỗ hổng) Lombok có thể khiến bạn bị mắc kẹt với một phiên bản Java cũ trong khi các nhà phát triển tranh giành để cập nhật việc sử dụng chúng. API nội bộ. Cho dù đây là một rủi ro nghiêm trọng rõ ràng phụ thuộc vào dự án.

Tôi biết tôi đến muộn, nhưng tôi không thể cưỡng lại sự cám dỗ: bất kỳ ai thích Lombok cũng nên xem Scala. Nhiều ý tưởng hay mà bạn tìm thấy ở Lombok là một phần của ngôn ngữ Scala.

Về câu hỏi của bạn: chắc chắn sẽ dễ dàng hơn để khiến các nhà phát triển của bạn dùng thử Lombok so với Scala. Hãy dùng thử và nếu họ thích, hãy thử Scala.

Cũng như từ chối trách nhiệm: Tôi cũng thích Java!

Tôi đã sử dụng Lombok trong hầu hết các dự án của mình trong một năm nhưng không may xóa nó. Ban đầu, đó là một cách phát triển rất trong sạch nhưng việc thiết lập môi trường phát triển cho các thành viên nhóm mới không phải là điều dễ dàng và đơn giản. Khi nó trở nên đau đầu, tôi mới gỡ nó ra. Nhưng đó là một công việc tốt và cần một số đơn giản hơn để thiết lập.

Khi tôi trình bày dự án cho nhóm của mình, sự nhiệt tình rất cao, vì vậy tôi nghĩ bạn không nên sợ phản ứng của đội.

• Theo như ROI, nó là một tích hợp để tích hợp và không yêu cầu thay đổi mã ở dạng cơ bản. (chỉ cần thêm một chú thích vào lớp của bạn)

• Và cuối cùng, nếu bạn thay đổi ý định, bạn có thể chạy chương trình mở rộng hoặc để IDE của bạn tạo ra các setters, getters và ctor này (mà tôi nghĩ sẽ không ai yêu cầu khi họ thấy pojo của bạn trở nên rõ ràng như thế nào)

Tôi nghĩ rằng Lombok là nó chỉ cung cấp các phím tắt để viết mã Java.
Khi nói đến việc sử dụng các phím tắt để viết mã Java mã hóa, tôi sẽ dựa vào các tính năng như vậy được cung cấp bởi IDE - như trong Eclipse, chúng ta có thể vào menu Nguồn> Tạo Getters và Setters để tạo getters và setters.
Tôi sẽ không dựa vào một thư viện như Lombok cho việc này:

1. Nó gây ô nhiễm mã của bạn với một lớp cú pháp thay thế (đọc @Getter,@Setter vv chú thích). Thay vì học một cú pháp thay thế cho Java, tôi sẽ chuyển sang bất kỳ ngôn ngữ nào khác vốn cung cấp cú pháp giống như Lombok.
2. Lombok yêu cầu sử dụng IDE hỗ trợ Lombok để làm việc với mã của bạn. Sự phụ thuộc này gây ra rủi ro đáng kể cho bất kỳ dự án không tầm thường nào. Dự án Lombok nguồn mở có đủ tài nguyên để tiếp tục cung cấp hỗ trợ cho các phiên bản khác nhau của một loạt các Java IDE có sẵn không?
3. Dự án Lombok nguồn mở có đủ tài nguyên để tiếp tục cung cấp hỗ trợ cho các phiên bản Java mới hơn sẽ đến trong tương lai không?
4. Tôi cũng cảm thấy lo lắng rằng Lombok có thể giới thiệu các vấn đề tương thích với các khung / thư viện được sử dụng rộng rãi (như Spring, Hibernate, Jackson, JUnit, Mockito) hoạt động với mã byte của bạn khi chạy.

Nói chung, tôi không thích "thêm gia vị" cho Java của mình với Lombok.

Muốn sử dụng lombok @ToStringnhưng sớm gặp phải các lỗi biên dịch ngẫu nhiên khi xây dựng lại dự án trong Intellij IDEA. Phải nhấn biên dịch nhiều lần trước khi biên dịch gia tăng có thể hoàn thành với thành công.

Đã thử cả lombok 1.12.2 và 0.9.3 với Intellij IDEA 12.1.6 và 13.0 mà không có bất kỳ plugin lombok nào dưới jdk 1.6.0_39 và 1.6.0_45.

Phải sao chép thủ công các phương thức được tạo từ nguồn delomboked và giữ lombok cho đến khi thời gian tốt hơn.

Cập nhật

Vấn đề chỉ xảy ra với kích hoạt biên dịch song song.

Đã gửi một vấn đề: https://github.com/rzwitserloot/lombok/issues/648

Cập nhật

mplushnikov đã nhận xét vào ngày 30 tháng 1 năm 2016:

Phiên bản mới hơn của Intellij không còn gặp phải vấn đề như vậy nữa. Tôi nghĩ rằng nó có thể được đóng lại ở đây.

Cập nhật

Tôi thực sự khuyên bạn nên chuyển từ Java + Lombok sang Kotlin nếu có thể. Vì nó đã được giải quyết từ đầu, tất cả các vấn đề Java mà Lombok cố gắng giải quyết.

Tôi đã gặp sự cố với Lombok và Jackson CSV , khi tôi sắp xếp đối tượng của mình (java bean) vào một tệp CSV, các cột được sao chép, sau đó tôi đã xóa chú thích @Data của Lombok và việc sắp xếp theo thứ tự hoạt động tốt.

Tôi không khuyên bạn nên nó. Tôi đã từng sử dụng nó, nhưng sau đó khi tôi làm việc với NetBeans 7.4, nó đã làm rối mã của tôi. Tôi phải xóa lombok trong tất cả các tệp trong các dự án của mình. Có delombok, nhưng làm thế nào tôi có thể chắc chắn rằng nó sẽ không làm hỏng mã của tôi. Tôi phải dành nhiều ngày chỉ để loại bỏ lombok và trở lại các kiểu Java thông thường. Tôi chỉ quá cay ...

Tôi chưa thử sử dụng Lombok - nó là / tiếp theo trong danh sách của tôi, nhưng có vẻ như Java 8 đã gây ra vấn đề đáng kể cho nó và công việc khắc phục vẫn đang được tiến hành như một tuần trước. Nguồn của tôi cho điều đó là https://code.google.com.vn/p/projectlombok/issues/detail?id=451 .