[java] Project Lombok을 사용하는 것이 안전합니까? [닫은]

오늘 롬복을 사용하기 시작했습니다. 지금까지 나는 그것을 좋아하지만 언급하지 않은 한 가지 단점은 리팩토링 지원이었습니다.

로 주석이 달린 클래스가 있으면 @Data필드 이름을 기반으로 게터와 세터가 생성됩니다. 다른 클래스에서 해당 getter 중 하나를 사용하는 경우 필드 이름이 잘못 결정되면 해당 getter 및 setter 사용법을 찾지 않고 이전 이름을 새 이름으로 바꿉니다.

나는 이것이 Lombok이 아닌 IDE 플러그인을 통해 수행되어야한다고 생각할 것입니다.

업데이트 (Jan 22 ’13)
3 개월 동안 롬복을 사용한 후에도 여전히 대부분의 프로젝트에 권장합니다. 그러나 위에 나열된 것과 비슷한 또 다른 단점을 찾았습니다.

클래스가있는 경우 다른 클래스에서 전화 할 때 , say 및로 MyCompoundObject.java주석이 달린 두 멤버가 @Delegate있다고 말하면 클래스를 위임했는지 또는 IDE 내에서 더 이상 소스로 이동할 수 없기 때문에 알 수 없습니다. myWidgetsmyGadgetsmyCompoundObject.getThingies()WidgetGadget

Eclipse “Generate Delegate Methods …”를 사용하면 동일한 기능을 제공하며, 신속하고 소스 점프를 제공합니다. 단점은 중요한 것들에 초점을 맞추는 상용구 코드로 소스를 복잡하게 만드는 것입니다.

업데이트 2 (Feb 26 ’13)
5 개월 후에도 여전히 롬복을 사용하고 있지만 다른 성가심이 있습니다. 선언 된 getter & setter가 없으면 새 코드에 익숙해 지려고 할 때 성 가실 수 있습니다.

예를 들어, 메서드가 호출 getDynamicCols()되었지만 그 기능에 대해 잘 모르는 경우이 메서드의 목적을 결정하기 위해 추가 장애물이 있습니다. 장애물 중 일부는 롬복이고 일부는 롬복 스마트 플러그인이 없습니다. 장애물은 다음과 같습니다.

• JavaDocs 부족. 내가 필드를 javadoc하면 getter와 setter가 Lombok 컴파일 단계를 통해 해당 javadoc을 상속하기를 바랍니다.
• 메소드 정의로 이동하면 클래스로 이동하지만 게터를 생성 한 속성은 아닙니다. 이것은 플러그인 문제입니다.
• 메소드를 생성하거나 코딩하지 않으면 getter / setter에 중단 점을 설정할 수 없습니다.
• 참고 :이 참조 검색은 처음 생각했던 문제가 아닙니다. 그래도 아웃 라인보기를 가능하게하는 관점을 사용해야합니다. 대부분의 개발자에게는 문제가되지 않습니다. 내 문제는 내 Outline보기를 필터링하는 Mylyn을 사용 하고 있었기 때문에 방법을 보지 못했습니다. 참조 부족 검색. 누가 전화하고 있는지 확인하려면 참조 getDynamicCols(args...)를 검색 할 수 있도록 세터를 생성하거나 코딩해야합니다.

업데이트 3 (Mar 7 ’13)
Eclipse에서 다양한 작업을 수행하는 방법을 배우는 것 같아요. 실제로 Lombok 생성 방법에서 조건부 중단 점 (BP)을 설정할 수 있습니다. Outline보기를 사용하여 방법을 마우스 오른쪽 버튼으로 클릭 할 수 있습니다 Toggle Method Breakpoint. 그런 다음 BP에 도달하면 디버깅 Variables보기를 사용하여 생성 된 메소드가 매개 변수의 이름을 지정한 항목 (일반적으로 필드 이름과 동일)을보고 마지막으로 Breakpoints보기를 사용 하여 BP를 마우스 오른쪽 단추로 클릭하고 Breakpoint Properties...조건을 추가하도록 선택하십시오 . 좋은.

업데이트 4 (Aug 16 ’13)
Netbeans은 Maven pom에서 Lombok 종속성을 업데이트 할 때 좋아하지 않습니다. 프로젝트는 여전히 컴파일되지만 파일은 Lombok이 생성하는 방법을 볼 수 없기 때문에 컴파일 오류가 발생하는 것으로 표시됩니다. Netbeans 캐시를 지우면 문제가 해결됩니다. Eclipse에 “Clean Project”옵션이 있는지 확실하지 않습니다. 사소한 문제이지만 알기를 원했습니다.

업데이트 5 (Jan 17 ’14)
롬복은 항상 Groovy 또는 적어도 groovy-eclipse-compiler. 컴파일러 버전을 다운 그레이드해야 할 수도 있습니다.
메이븐 그루비와 자바 + 롬복

업데이트 6 (Jun 26 ’14)
경고의 한마디. 롬복은 약간 중독성이 있으며 어떤 이유로 사용할 수없는 프로젝트에서 작업하면 화나게합니다. 전혀 사용하지 않는 것이 좋습니다.

업데이트 7 (Jul 23 ’14)
이것은 업데이트를 직접 해결하기 때문에 약간 흥미로운 업데이트입니다. OP가 요구 한 롬복 채택 안전 을 입니다.

v1.14부터 @Delegate주석이 실험 상태로 강등되었습니다. 자세한 내용은 해당 사이트에 문서화되어 있습니다 ( Lombok Delegate Docs ) .

문제는이 기능을 사용하는 경우 취소 옵션이 제한되어 있다는 것입니다. 옵션은 다음과 같습니다.

• 수동 제거 @Delegate주석을 하고 델리게이트 코드를 생성 / 핸드 코드하십시오. 주석 내에서 속성을 사용하는 경우 조금 더 어려워집니다.
• 파일이있는 Delombok @Delegate 원하는 주석에 다시 추가하십시오.
• 롬복을 업데이트하거나 포크를 유지하지 마십시오 (또는 체험 기능을 사용하여 라이브).
• 전체 프로젝트를 Delombok하고 Lombok 사용을 중지하십시오.

내가 알 수 있는 한 Delombok에는 주석의 하위 집합을 제거 할 수있는 옵션이 없습니다 . 적어도 단일 파일의 맥락에서 전부 또는 아무것도 아닙니다. 이 기능을 요청하기 위해 티켓을 열었습니다Delombok 플래그를 사용하여이 지만 가까운 시일 내에이를 기대하지는 않습니다.

업데이트 8 (Oct 20 ’14)
만약 그것이 당신을위한 옵션이라면, Groovy는 롬복의 동일한 혜택과 @Delegate를 포함한 다른 기능의 보트로드를 제공합니다 . 아이디어를 권력에 판매하는 데 어려움을 겪고 있다고 생각되는 경우 @CompileStatic또는 @TypeChecked주석을 살펴보면 그 원인이 도움이 될 수 있는지 확인하십시오. 사실, Groovy 2.0 릴리즈의 주요 초점은 정적 안전 입니다.

업데이트 9 (Sep 1 ’15)
롬복은 여전히 적극적으로 유지 관리되고 개선 되어 안전 채택 수준에 잘 맞습니다. @Builder의 주석 내가 제일 좋아하는 새로운 기능 중 하나입니다.

업데이트 10 (Nov 17 ’15)
이것은 OP의 질문과 직접적으로 관련이 없지만 공유 가치가있는 것처럼 보일 수 있습니다. 작성하는 상용구 코드의 양을 줄이는 데 도움이되는 도구를 찾고 있다면 Google Auto- 특히 AutoValue를 확인하십시오 . 슬라이드 데크 를 살펴보면 Lombok을 해결하려는 문제에 대한 가능한 솔루션으로 나열하십시오. 그들이 롬복에 대해 나열한 단점은 다음과 같습니다.

• 삽입 된 코드는 보이지 않습니다 (생성하는 메소드를 “볼”수 없음) [주-실제로 가능하지만 디 컴파일러 만 필요]
• 컴파일러 핵은 표준이 아니며 깨지기 쉽다
• “우리의 견해로는 귀하의 코드는 더 이상 자바가 아닙니다”

그들의 평가에 얼마나 동의하는지 잘 모르겠습니다. 그리고 슬라이드에 문서화 된 AutoValue의 단점을 감안할 때 Groovey가 옵션이 아닌 경우 Lombok을 고수 할 것입니다.

업데이트 11 (Feb 8 ’16) Spring Roo 에 비슷한 주석 이
있음을 알았습니다 . Roo가 여전히 문제가되고 주석에 대한 문서를 찾는 것이 약간 거칠다는 것을 알고 약간 놀랐습니다. 제거는 탈 롬복만큼 쉬운 것처럼 보이지 않습니다. 롬복이 더 안전한 선택 인 것 같습니다.

업데이트 12 (Feb 17 ’16)
현재 진행중인 프로젝트에 롬복을 가져 오는 것이 안전한 이유에 대한 정당성을 제시하려고 시도하면서 추가 된 금 조각을 찾았습니다 v1.14– 구성 시스템 ! 즉, 팀이 안전하지 않거나 바람직하지 않은 것으로 판단되는 특정 기능을 허용하지 않도록 프로젝트를 구성 할 수 있습니다. 또한 다른 설정으로 디렉토리 특정 구성을 작성할 수도 있습니다. 이것은 굉장합니다.

업데이트 13 (Oct 4 ’16)
이런 종류의 일이 당신에게 중요하다면 Oliver Gierke 는 Spring Data Rest에 Lombok을 추가 하는 것이 안전하다고 생각했습니다 .

업데이트 14 (Sep 26 ’17) OPs 질문에 대한 의견에서 @gavenkoa 가
지적했듯이 JDK9 컴파일러 지원은 아직 사용할 수 없습니다 (문제 # 985). 또한 롬복 팀이 쉽게 해결할 수없는 것처럼 들립니다.

업데이트 15 (Mar 26 ’18)
롬복 변경 기록은 v1.16.20부터 ” # 985 가 여전히 열려 있어도 JDK1.9에서 롬복 컴파일이 가능합니다 “를 나타냅니다 .

그러나 JDK9를 수용하기 위해 변경하려면 몇 가지 주요 변경이 필요했습니다. 모두 구성 기본값의 변경으로 분리됩니다. 그것들이 주요 변경 사항을 도입 한 것에 관한 약간의 문제이지만 버전은 “증분”버전 번호 (v1.16.18에서 v1.16.20으로 이동) 만 충돌했습니다. 이 게시물은 안전에 관한 yarn/npm것이기 때문에 최신 증분 버전으로 자동 업그레이드 하는 유사한 빌드 시스템이 있다면 무례한 깨어날 수 있습니다.

업데이트 16 (Jan 9 ’19)

JDK9 문제가 해결 된 것 같고 Lombok은 JDK10 및 JDK11과 함께 작동합니다.

안전 측면과 관련하여 알았지 만 한 가지 주목할 점은 v1.18.2에서 v1.18.4로 변경 로그가 BREAKING CHANGE!? semver “패치”업데이트에서 주요 변경 사항이 어떻게 발생하는지 잘 모르겠습니다. 패치 버전을 자동 업데이트하는 도구를 사용하는 경우 문제가 될 수 있습니다.

답변

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