저는 새해의 성과 목표를 생각해 내고 있습니다. 코드베이스의 크기를 줄이기위한 목표, 특히 상용구를 만드는 것이 재미있을 것이라고 생각했습니다. 이 문제를 해결하기 위해 내가 취한 한 가지 조치는 Project Lombok을 사용하여 콩을 최대한 짧게 만드는 것입니다. 그러나 나는 새로운 소프트웨어와 접근법에 대한 단점을 간과하는 습관이 있으므로 Stack Overflow 커뮤니티에 의존하고 있습니다. 왜 누군가가 롬복이 나쁜 생각인지 말해 줄 수 있습니까?Project Lombok의 위험은 무엇입니까?
주요 단점은 IDE 지원입니다. Lombok은 실제로 언어 변경이 아니기 때문에 IDE는 Java 만 이해하므로 롬복을 지원하는 IDE가 필요합니다. 지금은 이며 이클립스와 IntelliJ가 포함 된 Eclipse 만 있습니다. 당신이 괜찮을지도 모르는 이클립스를 사용한다면, 미래 개발자를 위해서도 결정을 내리고 있다는 것을 기억하십시오.
코드의 일부를 groovy와 같은 덜 의식적인 언어로 옮기는 것이 좋습니다. 우리는 비즈니스 논리와 모델 중 일부를 그루비로 성공적으로 옮겨 왔으며 실제로 원활하게 작동합니다.
Lombok과 같은 잠재적 인 단점은 setter/getters가 "missing"인 경우 소스 도구는 "bean"자질을 제공하는 결과 객체의 측면을 "인식"하지 않을 수 있습니다. 왜냐하면 이러한 자질은 컴파일 된 수업.
또 다른 단점은 도구 체인 내에 또 다른 "흑 마법"이 있다는 것입니다. 다행스럽게도, 다소 익숙하지 않은 것으로 보입니다. (필자는 그것을 사용하지 않았습니다.) 런타임보다는 컴파일 타임에 발생한다는 사실은 사실상 축복입니다 (IMHO). 하지만 코드베이스에 아티팩트가 추가되므로 프로젝트없이 코드를 재사용하거나 공유 할 수 없습니다. 따라서 컴파일 된 클래스 파일은 "POJO"일 수 있지만 소스 코드는 POJO가 아니라고 주장합니다.
위의 두 가지 방법은 절충적인 단점이 아니라 오히려 기대되는 부분입니다.
바닐라 클래스를 얻으려면 http://projectlombok.org/features/delombok.html을 사용할 수 있습니다. – maaartinus
롬 보크는 자바 컴파일러와 밀접한 관련이 있습니다. 주석 프로세서 API는 컴파일하는 동안 (그리고 기존 파일의 수정이 아닌) 새 파일을 만들 수 있기 때문에 lombok은 해당 API를 진입 점으로 사용하여 Java 컴파일러를 수정합니다. 불행히도 컴파일러의 이러한 수정은 비공개 API를 많이 사용합니다. lombok을 사용하는 것이 좋은 생각 일 수 있지만 컴파일러를 업그레이드하면 코드가 파손될 수 있음을 알고 있어야합니다. 확률은 낮지 만 비공개 API를 사용할 때마다 불편 함을 느낍니다.
아주 좋은 지적. Java 8 + Lombok의 역사는 이것이 문제가 될 수 있음을 보여주었습니다. –
다른 답변으로 @Jcs 사용자가 지적한 것처럼, 나는 더 추가하고 싶습니다.
우리 프로젝트에서 mapper 클래스를 생성하는 데 사용되는 mapstruct를 사용하고 있습니다. mvn generate-sources 명령을 사용하여 코드가 컴파일되기 전에 maven 프로세서 플러그인을 사용하는 프로세스 단계에서 완료됩니다.
프로젝트 lombok은 컴파일 단계에서 클래스 파일의 getter/setter에 대한 바이트 코드를 추가합니다.
프로세스 단계가 컴파일 전에 실행되기 때문에 클래스에서 사용할 수있는 getter/setter가 없다는 것을 알 수 있습니다.
둘 이상의 컴파일 단계를 실행할 수있는 몇 가지 해결 방법이 있습니다. 자세한 내용은 git hub ticket을 참조하십시오.
참고 : 나는 봄에서 STS를 IDE를 사용하고 있으며이 롬복 :
그것은 타사 라이브러리, 그리고 잘 모르는 개발자가 지원됩니다.
IDE는 주석 처리를 지원해야합니다 (IDEA 및 Eclipse 용 플러그인이 있음).
위에서 언급했듯이 코드에는 getters/setter가 없습니다. 그것은 수중 음파 탐지기/checkstyle 위반으로 이어집니다.
"Java + Lombok"의 소스 코드는 Java 소스 코드가 아닙니다. Borland는 수 년 전 Borland C++ Builder IDE에서 VCL 용으로 만든 것과 비슷한 것으로 봅니다. C++ 코드에 "속성"을 도입하여 C++이 아닌 새로운 프로그래밍 언어를 효과적으로 도입했습니다 (C++이 아니라). C++ 언어의 표준). "Java + Lombok"을 사용하는 소스는 Java 언어 스펙과 관련하여 유효한 소스가 아닙니다. 게다가 주석은 언어의 의미에 영향을 미치지 않도록 고안된 것이라고 생각합니다.
Eclipse : Netbeans Dev의 Project Lombok을 사용합니다. 그리고 그들은 다른 IDE도 지원한다고 생각합니다. – TheLQ
상황이 개선 될 수도 있지만, Lombok 프로젝트에서 IDE를 사용하려면 명시 적 IDE 지원이 필요하다는 비판이 여전히 남아 있습니다. 프로젝트가 더 이상 엄격하게 Java 코드로 간주되지 않는 시점. – Zeki
위안이라면 이클립스를 사용하지만 일부 개발자는 아직 롬복을 지원하지 않는 IDEA를 사용합니다. – jldugger