프로젝트 빌드 에러

안녕하세요. yoon6669님IntelliJ에서 사용하는 자바 버전을 17 또는 21로 변경해보시겠어요?추가로 다음 내용을 참고해서 자바 버전을 17또는 21로 변경해야 합니다.https://docs.google.com/document/d/1j0jcJ9EoXMGzwAA2H0b9TOvRtpwlxI5Dtn3sRtuXQas/edit?tab=t.0#heading=h.f9xqb7l8nuph감사합니다.

영속성 컨텍스트 flush에 들어가는 쿼리 기준이 궁금합니다

안녕하세요. jayjoy05님하이버네이트는 JPQL을 실행할 때 기본적으로 플러시를 먼저 수행하고 JPQL을 수행합니다. 따라서 UPDATE User u SET u.name ="AA" WHERE u IN :users JPQL 쿼리가 실행되기 직전에 먼저 플러시가 수행되어야 합니다.그런데 하이버네이트 내부에 최적화 로직이 있습니다. JPQL이 현재 User를 대상으로 하는 JPQL이기 때문에 User 엔티티에 변경 사항이 없다면 플러시를 수행하지 않습니다.이 경우 User 엔티티가 영속성 컨텍스트에 없고, 따라서 변경사항이 없습니다. 이 경우 JPQL을 수행하기 직전에 플러시가 수행되지 않습니다.그리고 쿼리 수행 이후 바로 clearAutomatically에 의해서 영속성 컨텍스트가 초기화 되어버린 것입니다.감사합니다.

영한님 ReentrantLock 대기상태 다시 질문드려요!

안녕하세요. 김태언님질문의 핵심이 ReentrantLock에서 lock()을 호출할 때 대기 상태가 되면 BLOCKED 상태가 되는가? 아니면 WAITING 상태가 되는가이지요?너무 고민하기 보다는 간단한 예시를 만들어서 ReentrantLock 락을 획득하지 못하고 기다리는 스레드의 상태를 출력해보시면 바로 이해가 되실거에요 🙂사실 BLOCK이라는 표현이 스레드가 대기한다는 중의적인 표현으로 많이 사용되기 때문에 혼란이 있을 수 있는데요. 그래서 GPT나 여러 블로그에서 대기 한다는 표현을 함께 섞어서 이렇게 사용하면서 혼란이 있는 것 같아요. 제가 코드와 테스트로 확인해보았을 때는 WAITING 상태가 맞았습니다.감사합니다.

스프링 수동 빈 등록에서 인코딩 관련 질문입니다.

안녕하세요. 김한성님이 부분은 저도 잘 모르겠습니다. 혹시 아시는 분 있으면 답변 부탁드려요.감사합니다.

pdf 파일 수정 부탁드립니다.

안녕하세요. 생각하는자님도움 주셔서 감사합니다 🙂테스트 코드의 경우에는 두 가지 방식을 모두 보여드린 것인데요. 메뉴얼을 수정하는 과정중에 변경된 것 같아요. 만약 둘 중 선택하신다면 assertThat 방식이 좀 더 직관적이어서 이 방식을 권장합니다.감사합니다.

System.nanoTime() 메소드에 대하여 문의 드립니다.

안녕하세요. seonman.kim님도움 주셔서 감사합니다 🙂다음 버전에 패치할게요^^!

로그 추적기 V1 - 프로토타입 개발 소스 코드 관련 문의드립니다.

안녕하셍요. 최제수님값이 있다는 것이 항상 보장되기 때문에 Long -> long을 사용하는 것이 더 나은 방법입니다.static을 제거하는 것이 맞습니다 🙂알려주신 내용들은 다음 패치에 반영할게요 🙂감사합니다.

공통 속성을 여러 개 사용하고 싶을 때 사용방법?

안녕하세요. nickheatlhy님자바는 단일 상속만 지원하기 때문에 @MappedSuperclass를 사용하는 경우에도 단일 상속을 사용해야 합니다.감사합니다.

equals - 구현(2)에서 자동 완성으로 코드 한줄이 없이 나오는데 제가 생각한게 맞나요?

안녕하세요. 박혁진님저도 궁금해서 찾아보니 다음 이슈로 패치되었네요 🙂https://youtrack.jetbrains.com/issue/IDEA-357686 다음 내용으로 메뉴얼에도 반영해둘게요 🙂 > 참고: 최신 IntellJ에서는 equals 구현에서 다음 첫 줄 코드가 제거된다.if (this == o) return true;* 이유: 내부 분석 결과, 대부분의 실무 코드에서는 자기 자신을 비교하는 경우가 거의 없다. 따라서 분기 예측 미스가 더 큰 비용을 유발한다는 리포트(IDEA-357686)가 반영되었다.감사합니다.

OrderServiceImpl 클래스에 의존성 주입이 되는 이유를 모르겠습니다

안녕하세요. yoon6669님이번 테스트 코드에서는 스프링 컨테이너를 사용하지 않기 때문입니다.// 이 코드는 순수 자바 코드입니다 (스프링 컨테이너 없음) OrderService orderService = new OrderServiceImpl(new MemoryRepository(), new FixDiscountPolicy()); 여기서 중요한 포인트들을 정리해보겠습니다:1. 테스트 코드의 특징이 테스트는 순수 자바 테스트입니다스프링 컨테이너(@SpringBootTest, ApplicationContext 등)를 사용하지 않습니다따라서 @Component, @Autowired 같은 스프링 어노테이션이 전혀 동작하지 않습니다2. 왜 오류가 나지 않는가?@Autowired는 스프링 컨테이너가 객체를 생성할 때만 동작합니다테스트에서는 new OrderServiceImpl(...)로 직접 객체를 생성하고 있습니다생성자에 직접 파라미터를 전달하므로 의존관계가 수동으로 주입됩니다스프링 컨테이너가 개입하지 않으므로 빈 등록 여부는 상관없습니다4. 스프링 컨테이너를 사용한다면?만약 스프링 컨테이너를 사용하는 테스트라면:@SpringBootTest class OrderServiceTest { @Autowired OrderService orderService; // 이 경우 FixDiscountPolicy가 빈으로 등록되어야 함 } 결론: 테스트 코드는 순수 자바이므로 스프링의 자동 주입 메커니즘과는 별개로 동작합니다. 직접 객체를 생성하고 생성자로 의존관계를 주입하는 것입니다. 감사합니다.