JDK7_SangShin.pdf
자바 자체에 모듈 시스템 넣는다고 해서 현재 OSGi 스펙을 집어넣는 줄 알았더니 더 아랫단에서 작업하고 있었군.. 그런데 이렇게 위아래 따로 버저닝 하게 되면 나중에 골 때리게 될 것 같은데.. OSGi 스펙이 바뀌려나 -_-;
C#에 있던 internal, using이나 switch에서 case에 문자열 리터럴 써먹을 수 있게 되는건 환영할만하고.. 2진수를 0b1010 이런 식으로 쓸 수 있게 된 것도 좋고.. 그런데 숫자 리터럴에 밑줄 들어가는 부분은 좀 깨는듯 -_-; (,는 어차피 못 넣겠지만 그래도 _는 좀..)
NIO2에서 파일 변경 이벤트 받아올 수 있게 된 것도 무결성 체크 구현할 때 편하게 써먹을 수 있을 듯.. 아무튼 닷넷에서는 있는데 자바에 없어서 아쉬웠던게 많이 추가됐네..
타입 어노테이션 추가는 툴에게 주로 도움이 될진 몰라도 가독성 면에서 너무 흉악하게 보이는데..
아무튼 문서에서 얘기하는대로 클래스패스 지옥은 그만 봤으면 좋겠다.. OSGi 환경에서는 별 신경 안 쓰게 됐지만 다른 쪽에서는 여전히 지옥이니까.. 2010년 상반기 출시 예정이라면 그리 멀지 않았군..
난 unsigned나 넣어줬으면 좋겠는데 죽어도 안 넣겠지..?
사실 황이 말한 김에 Calendar가 너무 거지같아서 혹시 대체품이 없나 찾아보다가 Joda-Time 얘기가 나와서 좀 보다가 JDK7까지 흘러가게 됐음.. 그러나 JodaTime은 완전히 기존 것을 다 갈아버려서 쓰기 곤란할 것 같고.. JSR로 작업하고 있는건 언제 나올지 모르겠고.. 하여간 개 썩는 Calendar 같으니..




덧글
AnonymousY 2009/11/14 12:32 # 답글
음...전체적으로 긍정적인 발전으로 보여서 좋네요.정말 Calendar 썩죠...정말 대책이 없는건지...
xeraph 2009/11/15 22:54 #
네.. 그런데 갈수록 복잡해지는 것 같은 느낌이죠 (..)
Kevin 2009/11/21 19:06 # 삭제 답글
Closure는 JDK 7에 안 들어가는걸로 결정났다고 하더니이번에 결국 추가 되려나 봅니다. 며칠전에 발표된듯...
http://www.jroller.com/scolebourne/entry/closures_in_jdk_7
편리하니, 추가되는건 좋은데
Java의 타입 시스템과 readability를 망치지 않도록
잘 됐으면 좋겠습니다.
근데 Closure 추가는
"이렇게 뒤늦게 결정해서, JDK 7 릴리즈 전까지
충분한 시간이 있을까?" 싶을 정도로
심각한 사안인거 같은데 말이죠.
물론 이미 제안이 3개정도 나와있고
프로토타입까지 완성된 상황이긴 하지만...
개인적으로는 JDK7에 추가되기로 결정된 것중에
Automatic Resource Management가 제일 맘에 드는군요.
사실 Java 에 문제점도 많고 언어 디자인이나
API 디자인 실수도 많았지만, 계속 발전해 나가는게
보기 좋은거 같습니다. 실수를 통해서 많이 배우기도 하구요.
언어 자체는 물론 그 사용자들 까지도 말이죠.
Automatic Resource Management가 아주 뒤늦게 추가되긴 하지만,
.NET보다 나은점이라면, 한 using statement에 리소스 하나밖에
못 열어서 여럿을 열려면, nested using statements가 필요한
C#과 달리 하나의 try 에 여러리소스를 한꺼번에
열수 있어서 nested try statements 같은게
필요하지 않다는게 아닐까 합니다. 뒤늦게 추가되지만, 그덕에
좀더 나은 형태가 된게 아닐까요?
(그나저나 .NET은 3년전에, 그것도 배우기만 한거라
제가 틀렸다면 알려주시길...)
enum도 뒤늦게 추가되면서 C# 보다 좀더 다재다능하게 된거 같구요.
근데 generics 는 늦게 추가되는 바람에, 하위버전 호환성등의
이유로 컴파일 하면 타입 정보가 싹다 날아간다는게
좀 안타깝네요. :(
그리고 같은 이유로 remove() 같은 일부 메소드의 경우
generified가 안돼서 요것도 좀...
autoboxing과 함께 쓰여져서 버그를 양산할수도 있겠구요.
가끔은 Sun에서 JVM 설계를 다시하고 generics 사용시
컴파일후에도 타입정보가 날아가지 않는 형태로 완전히
바뀌어 버리면 어떨까 생각해 보기도 합니다만...
아무래도 역시 하위버전 호환성 때문에 힘들겠죠...
근데 재밌는것은 Java 설계에 참여한 사람들이
그렇게 고심해서 더 나은 디자인을 포기하면서까지
하위버전 호환성에 신경을 써서 만들어 놨는데,
아직도 JDK 1.3대 쓰면서 자기들이 만든거 안 돌아갈까봐
버전업 못 한다고 하는 기업들이 많다는 겁니다.
(아는 분에게 들은 얘깁니다만...)
뭐 얘길 들어보면, 개발 문서는 하나도 없는 소프트웨어 업체부터
Servlet같은거 없이 다 JSP로 만들고 DB 접속 정보까지 JSP에
hard-coding 하는 곳도 있으니 "버전업 못하는것 쯤이야" 일까요? @_@;
xeraph 2009/11/22 01:20 #
헐 Closure가 추가되는군요.. 의외네요.. 제네릭스는 저도 항상 아쉽게 생각하는 부분이죠..버전 업 관련해서는 ㅎㅎ 정말로 막장인 것 때문에 그런 경우도 있긴 하겠지만 아무래도 개발자와 시스템 엔지니어의 입장 차라는게 쉽게 좁혀지지는 않는 것 같습니다. JVM 자체의 보안 문제나 버그들도 수정되는데 업데이트를 안 하는게 말이 되느냐 생각할 수도 있기는 하지만 미묘하게 동작이 달라지거나 버그에 의존하거나 하는 경우들도 있다보니 ㅡㅡ;; 개발사가 지원하거나 보증해주지 않는 한 일일이 업데이트 하려고 하면 일이 너무 커지는 것 같더군요.. 하지만 다들 바쁘니까 아무래도 잘 안 하려고 하고 구버전이 계속 유지되고 그런 듯 합니다. (..)
Kevin 2009/11/22 02:22 # 삭제
저도 사실은 xeraph님 말씀하신것처럼 생각하고는 있습니다만...^^;대외적으로는 "보안 문제 해결된 것도 있고, 속도도 더 빠른데,
하위버전 호환성 신경써서 디자인까지 희생한 새버전으로
도대체 왜 못 바꾼다는건지 모르겠다" 는 식으로 말하는 편입니다.
(이렇게 강한 어조는 아니지만...^^; )
이유야, 제가 구버전 쓰기 싫어서죠...ㅡ_ㅡ;;;
즉, 지극히 방어적인 이유로... :)
물론 새버전을 사용하는것 때문에 더 신경써야 할것도 있겠지만,
좀더 편해진 것들을 포기하자니 답답해서요.
annotation이나 enum 같은거 안쓰면 많이 답답할테고
regular expression은 1.4에 도입됐고,
covariant return type 같은건 5.0 에 도입됐으니...
거기다가 JDK 1.2 이전 버전의 JVM처럼 Singleton 을
garbage collecting 하는 버그가 있는거라면...@_@;
(1.2 이전에 나온 버전 쓰는곳이 아직 있을지 모르겠습니다만)
근데, 사실 제가...
"컴파일타임에러야 컴파일러가 잡아주고,
요즘 좋은 분석툴이나 IDE가 많아서
문제점 찾기 쉽고, 테스트 코드 잘 작성해 놨으면
버전 바꿔도 별 문제 없는데 뭐가 걱정인건지 모르겠다"
라는식으로 말할 입장이 아니네요...
저도 자바 파일 한 500개 가량을 바쁘다는 핑계로
테스트 코드 단 한줄도 없이 작성해 놓은게 있어서... @_@;
지금도 이거 생각하면, 참 후회가... ㅠ_ㅠ
지금 작성하려고 해도 막막합니다.
아무튼 정말 xeraph님 말씀대로 현실적으로
그렇게 쉽지만은 않은게 대부분이겠죠.
다들 바빠서 어디어디 손보면 해결되는걸
알면서도 못하는 경우도 많겠구요.
아무튼 이런거는 프로그래밍 경험이나 경력이 많은
xeraph님 같은분들 말씀을 새겨들어야...
그나저나 블로그 보니 아직 학생이신거 같은데,
학생들도 가르치시고, 거기에 사업에, 프로그래밍에
오픈소스 프로젝트까지... 덜덜덜...
경험, 경력 아니라 실력까지 갖추셨네요.
대단하십니다.
하긴 보안쪽 일 하시는거부터가...
그 분야가 아무나 손댈수 있는 분야가 아니죠. :)
xeraph 2009/11/23 12:54 #
과찬이십니다..ㅎㅎ 이 나이 먹고도 아직도 졸업을 못 했으니 그저 부끄럽죠 (..)
Kevin 2009/11/23 12:36 # 삭제 답글
혹시 관심있으실지 몰라서...이미 Date와 Calendar의 대안으로 제안된게 있었군요.
http://jsr-310.dev.java.net/
역시, 사람들이 그 불편한 Date와 Calendar에 불만을 안 품었을리가 없겠죠.
요것도 참고로...
http://www.jroller.com/scolebourne/entry/why_jsr_310_isn_t
그나저나 진짜 문제는 이게 JDK7에 포함되느냐 마느냐 인데...
이렇게 흔하게 쓰는거는 좀 빨리 빨리 해결됐으면 좋겠네요..
xeraph 2009/11/23 12:50 #
네 이게 그런데 이번엔 안 들어간다고 알고 있네요 ㅎㅎ