Xeraph@NCHOVY

자바도 이런 경우가 있군요. ㅎㅎ
아투이(atoi)류 함수에서도 그런 경우가 있어서 예전에 개고생을 했던 슬픈 기억이... ㅠㅠ
http://msdn.microsoft.com/en-us/library/aa272023(VS.60).aspx
결국 MSDN 자세히 읽어 보고 라이브러리 링크로 문제를 해결했다는... ^^

자바에 이런거 많습니다. 하도 느리다고 구박받다보니 그런게 아닐까 싶기도 합니다.

같은 경우는 아니지만, API문서 제대로 안 읽었다가...
그넘에 Calendar에 set() 메소드 쓰면서
이거 set으로 날짜 설정하면 바로 반영되는줄 알았더니,
getTimeInMillis() 같은 메소드를 호출해야
비로소 설정이 끝나더군요.

그래서 일부 날짜/시간 비교를 사용하는 메소드가
제대로 안 돌아가는 버그가 발견됐는데...
웃긴건 테스트는 멀쩡하게 통과하고,
로그를 찍어도 멀쩡하고, 환장하는줄 알았습니다.
로그를 찍기위해서
getTime()이나 getTimeInMillis()를 호출하면
호출 순간에 계산후 설정이 끝나기 때문에
그런거였더군요.
테스트는 테스트비교 직전에 로그를 찍는 바람에
멀쩡했던거구요.
개발때도 잘 돌아갔었는데, 그역시 로그 때문에...ㅡ_ㅡ;
릴리즈 하면서 로그 찍는걸 없앴더니 비로소...

이거 버그인줄 알고 이미 버그로 보고한 경우도 있더군요.
저도 버그인가 싶어서 찾아봤었습니다.

근데, compute() 같은 메소드가 따로 있었으면
그나마 이해를 하겠는데,
(updateTime() 이랑 computeTime()이 있긴한데
전자는 private 후자는 protected 죠...ㅡ_ㅡ;
소스 확인전까지는 알길이...)
아니 도대체 누가 getTimeInMillis() 메소드 호출해서
날짜/시간 설정을 끝마치는걸 예상할 수 있을까요?
물론 문서 안 읽고, 예상을 해서 사용한게 잘못이겠습니다만 @_@;
좀더 상식적으로 만들었다면 그런일은...

아무튼 JDK에 있는 Date와 Calendar는 조슈아 블록 말대로
좀 문제가 있는 녀석들 같습니다.

그거 말고도, 아시는거겠지만,
URL에 있는 equals() 메소드를 쓰면 IP를 비교해서
네트워크에 연결된 상황과 아닌 상황에서 다른 결과가 나오고
IP체크 하느라 프로그램 성능을 저하 시킨다거나...
BufferedInputStream에 있는 skip() 메소드도 그렇고...

근데 하위 버전 호환성 때문에 아는 문제도
못 고친다는게 좀 안타깝죠.
그래서 새로 추가되는 class들이 늘어나고
자꾸 JDK 덩치가 커지고...

그나마 다행인것은 문서가 잘 작성되어 있고,
소스가 공개되어 있으니 확인해 보고,
맘에 안들면 직접 만들어서 쓰거나 써드파티
라이브러리를 쓰면 된다는 점이... @_@;