Lombok을 사용할 때 주의할 점은 뭐가 있을까요?

2013-02-03 13:28

http://gitblog.ihoney.pe.kr/blog/2013/01/23/use-lombok-annotation-in-java-project/ 에 Lombok 관련해 잘 정리한 문서가 있네요. 저도 이전 프로젝트에서 Lombok 사용했는데 정말 유용하다는 생각을 했습니다.

하지만 모든 것을 사용할 때는 주의할 점도 있을 듯 한데요. Lombok 사용할 때 주의할 점은 뭐가 있을까요? 또한 Lombok을 모든 곳에 사용하는 것이 좋을까요? 개인적으로 DTO와 VO와 같은 곳에서는 정말 유용하다는 생각이 듭니다.

13개의 의견 from SLiPP

2013-02-03 20:06

저는 개인적으로 선호하지 않아요. 지원을 위해서 무언가 추가 셋팅을 해줘야 하는것도 그렇고 눈에 보이는 코드와 실제 컴파일된 코드가 다른것도 찝찝하고. . 이클립스가 자동완성이나 소스 제너레이터가 잘 만들어주니 ㅋㅋ

2013-02-04 00:19

@ezblog 좋은 지적이다. lombok을 쓰는 것이 좋은 점도 있지만 그렇지 않은 부분도 많다. 자동 완성이야 큰 이슈가 되지 않는데 문제는 리팩토링할 때 이슈가 된다. 리팩토링이 잘 되지 않는 경우가 많이 발생하거든. 뭐 리팩토링을 자주하지 않는다면 이슈가 되지 않겠지만 말이야.

2013-02-04 08:47

아, 위의 분 이야기를 들으니 생각나는 게 있네요. ^^

간단히 예를 들어,

class A { @Getter private String something; }

A 클래스의 getSomething() 를 B 클래스에서 사용하고 있었는데, A 클래스의 something 변수명을 anything 으로 바꾸면 B 클래스에 가서 getAnything()으로 변경해줘야하는 번거로움이 있죠. 이클립스의 ctrl+H replace를 이용해서 한번에 바꿔도 되기합니다.

2013-02-04 10:47

위에서 말씀들 하신데로 속성의 리네임 리펙토링 시 문제가 될 소지가 있지요... 그런데 이문제는 @Data @Setter @Getter 에서 발생하는 문제이겠죠??? 이것또한 IDE 를 사용하고 있다면 Error 를 마크해주기 때문에 그리큰 문제는 아니라고 생각합니다. 찾기해서 일괄수정할수도 있고요 ..

@ezblog 께서 말씀하신 찝찝함으로 거론해주신 컴파일되는 소스와 실제 소스가 다르다라고 하셨는데. 작동하는 코드의 결과가 같다면 찝찝할 필요가 있을까요????? 자동완성 으로 만들어도 편리 할수 있겠지만 일단 가독성에서는 lombok 사용에 한표를 던지고 싶습니다.

lombok이 Class 작성시 가독성이 떨어지는 요소들을 제거해주는 역활을 한다고 생각합니다. 또 @@EqualsAndHashCode @ToString 는 common.lang 의 org.apache.commons.lang.builder.ToStringBuilder 나 EqualsBuilder 등에 비해 편리하다고 생각이 드네요 ...

아직까진 위에서 속성의 리네임 리펙토링시 발생하는 문제를 제외하고는 별다른 문제점을 찾지는 못했네요....

2013-02-04 14:44

또 한 가지 주의할 점이라면 객체 간에 상호 참조하는 경우 무한 루프에 빠질 가능성이 있습니다. toString, equals 메소드를 자동 생성할 때 자바 reflection을 사용하는데 상호 참조를 할 경우 무한 루프에 빠지게 됩니다. 따라서 상호 참조하는 경우가 있을 때는 @EqualsAndHashCode(exclude={“field1”, “field2”}) 처럼 exclude를 사용해야 합니다.

가독성 측면에서 lombok이 좋은 것은 사실이지만 사용할 때 주의해서 사용하지 않으면 이슈가 생길 수도 있습니다. 그리고 써보면 항상 좋지는 않은 듯합니다.

2016-10-04 20:20

Lombok 관련해 잘 정리한 문서 사이트에 연결할 수 없다고 뜨네요 최근 JPA 김영한님이 쓰신 책보다가 롬복 사용시 루프에 빠질수도 있다고 하셨는데 자세하게 설명이 안되있어서 왜 그런지 너무 궁금합니다

toString, equals 메소드를 자동 생성할 때 자바 reflection을 사용하는데 상호 참조를 할 경우 무한 루프에 빠지게 됩니다. 이부분 이해가 가지 않아서 그러는데요 좀더 자세하게 설명 부탁드려도 될까요??...

따라서 상호 참조하는 경우가 있을 때는 @EqualsAndHashCode(exclude={“field1”, “field2”}) 처럼 exclude를 사용해야 합니다. 이부분에서 어떤 필드를 제외 시키라는 말인가요??? @id 로만들어진애들 제외 시키라는 건가요??

2016-10-05 09:28

@정범석 최근 버전에서는 이 이슈가 해결되었다는 이야기를 들은 듯도 하네요. 찾아보니 없네요.

일단 이와 관련해 깊이 있게 이해하려면 Lombok이 toString() 메소드를 자동으로 생성하는 과정을 이해해야 합니다. 이를 이해하려면 자바 reflection에 대한 이해가 있으면 더 좋고요.

이 이슈는 객체 간에 관계를 맺을 때 상호참조(ORM에서 bi-direction이라고 함) 관계에 있을 때 발생합니다. 예를 들어 Question과 Answer가 상호 참조인 경우(Question은 Answer와 @OneToMany, Answer는 Question과 @ManyToOne 관계)로 설정되어 있는 경우 Question의 toString() 메소드를 생성하는 중에 Answer의 toString() 메소드 호출, Answer의 toString() 메소드를 생성하려면 Question의 toString() 메소드를 호출하는 상황이 발생합니다.

이와 같이 서로의 toString() 메소드를 반복적으로 호출하면서 무한 루프에 빠지게 됩니다. 이런 이슈 때문에 Lombok이 버전하면서 문제를 해결한 것으로 알고 있어요.

2016-10-07 21:49

전에 다른 분이 만든 스프링 프로젝트를 git에서 가져와서 빌드한 적이 있었는데, 이상한 에러가 나면서 빌드시 오류가 발생했었습니다. maven + spring이었는데 이유를 못 찾고 있다가 나중에 구글링해서 겨우겨우 발견한 게, lombok 플러그인이 이클립스에 없을 경우에 생기는 오류더라구요.

lombok이 편하긴 한데, Document가 잘 되어 있지 않으면 저 같은 초보들은 유사한 문제를 겪을 수 있을 것 같습니다.

2016-10-09 14:58

보편성과 신뢰의 문제

여전히 많은 사람들이 이클립스를 이용해서 개발을 배웁니다.

같이 일하는 사람들이 모두 똑같은 관심사와 경험을 가지고 있지 않아요

처음 업무를 인계받는 사람이 평상시 하던대로 개발환경을 구축했는데 컴파일이 안되면

얼마나 당황스럽겠어요 그리고 시작부터 불신이 생기죠

같이 일하는 관점에서 초보는 없습니다.

업무에 반드시 필요한 부분이 아니라면, 조금이라도 진입에 장벽이 될만한 부분은 제거하는 게 맞다고 봅니다.

2017-06-22 16:09

@자바지기 lombok 사용해보려고 하는데 아직도 상호참조 문제로 무한루프에 빠지더라구요..ㅠ @ToString 이랑 @EqualsAndHashCode 사용하면 여전히...

@ToString(exclude = "refClassName") @EqualsAndHashCode(exclude = "refClassName") 이런식으로 제외 해줘야 무한루프 빠지지 않던데 혹시 더 좋은 방법 있나요 ㅎㅎ

의견 추가하기

연관태그

← 목록으로