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

Project Lombok 을 모르는 경우 주석을 사용 하여 getter 및 setter를 생성하거나 @Data를 사용하여 생성하는 것과 같은 간단한 JavaBean을 생성 하는 등 Java의 성가신 문제를 해결하는 데 도움이됩니다 . 게터로 구성하고 숨겨야하는 최대 7 개의 서로 다른 필드가있는 50 개의 서로 다른 이벤트 객체에서 실제로 도움이 될 수 있습니다. 이것으로 거의 수천 줄의 코드를 제거 할 수 있습니다.

그러나 장기적으로는 유감스러운 결정이 될 것이라 걱정됩니다. 화염 전은##Java Freenode내가 언급 할 때 채널 것이고, 코드 스 니펫을 제공하면 가능한 도우미를 혼란스럽게 할 것이고 사람들은 JavaDoc이 누락되었다고 불평 할 것이며 미래의 커미터는 어쨌든 그것을 제거 할 수 있습니다. 나는 정말 긍정적 인 것을 즐길 것이지만, 나는 부정적인 것에 대해 걱정하고 있습니다.

따라서 : 크든 작든 큰 프로젝트에서 롬복을 사용하는 것이 안전합니까? 긍정적 인 효과는 부정적인 가치가 있습니까?

Project Lombok이 제안 된 새 프로젝트에 대해 상당한 기술적 이점을 제공한다고 이미 결정한 것 같습니다. (처음부터 명확하게하기 위해 Project Lombok에 대한 특정 관점이 없습니다.)

일부 프로젝트 (오픈 소스 또는 기타 현명한 프로젝트)에서 Project Lombok (또는 다른 게임 변경 기술)을 사용하기 전에 프로젝트 스테이크 소유자가 이에 동의하는지 확인해야합니다. 여기에는 개발자 및 중요한 사용자 (예 : 공식 또는 비공식 스폰서)가 포함됩니다.

다음과 같은 잠재적 인 문제를 언급했습니다.

내가 언급하면 ​​## Java Freenode 채널에서 Flamewars가 폭발합니다.

쉬운. 화염 전쟁에 참여하거나 무시하지 말거나 단순히 롬복에 대한 언급을 삼가십시오.

코드 스 니펫을 제공하면 가능한 도우미를 혼란스럽게 할 것입니다.

프로젝트 전략이 Lombok을 사용하는 경우 가능한 도우미가 익숙해 져야합니다.

사람들은 JavaDoc 누락에 대해 불평 할 것입니다.

그것이 그들의 문제입니다. 올바른 생각에 조직의 소스 코드 / 문서 규칙을 타사 오픈 소스 소프트웨어에 엄격하게 적용하려는 사람은 없습니다. 프로젝트 팀은 사용중인 기술에 적합한 프로젝트 소스 코드 / 문서 표준을 자유롭게 설정할 수 있어야합니다.

( FOLLOWUP -Lombok 개발자는 합성 된 getter 및 setter 메소드에 대해 javadoc 주석을 생성하지 않는 것이 문제라는 것을 알고 있습니다. 이것이 프로젝트의 주요 문제인 경우, 하나의 대안은이를 해결하기 위해 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 "패치"업데이트에서 주요 변경 사항이 어떻게 발생하는지 잘 모르겠습니다. 패치 버전을 자동 업데이트하는 도구를 사용하는 경우 문제가 될 수 있습니다.

계속해서 Lombok을 사용하십시오. 필요한 경우 나중에 코드를 "delombok" http://projectlombok.org/features/delombok.html

개인적으로 (따라서 주관적으로) 롬복을 사용하면 해시 코드 및 등의 복잡한 메소드의 IDE / 자체 구현과 비교할 때 달성하려는 것에 대해 코드를보다 표현력있게 만듭니다.

사용할 때

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

IDE / 자체 구현보다 Equals & HashCode를 일관성있게 유지하고 평가되는 필드를 추적하는 것이 훨씬 쉽습니다. 필드를 정기적으로 추가 / 제거 할 때 특히 그렇습니다.

@ToString포함 / 제외 된 필드, 게터 사용 또는 필드 액세스 및 호출 여부에 관한 원하는 동작을 명확하게 전달 하는 주석 및 해당 매개 변수도 마찬가지 super.toString()입니다.

그리고 다시와 전체 클래스를 주석에 의해 @Getter또는 @Setter(AccessLevel.NONE)이 메소드는 필드에 사용할 수 있습니다 무엇 즉시 분명하다 (그리고 선택적으로 어떤 분기 메소드를 오버라이드 (override)).

계속해서 혜택이 ..

제 생각에는 코드를 줄이는 것이 아니라 Javadoc 또는 구현에서 코드를 파악하지 않고 달성하려는 것을 명확하게 전달하는 것입니다. 축소 된 코드는 다양한 방법 구현을보다 쉽게 ​​발견 할 수있게합니다.

롬복은 훌륭하지만 ...

롬복은 새로운 소스 파일을 생성하지 않기 때문에 주석 처리 규칙을 어 깁니다. 즉, getter / setter 또는 기타 다른 항목이있을 것으로 예상되는 경우 다른 주석 프로세서와 함께 사용할 수 없습니다.

주석 처리는 일련의 라운드에서 실행됩니다. 각 라운드에서 각 라운드마다 차례가 나옵니다. 라운드가 완료된 후 새로운 Java 파일이 발견되면 다른 라운드가 시작됩니다. 이런 식으로 주석 프로세서의 순서는 새 파일 만 생성하더라도 중요하지 않습니다. lombok은 새로운 파일을 생성하지 않기 때문에 새로운 라운드가 시작되지 않으므로 lombok 코드에 의존하는 일부 AP가 예상대로 실행되지 않습니다. mapstruct를 사용하는 동안 이것은 큰 고통의 원천이었고 delombok-ing은 로그의 줄 번호를 파괴하기 때문에 유용한 옵션이 아닙니다.

나는 결국 lombok과 mapstruct 모두에서 작동하도록 빌드 스크립트를 해킹했습니다. 그러나 나는이 프로젝트에서 최소한 해키가 있기 때문에 롬복을 떨어 뜨리고 싶습니다. 나는 다른 물건에 항상 롬복을 사용합니다.

롬복에 대한 의견을 읽고 실제로 일부 프로젝트에서 사용하고 있습니다.

글쎄, 롬복과의 첫 접촉에서 나는 나쁜 인상을 받았습니다. 몇 주 후, 나는 그것을 좋아하기 시작했다. 그러나 몇 달 후에 나는 그것을 사용하여 많은 작은 문제를 알아 냈습니다. 롬복에 대한 나의 마지막 인상은 그리 긍정적이지 않습니다.

이런 식으로 생각해야하는 나의 이유 :

• IDE 플러그인 의존성 . 롬복에 대한 IDE 지원은 플러그인을 통해 이루어집니다. 대부분의 시간 동안 잘 작동하더라도, IDE의 향후 릴리스 및 언어 버전 (Java 10+는 언어 개발을 가속화 할 것임) 에서 항상이 플러그인의 인질로 유지됩니다 . 예를 들어 Intellij IDEA 2017.3에서 2018.1로 업데이트하려고 시도했지만 실제 lombok 플러그인 버전에 문제가 있었고 플러그인이 업데이트 될 때까지 기다려야했기 때문에 업데이트 할 수 없었습니다. 롬복 플러그인을 지원하지 않는 대체 IDE를 사용하고 싶습니다.
• '사용법 찾기'문제. . Lombok을 사용하면 생성 된 getter, setter, 생성자, 빌더 메소드 등이 표시되지 않습니다. 따라서 IDE에서 프로젝트에서 이러한 메소드가 사용되는 위치를 찾으려면 이 숨겨진 메소드를 소유 한 클래스의 경우
• 개발자가 캡슐화를 깨뜨리지 않아도되기 쉽습니다 . 나는 그것이 롬복의 문제가 아니라는 것을 안다. 그러나 개발자가 더 이상 어떤 방법을보아야하는지 제어하지 않는 경향이 커졌습니다. 따라서 여러 번 @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructor클래스가 실제로 노출 해야하는 메소드를 생각하지 않고 주석 블록을 복사하여 붙여 넣는 경우가 많습니다 .
• 빌더 집착 ©. 나는이 이름을 발명했다 (하차, Martin Fowler). 놀랍게도 빌더는 작성하기가 너무 쉬워 클래스에 두 개의 매개 변수 만있는 경우에도 개발자 @Builder가 생성자 또는 정적 생성자 메소드 대신 사용하는 것을 선호합니다 . 때때로 그들은 심지어 롬복 빌더 내부에 빌더를 만들려고 시도하여 이상한 상황을 만듭니다 MyClass.builder().name("Name").build().create().
• 리팩토링시 장벽 . 예를 들어 a를 사용 @AllArgsConstructor중이고 생성자에 하나 이상의 매개 변수를 추가해야하는 경우 IDE는 클래스를 인스턴스화하는 모든 위치 (주로 테스트)에이 추가 매개 변수를 추가하는 데 도움을 줄 수 없습니다.
• 구체적인 방법으로 롬복 혼합 . 모든 시나리오에서 Lombok을 사용하여 getter / setter / etc를 만들 수는 없습니다. 따라서이 두 가지 접근 방식이 코드에 혼합되어 표시됩니다. 당신은 얼마 후 이것에 익숙해 지지만 언어에 대한 해킹처럼 느껴집니다.

다른 답변에서와 같이 Java 상세 정보에 대해 화를 내고 Lombok을 사용하여 처리하는 경우 Kotlin을 사용해보십시오.

장기적인 유지 관리 위험도 있습니다. 첫째, 나는 예를 들면 그 개발자의 일부 답변, 롬복이 실제로 어떻게 작동하는지에 대해 읽어 보시기 바랍니다 것 여기 .

공식 사이트에는 Reinier Zwitserloot의 인용문을 포함하여 단점 목록 도 포함되어 있습니다 .

완전 해킹입니다. 비공개 API 사용 예상치 못한 캐스팅 (javac에서 실행되는 주석 프로세서가 AncationProcessor (인터페이스)의 내부 구현 인 JavacAnnotationProcessor의 인스턴스를 가져 오므로 라이브 AST에 액세스하는 데 사용되는 몇 가지 추가 메소드가 있음) .

일식에서는 논란의 여지가 있지만 더 강력합니다. Java 문법은 일식 문법 및 파서 클래스에 코드를 삽입하는 데 사용됩니다.

롬복이 표준 API로 할 수 있다면 그렇게 할 수는 있지만 그렇게 할 수는 없습니다. 여전히 가치가 있기 때문에 java 1.6에서 실행되는 이클립스 v3.5 용 이클립스 플러그인을 개발했으며 Java 1.5에서도 실행되는 이클립스 v3.4에서 변경하지 않았으므로 완전히 취약하지는 않습니다.

요약하자면, 이전 버전과 호환되지 않는 javac 업데이트 (예 : 취약성 완화)가있는 경우 롬복이 개발 시간을 절약 할 수 있지만 롬복은 개발자가 이전 버전의 Java를 사용하지 못하게하는 동안 개발자는 해당 버전의 사용법을 업데이트하려고합니다. 내부 API. 이것이 심각한 위험인지 여부는 분명히 프로젝트에 달려 있습니다.

늦었다는 것을 알고는 유혹에 저항 할 수 없습니다. 롬복을 좋아하는 사람은 누구나 스칼라를 봐야합니다. 롬복에서 찾을 수있는 많은 좋은 아이디어는 스칼라 언어의 일부입니다.

귀하의 질문에 : 개발자가 Scala보다 Lombok을 사용하는 것이 훨씬 쉽습니다. 시도해보고 마음에 들면 스칼라를 사용해보십시오.

면책 조항과 마찬가지로 : 나는 Java도 좋아합니다!

거의 1 년 동안 거의 모든 프로젝트에서 Lombok을 사용했지만 불행히도 제거했습니다. 처음에는 매우 깨끗한 개발 방법 이었지만 새로운 팀 구성원을위한 개발 환경을 설정하는 것은 매우 쉽고 간단하지 않습니다. 그것이 두통이되었을 때 방금 그것을 제거했습니다. 그러나 그것은 좋은 일이며 설정에 더 단순성이 필요합니다.

팀에 프로젝트를 보여 주었을 때 열정이 높았으므로 팀 응답을 두려워해서는 안된다고 생각합니다.

• ROI까지는 통합하기가 쉽고 기본 형태로 코드를 변경할 필요가 없습니다. (단지 클래스에 단일 주석을 추가하기 만하면됩니다)

• 마지막으로, 마음이 바뀌면 unlombok을 실행하거나 IDE가 이러한 setter, getter 및 ctor를 만들도록 할 수 있습니다.

롬복에 대한 나의 견해는 단지 bolilerplate Java 코드 작성을위한 지름길을 제공한다는 것입니다.
bolilerplate Java 코드 작성을위한 바로 가기를 사용하는 경우 Eclipse에서와 같이 IDE에서 제공하는 이러한 기능에 의존합니다. 메뉴에서 Getter 및 Setter 생성을 위해 소스> Getter 및 Setter 생성 메뉴로 이동할 수 있습니다.
나는 이것을 위해 롬복과 같은 도서관에 의존하지 않을 것입니다 :

1. 대체 구문의 간접 레이어 (read @Getter,@Setter 등 주석). Java에 대한 대체 구문을 배우는 대신 Lombok과 같은 구문을 기본적으로 제공하는 다른 언어로 전환하려고합니다.
2. 롬복은 코드 작업을 위해 롬복 지원 IDE를 사용해야합니다. 이러한 의존성은 사소한 프로젝트에 상당한 위험을 초래합니다. 오픈 소스 Lombok 프로젝트에 다양한 Java IDE의 다양한 버전을 계속 지원할 수있는 충분한 리소스가 있습니까?
3. 오픈 소스 Lombok 프로젝트에 향후 출시 될 Java의 최신 버전을 계속 지원할 수있는 충분한 리소스가 있습니까?
4. 또한 롬복이 런타임에 바이트 코드와 함께 작동하는 널리 사용되는 프레임 워크 / 라이브러리 (예 : Spring, Hibernate, Jackson, JUnit, Mockito)와의 호환성 문제가 발생할 수 있다는 것에 긴장합니다.

대체로 나는 롬복으로 자바를 "스파이 업"하고 싶지 않다.

롬복을 사용 @ToString하고 싶었지만 Intellij IDEA의 프로젝트 재 구축에서 곧 임의의 컴파일 오류가 발생했습니다. 증분 컴파일이 성공적으로 완료되기 전에 컴파일을 여러 번 수행해야했습니다.

jdk 1.6.0_39 및 1.6.0_45에서 lombok 플러그인없이 Intellij IDEA 12.1.6 및 13.0으로 lombok 1.12.2 및 0.9.3을 모두 시도했습니다.

delomboked 소스에서 생성 된 메소드를 수동으로 복사하고 더 나은 시간까지 롬복을 보류해야했습니다.

최신 정보

병렬 컴파일이 활성화 된 경우에만 문제가 발생합니다.

문제를 제기 : https://github.com/rzwitserloot/lombok/issues/648

최신 정보

mplushnikov는 2016 년 1 월 30 일에 다음과 같이 댓글을 달았습니다.

최신 버전의 Intellij에는 더 이상 그러한 문제가 없습니다. 여기서 닫을 수 있다고 생각합니다.

최신 정보

가능하면 Java + Lombok에서 Kotlin 으로 전환하는 것이 좋습니다 . 처음부터 롬복이 해결하려는 모든 Java 문제를 해결했습니다.

나는 문제가 발생했을 롬복 과 잭슨 CSV 중복 곳 CSV 파일로 내 객체 (자바 빈)을 marshalized, 열, 그때는 롬복의 @Data 주석 및 근무 벌금을 marshalizing를 제거했습니다.

나는 그것을 권장하지 않습니다. 나는 그것을 사용했지만 NetBeans 7.4로 작업 할 때 코드가 엉망이되었습니다. 내 프로젝트의 모든 파일에서 롬복을 제거했습니다. delombok이 있지만 코드를 망치지 않는지 어떻게 알 수 있습니까? 나는 롬복을 제거하고 평범한 자바 스타일로 돌아 가기 위해 며칠을 보냈습니다. 나는 너무 매운 ...

아직 Lombok을 사용해 보지 않았습니다. 다음은 목록에 있었지만 Java 8이 큰 문제를 일으킨 것처럼 들리며 일주일 전까지 치료 작업이 계속 진행되고 있습니다. 그 출처는 https://code.google.com/p/projectlombok/issues/detail?id=451 입니다.