EJB 3.0과 JDO 2.0의 통합
반가운 소식입니다. 골자를 나름대로 적어보면, 다음 정도로 요약되겠군요.
EJB 그룹에 JDO 그룹의 멤버를 포함해서 ㅤㅌㅗㅎ합팀을 구성한다.
EJB에 단일 POJO persistence 모델을 규정한다.
위의 새로운 POJO persistence 모델은 j2se나 j2ee 개발자 모두에게 단일화된 OR 매핑 수단을 제공하기 위해서이고, j2ee 5.0 기간에 완료한다.
JDO 2.0의 향상된 JDOQL이 새로운 POJO persistence 모델에 동작하게 한다.
Starting this reconciliation effort now is very timely given that both the EJB and JDO specifications are going through significant revisions. As specification leads for EJB 3.0 (JSR-220) and JDO 2.0 (JSR-243), we have jointly created the following plan to move this community effort forward:* This is a community effort. We are expanding the JSR-220 Expert Group to include some members from the JSR-243 Expert Group. By joining forces, we will bridge the two communities and leverage the know-how in both groups. The current JSR-220 specification lead will remain unchanged.
* The work to define a single POJO persistence model for the Java community will be done under JSR-220 starting from the existing JSR-220 Early Draft.
* The technical objective for this new POJO persistence model is to provide a single object/relational mapping facility for all Java application developers that works in both J2SE and J2EE. The work will be done within the J2EE 5.0 time frame.
* The new POJO persistence model will be delivered by JSR-220 as a separate specification, Reference Implementation, and Technology Compatibility Kit, usable independently of EJB 3.0.
* As currently planned, the scope of JSR-243 will include maintenance to JDO 1.0.1 and enhancements to JDOQL. Additionally, the JDO expert group will aim to deliver JDOQL that would work with the new POJO persistence model so those with a preference for JDO query style can leverage the new common persistence API. The current JSR-243 specification lead will remain unchanged.
http://javalobby.com/thread.jspa?messageID=91811955&threadID=14630&forumID=61
JDO와 통합으로 EJB가 올바른 방향으로 발전하고 있다는 건 인정하지만
JDO와 통합으로 EJB가 올바른 방향으로 발전하고 있다는 건 인정하지만 너무 뒤늦은 선택이 아닌가 싶습니다. EJB 2.0이 나올 때 쯤 저런 변화가 있었다면 현재 서버측 개발 환경은 크게 달라졌을 것입니다. (물론 그럼에도 불구하고 우리나라에선 2000년이나 지금이나 꿋꿋이 에디트플러스에서 JSP 삽질을 하겠지만요; )
솔직히 자바에서 가장 이해가 가지 않는 부분은 왜 항상 오픈소스 쪽의 발전을 무시하는 가 하는 점입니다. 이미 대세가 Log4J로 완전히 기울었을 때 java.util.logging이라는 불완전한 Log4J의 클론을 내놓는 걸봐도 그렇고, Java3D와 여러 OpenGL 바인딩이 경쟁하는 걸봐도 그렇고 스윙 vs SWT의 경쟁을 봐도 그렇습니다.
물론 선택의 다양성은 커다란 장점이지만 다시 말하면 쓸데없이 코어 API의 덩치가 늘어나고 있다는 단점이기도 합니다. 지금도 쉽게 선택할 수 있는 퍼시스턴스 관련 프레임워크 들이 널려 있는데 왜 굳이 그런 분량이 큰 코드를 코어 API에 불완전하게 구겨 넣으려고 하는 지 이해가 가지 않습니다.
반면 정작 썬만이 할 수 있는 부분, 즉 JRE 자체를 개선하고 자바의 사용을 확대하는 작업은 아직도 지지부진합니다. 아무리 자바 스윙이 좋아졌다고 해도 한 번이라도 리눅스용으로 스윙 어플리케이션을 만들어 보거나 윈도우즈에서 독립실행 응용프로그램을 패키징 해봤다면 무엇이 클라이언트 자바의 발전을 막고 있는지 명백하게 알 수 있을 것입니다.
썬이 이미 오픈소스 진영에서 수년 전 부터 구현해 놓은 퀄리티 라이브러리를 베끼는데 정신이 팔려있을 동안 오픈소스 닷넷 진영에서도 이들 라이브러리를 C#으로 포팅해서 현재 닷넷의 최대 약점 중 하나인 오픈소스 라이브러리의 부족을 메꾸어 나갈 것입니다(솔직히 유명 오픈소스 닷넷 라이브러리 중에 자바 포팅해서 만들지 않은게 뭐가 있나요?; ). 그리고 MS 스스로도 퍼시스턴스 프레임워크의 중요성을 인식하고 ObjectSpace 같은 걸 만들어 VS.NET에서 편리하게 쓸 수 있게 하겠지요...
항상 느끼는 거지만 자바가 닷넷과의 경쟁에서 살아남기 위해서는 썬이 IBM 등에 인수되어 망하거나 오픈소스화 되어야 하지 않을까 싶군요...
----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
동감하면서...
그 이유는 아마도 스콧 맥닐리의 폐쇄성과 고슬링의 욕심이 빚어내고 있다고
봅니다.
맥닐리아저씨의 MS뺨치는 독점욕은 이미 알려진 사실이고 또 고슬링의 자바
욕심또한 대단하더군요. 컨퍼런스나 초청강의보면 자기가 자바의 아버지라
면서 거들먹거리는 모습을 심심찮게 볼 수있지요...
솔직히 현재 자바가 시장에서 버티고 있는 이유는 뒤에서 IBM, Oracle이 버텨주기 때문이라고 생각합니다.
(특히 IBM의 자바에 대한 집착은 대단합니다.)
위의 JSR220이나 JSR243과는 별개로, IBM과 BEA는 JSR2
위의 JSR220이나 JSR243과는 별개로, IBM과 BEA는 JSR235:Service Data Objects 라는 새로운 프레임워크 스펙을 진행 중입니다.
http://www.jcp.org/en/jsr/detail?id=235
SDO에 대한 소개의 글입니다.
http://www-106.ibm.com/developerworks/library/j-sdo/
----
I paint objects as I think them, not as I see them.
atie's minipage
Re: 동감하면서...
고슬링은 emacs에 대해서도 그런 행태를 보인적이 있죠. 고슬링이 처음에 스톨만의 emacs를 C로 새로 구현/개선해서 무료로 소스코드를 배포하던 gosling emacs의 판권을 어느날 갑자기 UniPress에 팔아넘기면서 GNU emacs도 소스의 상당부분을 버려야 했다고 합니다. 소스코드를 서로 참고하고 가져다 쓰는게 일반적이었던 80년대 초반의 일입니다. 그일이 결국 GPL이 오늘날의 모습으로 정비되는 가장 큰 계기였다고 하네요.
=-=-=-=-=-=-=-=-=
http://youlsa.com
[quote="fender"]솔직히 자바에서 가장 이해가 가지 않는 부분
Java3D는 OpenGL 수준이 아니라 그 위에서 동작하는 Open Inventor와 같은 수준의 라이브러리입니다. Java3D와 Open Inventor에 있는 scene graph 자료구조는 상당히 귀찮은 배치작업들을 쉽게 해 줍니다.
SWT는 Swing이 나온지 2년이나 뒤에 공개되었습니다. 실제 널리 사용되어 검증될 기간도 필요했을테니 사실상 3년 뒤에나 생각할 만한 것이었을겁니다. 3년동안 만들어논 Swing을 AWT 처럼 포기할만한 이유는 Sun에서 가지지 못했으리라는 것은 당연한 일이라고 생각합니다.
[quote="meteors"]SWT는 Swing이 나온지 2년이나 뒤
썬이 SWT/이클립스 플랫폼에 애써 무관심한 태도를 보이는 것은 100% 정치적인 이유입니다. 이클립스란 이름 부터가 썬에게는 껄끄러운 것이고, 이클립스 재단에 참여 요청이나 자바의 오픈소스 공개 여부 등을 놓고 사사건건 IBM과 신경전을 벌여온 것은 널리 알려진 사실입니다.
Java3D의 경우는 SWT/스윙 이슈와는 달리 제가 전문 지식이 없어서 자세한 내용은 모르지만 개발자들 간에 Java3D/OpenGL 바인딩 선택 여부를 놓고 상당한 논란이 있었습니다. 최근까지 썬은 사실상 Java3D에 대한 개발을 중단한 상태였고 얼마전에 오픈소스로 공개된 것도 Java3D 자체가 아닌 관련 유틸 등 의 코드였기 때문에 과연 썬을 믿고 Java3D를 계속 써야 할지 아니면 Xith3D/JOGL 등의 오픈소스 라이브러리를 사용할 지 고민이 될 수 밖에 없습니다.
Java3D가 OpenGL 수준의 라이브러리가 아니라고 하셨는데, OpenGL 기반에서 동작하는 Xith3D의 경우 Java3D와 거의 유사한 기능을 제공하며 많은 3D 자바 프로그램이 개발이 정체된 Java3D 대신 이와 같은 대안을 택한 것으로 알고 있습니다.
----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
[quote="fender"]Java3D의 경우는 SWT/스윙 이슈와
Java Research License 문제인것 같군요. Java3D는 SGI와 협력해서 만든것이라 Sun 혼자서 풀기는 어렵죠.
그리고 JOGL(Java Bindings for OpenGL)이 OpenGL과 같은 수준이고(wrapping이니까 같을 수 밖에 없겠죠) JOGL 위에서 동작하는 Xith3D가 Java3D하고 같은 수준이라고 정리하겠습니다.
Xith3D에 대한 문서을 읽어보니 게임을 위해 속도를 빠르게 하려고 thread safe를 희생하고 또 double을 안쓰고 float만 사용하도록 한 점 등이 있다는 것도 알 수 있었습니다.
지향하는 목표가 Java3D하고는 다른 것 같습니다. 상호작용과(그래서 속도가 중요한) 시장성이 중요한 게임을 만드려면 Xith3D로 가는것이 바람직하겠지요. 약간의 늦음은 참아낼 수 있는 또는 돈으로 빠른 기계를 살 수 있는 경우(simulation, 연구)라면 Java3D가 적합할 것입니다.
high-end 연구용으로는 SGI machine이 많이 사용되는데 JOGL은 Windows, Linux, Solaris, Mac OS X에서만 porting이 되어있어서 아직 한계가 있네요. 또 Windows에서 Direct3D가 되어야 최근의 추세를 따라갈텐데 아직 Xith3D에서 그정도까지는 지원을 못하구요.
Re: 동감하면서...
이 주장에 대해서는 RMS의 일방적인 주장이고 고슬링의 입장은 다릅니다. 고슬링이 C로 emacs를 짜기 이전에 C언어로 작성된 emacs는 존재하지 않았습니다. elisp 프로그램들과 로우레벨 언어로 작성된 코어야 존재했습니다만 고슬링의 프로그램이 왜 상업화 되어서 안되는지 설명해주지 못한다고 봅니다.
- 죠커's blog / HanIRC:#CN
음... 자바 자체가 포인터를 포기한 이상 이맥까지 들먹일 필요야...
음... 자바 자체가 포인터를 포기한 이상 이맥까지 들먹일 필요야...
---------------------------------------------------
야!...