no args constructor를 개발자에게 강제하는 이유

죄송하지만 질문의의도는 필요한것은 알겠는데 왜 개발자가 항상 그코드를 작성하게끔 강제하냐는 것이 질문입니다. @entity를 스캔하여 어노테이션프로세싱으로 기본생성자가없는경우 생성자를 컴파일타임위빙했으면 개발자에게 강제하지 않아도 처리가 됬을거같아서요.. 하이브네이트 팀에 대한 푸념(?)이기도 하거나와 아니면 그렇게 할 수 밖에없었던 사유가 궁금합니다.

one to one lazy미동작 메커니즘에 대해서

영한님 답변주셔서 감사합니다. 말씀하신 예제를 구현해보았습니다. (사진) (사진) (사진) (사진) 실행결과는 당연히 아래와 같습니다. 첫번째 lock메소드에서 한번 real object가 로드되고 나머지 lock메소드 호출에서는 로드된 real object를 재사용합니다. (사진) 만약 여기서 하이버네이트 팀이 nullable proxy가 가능하도록 구현하였으면 애초에 저희가 FK가 없는쪽에서 lazy loading이 발생하지 않는 사태를 만들지 않을수있지 않았을까라는 의문이 자꾸 듭니다. 코드는 아래와 같습니다. (사진) 위 코드는 비록 client가 NPE에 노출되는 점은 있지만, 위의 흐름이 일반적인 관점에서 봤을때 사용자가 설정한 lazy메커니즘을 깨지않으면서 더 자연스러워 보일수도 있을것같습니다. 왜냐하면 클라이언트가 위코드처럼 lazy동작이 아니라 eager로 동작하게끔 설정해놔도 (현재 하이브네이트가 선택한 방식처럼..) fetch이후 null일거기 때문에 NPE에 노출 되는거는 똑같은거 같아보이거든요. (사진) 둘다 결국 member가 locker가 null인지 널체크를 하면서 lock()을 호출해야하는건 동일해보입니다. 제가 뭔가 잘못이해하고있는 것인지 고견을 주시면 감사하겠습니다. 좋은 하루되세요.