Project Lombok을 사용해도 안전한가요?

Project Lombok을 사용해도 안전한가요?

닫았습니다. 이 질문은의견 기반의현재 답변을 받고 있지 않습니다.

---

이 질문을 개선하시겠습니까?이 게시물을 편집하여 사실과 인용문으로 답변할 수 있도록 질문을 업데이트하십시오.

4년 전에 문을 닫았어요

이 질문을 개선하다

Project Lombok은 주석으로 getters와 setters를 생성하고 @Data로 간단한 JavaBean을 생성하는 등의 Java의 골칫거리 중 일부를 지원합니다.특히 getter로 구성하고 숨겨야 하는 필드가 최대 7개 있는 50개의 이벤트 개체에서 도움이 됩니다.이걸로 거의 천 줄의 코드를 제거할 수 있어요.

하지만 장기적으로 보면 후회스러운 결정이 되지 않을까 걱정입니다.화염 화력이 폭발할 것입니다.##Java Freenode내가 언급했을 때, 코드 스니펫을 제공하면 가능한 도우미들을 혼란스럽게 하고, 사람들은 JavaDoc을 놓쳤다고 불평할 것이고, 미래의 커밋은 어쨌든 모든 것을 제거할 것이다.저는 긍정적인 면을 정말 즐기고 싶지만 부정적인 면이 걱정됩니다.

그래서: Lombok을 사용하는 것은 작은 프로젝트든 큰 프로젝트든 안전한가요?긍정적인 효과가 부정적인 효과의 가치가 있는가?

오늘부터 롬복 사용을 시작했습니다.지금까지는 마음에 들지만, 제가 보지 못한 단점 중 하나는 리팩터링 서포트입니다.

주석이 달린 클래스가 있는 경우@Data필드명을 기반으로 getters와 setters가 생성됩니다.다른 클래스에서 이러한 getter 중 하나를 사용하는 경우 필드의 이름이 잘못 지정되면 해당 getter 및 setter의 용도가 검색되지 않고 이전 이름이 새 이름으로 바뀝니다.

이 작업은 롬복이 아닌 IDE 플러그인을 통해 수행되어야 한다고 생각합니다.

업데이트 (2013년 1월 22일)
롬복 3개월을 사용해도 대부분의 프로젝트에서 여전히 추천합니다.하지만 위와 유사한 단점을 하나 더 발견했습니다.

수업이 있다면, 이렇게 말하세요.MyCompoundObject.java2명의 멤버가 있으며, 둘 다 코멘트가 붙어 있습니다.@Delegate,말합니다myWidgets그리고.myGadgets, 당신이 전화할 때myCompoundObject.getThingies()다른 클래스로부터, 그것이 위임을 받고 있는지 아닌지는 알 수 없다.Widget또는Gadget더 이상 IDE 내에서 소스로 이동할 수 없기 때문입니다.

이클립스 "대표 메서드 생성"을 사용합니다.」는, 같은 기능을 제공.빠른 속도와 소스 점핑 기능을 제공합니다.단점은 중요한 것에 초점을 맞추는 보일러 플레이트 코드로 소스를 혼란스럽게 만든다는 것입니다.

업데이트 2 (2013년 2월 26일)
5개월이 지난 지금도 롬복을 사용하고 있습니다만, 다른 불편함이 있습니다.새로운 코드에 익숙해지려고 할 때 선언된 getter와 setter가 부족하면 짜증이 날 수 있습니다.

예를 들어 다음과 같은 메서드가 있는 경우getDynamicCols()무슨 일인지 모르겠지만 이 방법의 목적을 결정하려면 몇 가지 장애물을 뛰어넘어야 해요장애물의 일부는 롬복이고, 일부는 롬복 스마트 플러그인의 부족이다.장애물은 다음과 같습니다.

• Java Docs가 없습니다.필드를 javadoc하면 getter와 setter가 Lombok 컴파일 단계를 통해 javadoc을 상속받기를 바랍니다.
• 메서드 정의로 건너뛰면 클래스로 이동하지만 getter를 생성한 속성은 이동하지 않습니다.이것은 플러그인의 문제입니다.
• 메서드를 생성하거나 코드화하지 않으면 getter/setter에서 브레이크 포인트를 설정할 수 없습니다.
• 메모: 이 참조 검색은 처음에 생각했던 것과 같은 문제가 아닙니다.그러나 아웃라인 보기를 사용할 수 있는 관점을 사용해야 합니다.대부분의 개발자들에게는 문제가 되지 않습니다.내 문제는 Mylyn을 사용하고 있다는 것이다. Mylyn은 내 Filter를 필터링하고 있었다.Outline보기 때문에 방법을 못 봤어요.참조 검색이 없습니다. 발신자를 확인하려면 , 참조를 검색할 수 있도록 설정기를 생성하거나 코드화할 필요가 있습니다.

업데이트 3 (2013년 3월 7일)
이클립스에서 다양한 방법을 배우는 것 같아요.실제로 Lombok 생성 메서드에서 조건부 브레이크 포인트(BP)를 설정할 수 있습니다.사용방법Outline뷰에서 마우스 오른쪽 버튼을 클릭하여Toggle Method Breakpoint그런 다음 BP를 누르면 디버깅을 사용할 수 있습니다.Variables생성된 메서드가 매개 변수(일반적으로 필드 이름과 동일)에 어떤 이름을 지정했는지 확인하고 마지막으로Breakpoints뷰에서 BP를 우클릭하고Breakpoint Properties...조건을 추가합니다.좋아.

업데이트 4 (2013년 8월 16일)
Netbeans는 Maven pom에서 롬복 의존관계를 갱신하는 것을 좋아하지 않습니다.프로젝트는 아직 컴파일되지만, Lombok이 작성하는 메서드를 볼 수 없기 때문에 파일에 컴파일 오류가 있다는 플래그가 붙습니다.Netbeans 캐시를 클리어하면 문제가 해결된다.Eclipse와 같은 "Clean Project" 옵션이 있는지 확실하지 않습니다.사소한 문제지만 알려주고 싶었어요

업데이트 5 (2014년 1월 17일)
롬복이가 그루비랑 항상 잘 놀아주진 않아, 적어도 걔네랑 잘 놀아주진 않아.groovy-eclipse-compiler. 컴파일러 버전을 다운그레이드해야 할 수 있습니다.메이븐 그루비 및 자바 + 롬복

업데이트 6 (2014년 6월 26일)
경고 한 마디.Lombok은 약간 중독성이 있어서 어떤 이유로 사용할 수 없는 프로젝트를 진행하면 짜증이 날 것이다.아예 안 쓰는 게 나을 수도 있어요.

업데이트 7 (Jul 23'14)
이는 OP가 요청한 롬복 채택의 안전성에 대해 직접 언급하고 있기 때문에 다소 흥미로운 업데이트입니다.

v1.14의 시점에서@Delegate주석이 실험 상태로 강등되었습니다.자세한 내용은 해당 사이트(Lombok 위임 문서)에 기재되어 있습니다.

이 기능을 사용하고 있는 경우는, 백아웃 옵션이 한정되어 있습니다.옵션은 다음과 같습니다.

• 수동으로 삭제@Delegate주석 및 대리자 코드 생성/핸드코딩을 수행합니다.주석 내에서 속성을 사용하는 경우 이 작업은 조금 더 어렵습니다.
• Delombok이 있는 파일을@Delegate원하는 주석을 다시 추가할 수도 있습니다.
• Lombok을 업데이트하거나 포크를 유지(또는 경험적 기능을 사용하여 생활)하지 마십시오.
• 프로젝트 전체를 Delombok하고 Lombok 사용을 중지하십시오.

내가 알기로는 Delombok은 주석의 서브셋을 삭제할 수 있는 옵션이 없다. 적어도 단일 파일의 컨텍스트에 대해서는 모두 또는 전혀 없다.Delombok 플래그를 사용하여 이 기능을 요청하기 위해 티켓을 열었지만, 가까운 장래에는 기대하지 않을 것입니다.

업데이트 8 (2014년 10월 20일)
고객님의 옵션이라면 Groovy는 Lombok의 대부분의 동일한 이점을 제공하며 @Delegate 등 다양한 기능을 갖추고 있습니다.파워에게 아이디어를 팔기 힘들 것 같으면@CompileStatic또는@TypeChecked주석을 달아 그것이 당신의 명분에 도움이 되는지 확인합니다.사실 Groovy 2.0 릴리즈의 주요 초점은 정전기 안전이었습니다.

업데이트 9 ('15년 1월 1일
롬복은 여전히 적극적으로 유지되고 있으며, 이는 입양의 안전 수준에 좋은 징조이다.@Builder 주석은 제가 좋아하는 새로운 기능 중 하나입니다.

업데이트 10 (15년 11월 17일)
이는 OP의 질문과는 직접 관련이 없는 것처럼 보일 수 있지만 공유할 가치가 있다.만약 당신이 쓰는 보일러 플레이트 코드의 양을 줄이는 데 도움이 되는 도구를 찾고 있다면, 구글 오토(특히 AutoValue)를 확인해 보세요.그들의 슬라이드 덱을 보면 그들이 해결하려는 문제의 가능한 해결책으로 Lombok을 들 수 있습니다.롬복의 단점은 다음과 같습니다.

• 삽입된 코드는 보이지 않습니다(생성되는 메서드를 "표시"할 수 없습니다). [ed note - 실제로 할 수 있지만 디컴파일러만 필요합니다.]
• 컴파일러의 해크는 비표준이며 취약합니다.
• "우리가 보기에, 당신의 코드는 더 이상 진짜 Java가 아닙니다."

나는 그들의 평가에 얼마나 동의하는지 잘 모르겠다.슬라이드에 기재되어 있는 AutoValue의 단점을 고려하면, 저는 Lombok을 고수할 것입니다(Groovy가 옵션이 아닐 경우).

업데이트 11 (2016년 2월 8일)
Spring Roo에도 비슷한 주석이 몇 개 있대요.Roo가 여전히 문제라는 것을 알고 조금 놀랐습니다. 주석 문서를 찾는 것은 조금 어렵습니다.제거 또한 디롬복처럼 쉽지 않아 보입니다.롬복이 더 안전한 선택인 것 같아.

업데이트 12 (2016년 2월 17일)
제가 현재 진행 중인 프로젝트에 롬복씨를 데려오는 것이 왜 안전한지에 대한 이유를 생각해 보던 중, 저는 금을 하나 발견했습니다.v1.14- 구성 시스템!이는 팀이 안전하지 않거나 바람직하지 않다고 생각하는 특정 기능을 허용하지 않도록 프로젝트를 구성할 수 있음을 의미합니다.게다가 다른 설정으로 디렉토리 고유의 설정을 작성할 수도 있습니다.이거 정말 멋지다.

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

업데이트 14 (17년 6월 26일)
@gavenkoa가 OPs 질문에 대한 코멘트에서 지적한 바와 같이 JDK9 컴파일러 지원은 아직 제공되지 않습니다(이슈 #985).또한 롬복 팀이 움직이기 쉽지 않을 것으로 보입니다.

업데이트 15(18년 3월 26일)
Lombok changelog는 #985가 아직 열려 있는데도 v1.16.20 현재 "JDK1.9에서 lombok 컴파일이 가능합니다"를 나타냅니다.

단, JDK9에 대응하기 위해 변경을 실시하기 위해서는 몇 가지 변경이 필요했습니다.이러한 변경은 모두 Config Default 변경으로 분리되었습니다.이러한 변경사항이 도입된 것은 조금 우려되는 일이지만 버전에서는 버전 번호(v1.16.18에서v1.16.20으로 변경)가 "증분"으로 변경되었을 뿐입니다.이 게시물이 안전성에 관한 것이었으니까yarn/npm최신 증분 버전으로 자동 업그레이드되는 빌드 시스템처럼 갑자기 각성할 수도 있습니다.

업데이트 16(19년 1월 9일)

JDK9의 문제는 해결된 것 같고, Lombok은 JDK10, 심지어 JDK11에서도 동작하고 있는 것 같습니다.

안전면에서 우려되는 점은 v1.18.2에서 v1.18.4로의 변경 로그에는 다음과 같이2개의 항목이 기재되어 있다는 것입니다.BREAKING CHANGE!? semver "patch" 업데이트에서 어떻게 변경사항이 발생하는지 잘 모르겠습니다.패치 버전을 자동 업데이트하는 도구를 사용할 경우 문제가 될 수 있습니다.

업데이트 17 (21년 3월 17일)

Lombok 개발자들과 OpenJDK 개발자들 사이에 JDK 16을 둘러싼 드라마들이 전개되고 있다.JDK 개발자들은 Lombok이 JDK 팀이 마무리하고 싶은 허점을 통해 공개되지 않은 JDK의 내부 장점을 이용하고 있지만 여러 가지 이유로 의도적으로 열어두고 있다고 주장한다.

그들은 (롬복의 안전에 대해) 다음과 같이 우려를 표명했다.

내부로의 모든 액세스는 클라이언트애플리케이션이 명시적으로 허가하고 있는 한, 이것이 수반할 가능성이 있는 유지보수(또는 시큐러티)의 문제를 의식하고 있는 것을 인식하고 있는 한, 종래와 같이 사용할 수 있게 됩니다.

Lombok은 그들이 OpenJDK를 속이고 있다고 생각할 수 있지만, 그들이 하고 있는 모든 것은 그들의 사용자를 속이기 위한 의도라고 발표하는 것이다.

Lombok이 JDK의 보안 제한에 대해 더 이상 창의적인 해결책을 찾을 수 없는 날이 곧 올지도 모른다.설령 그렇다 하더라도, 당신의 프로젝트에서 롬복의 안전성에 문제가 있을 수 있습니다.

롬복 프로젝트가 제안한 새 프로젝트에 상당한 기술적 이점을 제공한다는 것을 이미 결정하신 것 같습니다.(처음부터 확실히 말하면, 저는 롬복 프로젝트에 대해 어떤 식으로든 특별한 견해를 가지고 있지 않습니다.)

Project Lombok(또는 다른 획기적인 테크놀로지)을 일부 프로젝트(오픈 소스 또는 기타 현명한 프로젝트)에서 사용하기 전에 프로젝트 관계자가 이에 동의하는지 확인해야 합니다.여기에는 개발자와 중요한 사용자(예: 공식 후원자 또는 비공식 후원자)가 포함됩니다.

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

내가 언급하면 ##Java Freenode 채널에서 불꽃이 튀어오릅니다.

간단하다. 불꽃놀이에 참여하지 않거나 롬복에 대한 언급을 삼가라.

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

프로젝트 전략이 롬복이라면 도우미들도 익숙해져야 합니다.

자바닥을 놓쳤다고 불평할 거야

그게 그들의 문제야.제정신인 사람은 조직의 소스 코드/문서 규칙을 서드파티제의 오픈 소스 소프트웨어에 엄격하게 적용하려고 하지 않습니다.프로젝트 팀은 사용 중인 기술에 적합한 프로젝트 소스 코드/문서 표준을 자유롭게 설정할 수 있어야 합니다.

(FOLOWUP - 롬복 개발자들은 합성된 getter 및 setter 메서드에 대한 javadoc 코멘트를 생성하지 않는 것이 문제임을 인식하고 있습니다.이 문제가 프로젝트의 주요 문제라면 이를 해결하기 위한 Lombok 패치를 생성하여 제출하는 것도 하나의 방법입니다.)

미래의 커미트먼트는 모두 삭제될지도 모릅니다.

그건 안 돼!합의된 프로젝트 전략이 Lombok을 사용하는 것이라면 무료로 코드를 디롬복한 커밋은 처벌해야 하며, 필요하다면 커밋 권리를 철회해야 합니다.

물론, 이것은 당신이 이해관계자로부터 매수당했다고 가정합니다.개발자를 포함해서요.그리고 그것은 당신이 당신의 명분을 주장할 준비가 되어 있고, 피할 수 없는 반대 의견을 적절히 처리할 준비가 되어 있다고 가정합니다.

Lombok을 사용하여 필요에 따라 나중에 코드를 "델롬복"할 수 있습니다.http://projectlombok.org/features/delombok.html

개인적으로(따라서 주관적으로) 해시코드와 등가 등의 복잡한 메서드의 IDE/Own 실장에 비해 Rombok을 사용하면 내가 무엇을 달성하고 싶은지에 대한 내 코드가 더 잘 표현된다는 것을 알게 되었다.

사용시

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

Equals & Hash Code를 일관되게 유지하고 평가 대상 필드를 추적하는 것이 IDE/Own 구현보다 훨씬 쉽습니다.특히 필드를 정기적으로 추가/제거하는 경우에는 더욱 그렇습니다.

이 경우도 마찬가지입니다.@ToString포함/제외 필드, 게터 또는 필드 액세스 사용 및 호출 여부를 명확하게 전달하는 주석 및 그 매개 변수super.toString().

그리고 다시 전체 수업에 주석을 달아서@Getter또는@Setter(AccessLevel.NONE)(옵션으로 다른 메서드를 덮어씁니다) 필드에 어떤 메서드를 사용할 수 있는지 즉시 알 수 있습니다.

혜택은 계속됩니다.

제 생각에는 코드를 줄이는 것이 아니라 달성하고자 하는 바를 Javadoc이나 구현에서 파악하지 않고 명확하게 전달하는 것이 중요합니다.코드가 줄어들기 때문에 다른 방식의 구현을 쉽게 찾을 수 있습니다.

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

음, 롬복과 처음 만났을 때 나쁜 인상을 받았어요.몇 주 후, 나는 그것을 좋아하기 시작했다.하지만 몇 달 후, 저는 그것을 사용하는 데 많은 작은 문제들을 발견했어요.그래서 롬복에 대한 나의 마지막 인상은 그리 긍정적이지 않다.

내가 이렇게 생각하는 이유:

• IDE 플러그인 종속성.Lombok에 대한 IDE 지원은 플러그인을 통해 이루어집니다.대부분의 경우 정상 작동하더라도 IDE의 향후 릴리스 및 언어 버전에서도 이 플러그인의 유지보수를 위해 항상 필요한 역할을 합니다(Java 10+는 언어 개발을 가속화합니다).예를 들어 Intelij IDEA 2017.3에서 2018.1로 업데이트하려고 했는데 실제 lombok 플러그인 버전에 문제가 있어서 플러그인이 업데이트되기를 기다려야 했기 때문에 업데이트 할 수 없었습니다.이것은 또한 Rombok 플러그인이 지원되지 않는 다른 IDE를 사용하려는 경우에도 문제가 됩니다.
• 사용법 찾기 문제..Lombok을 사용하면 생성된 getter, setter, constructor, builder 메서드 등을 볼 수 없습니다.따라서 IDE를 통해 프로젝트에서 이러한 메서드가 사용되는 위치를 확인할 계획이라면 이 숨겨진 메서드를 소유한 클래스만 찾을 수 없습니다.
• 너무 쉬워서 개발자들은 캡슐화를 깨는 데 신경 쓰지 않습니다.롬복에게 문제가 되지 않는다는 것을 알고 있습니다.하지만 개발자들에게서 어떤 방법이 보여야 하는지, 보이지 않아야 하는지 더 이상 통제하지 않는 경향이 더 크게 느껴졌습니다.그래서 그냥 복사해서 붙이는 경우가 많아요.@Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructor주석이 클래스를 실제로 노출해야 하는 방법을 생각하지 않고 차단합니다.
• 빌더 오브세션 ©.이 이름은 내가 만든 것이다. (마틴 파울러.농담은 차치하고, 빌더는 매우 쉽게 만들 수 있기 때문에 클래스에 파라미터가 2개밖에 없는 경우에도 개발자가 사용하는 것을 선호합니다.@Builder생성자 또는 정적 생성자 메서드 대신 사용할 수 있습니다.때때로 그들은 롬복 빌더 안에 빌더를 만들려고 시도하기도 한다.MyClass.builder().name("Name").build().create().
• 리팩터링 시 장벽.예를 들어, 를 사용하고 있는 경우,@AllArgsConstructor생성자에 매개 변수를 하나 더 추가해야 하는 경우 IDE는 클래스를 인스턴스화하는 모든 위치(대부분 테스트)에 이 매개 변수를 추가할 수 없습니다.
• 롬복과 구체적인 방법을 혼합한다.모든 시나리오에서 Lombok을 사용하여 getter/setter 등을 만들 수는 없습니다.이 두 가지 접근법이 코드에 혼재되어 있음을 알 수 있습니다.시간이 지나면 익숙해지겠지만, 언어를 해킹하는 것 같은 느낌이 들어요.

다른 답변처럼 자바 장황함에 화가 나서 롬복으로 대처한다면 Kotlin을 사용해보세요.

롬복도 좋지만...

Lombok은 새로운 소스 파일을 생성하지 않는다는 점에서 주석 처리 규칙을 위반합니다.즉, 다른 주석 프로세서에서 getter/setter 또는 기타 모든 것이 존재한다고 예상하는 경우 주석 프로세서와 함께 사용할 수 없습니다.

주석 처리는 일련의 라운드로 실행됩니다.각 라운드에서, 각 팀은 뛸 차례가 있다.라운드가 완료된 후 새로운 Java 파일이 발견되면 다른 라운드가 시작됩니다.이렇게 하면 주석 프로세서가 새 파일만 생성하더라도 주석 프로세서의 순서는 중요하지 않습니다.롬복은 새로운 파일을 생성하지 않기 때문에 새로운 라운드가 시작되지 않기 때문에 롬복 코드에 의존하는 일부 AP가 예상대로 실행되지 않습니다.이것은 지도 구조를 사용하는 동안 저에게 큰 고통의 원인이었고, 델롬복잉은 로그에서 당신의 행 번호를 파괴하기 때문에 유용한 옵션이 아닙니다.

I eventually hacked a build script to work with both lombok and mapstruct. But I want to drop lombok due to how hacky it is -- in this project at least. I use lombok all the time in other stuff. Update to specifically mapstruct+lombok: the two libraries work out of the box with each other nowadays. The problem will still exist for other annotation processors though.

There are long-term maintenance risks as well. First, I'd recommend reading about how Lombok actually works, e.g. some answers from its developers here.

The official site also contains a list of downsides, including this quote from Reinier Zwitserloot:

It's a total hack. Using non-public API. Presumptuous casting (knowing that an annotation processor running in javac will get an instance of JavacAnnotationProcessor, which is the internal implementation of AnnotationProcessor (an interface), which so happens to have a couple of extra methods that are used to get at the live AST).

On eclipse, it's arguably worse (and yet more robust) - a java agent is used to inject code into the eclipse grammar and parser class, which is of course entirely non-public API and totally off limits.

If you could do what lombok does with standard API, I would have done it that way, but you can't. Still, for what its worth, I developed the eclipse plugin for eclipse v3.5 running on java 1.6, and without making any changes it worked on eclipse v3.4 running on java 1.5 as well, so it's not completely fragile.

As a summary, while Lombok may save you some development time, if there is a non-backwards compatible javac update (e.g. a vulnerability mitigation) Lombok might get you stuck with an old version of Java while the developers scramble to update their usage of those internal APIs. Whether this is a serious risk obviously depends on the project.

I know I'm late, but I can't resist the temptation: anybody liking Lombok should also have a look at Scala. Many good ideas that you find in Lombok are part of the Scala language.

On your question: it's definitely easier to get your developers trying Lombok than Scala. Give it a try and if they like it, try Scala.

Just as a disclaimer: I like Java, too!

I have used Lombok in almost all my projects for one year but unfortunately removed it. In the beginning it was a very clean way of development but setting up the development environment for new team members is not very easy and straightforward. When it became a headache I just removed it. But it is a good work and needs some more simplicity to setting up.

When I showed the project to my team the enthusiasm was high, so I think you should not be afraid of team response.

• As far as ROI, it is a snap to integrate, and requires no code change in its basic form. (just adding a single annotation to your class)

• And last, if you change your mind, you can run the unlombok, or let your IDE create these setters, getters, and ctors, (which I think no one will ask for once they see how clear your pojo becomes)

My take on Lombok is that it merely provides shortcuts for writing bolilerplate Java code.
When it comes to using shortcuts for writing bolilerplate Java code, I would rely on such features provided by IDE -- like in Eclipse, we can go to menu Source > Generate Getters and Setters for generating getters and setters.
I would not rely on a library like Lombok for this:

1. It pollutes your code with an indirection layer of alternative syntax (read @Getter, @Setter, etc. annotations). Rather than learning an alternative syntax for Java, I would switch to any other language that natively provides Lombok like syntax.
2. Lombok requires the use of a Lombok supported IDE to work with your code. This dependency introduces a considerable risk for any non-trivial project. Does the open source Lombok project have enough resources to keep providing support for different versions of a wide range of Java IDE's available?
3. Does the open source Lombok project have enough resources to keep providing support for newer versions of Java that will be coming in future?
4. I also feel nervous that Lombok may introduce compatibility issues with widely used frameworks/libraries (like Spring, Hibernate, Jackson, JUnit, Mockito) that work with your byte code at runtime.

All in all I would not prefer to "spice up" my Java with Lombok.

Wanted to use lombok's @ToString but soon faced random compile errors on project rebuild in Intellij IDEA. Had to hit compile several times before incremental compilation could complete with success.

Tried both lombok 1.12.2 and 0.9.3 with Intellij IDEA 12.1.6 and 13.0 without any lombok plugin under jdk 1.6.0_39 and 1.6.0_45.

Had to manually copy generated methods from delomboked source and put lombok on hold until better times.

Update

The problem happens only with parallel compile enabled.

Filed an issue: https://github.com/rzwitserloot/lombok/issues/648

Update

mplushnikov commented on 30 Jan 2016:

Newer version of Intellij doesn't have such issues anymore. I think it can be closed here.

Update

I would highly recommend to switch from Java+Lombok to Kotlin if possible. As it has resolved from the ground up all Java issues that Lombok tries to work around.

I have encountered a problem with Lombok and Jackson CSV, when I marshalized my object (java bean) to a CSV file, columns where duplicated, then I removed Lombok's @Data annotation and marshalizing worked fine.

I haven't tried using Lombok yet - it is/was next on my list, but it sounds as if Java 8 has caused significant problems for it, and remedial work was still in progress as of a week ago. My source for that is https://code.google.com/p/projectlombok/issues/detail?id=451 .

ReferenceURL : https://stackoverflow.com/questions/3852091/is-it-safe-to-use-project-lombok