최근에 오라클에서 Java 6 update 21 을 발표했습니다. 이번 버전에서 java.dll의 변경된 사항으로 인해 이클립스 구동에 영향을 미치게 되었다고 합니다.
변경 사항은 JDK의 개발사 정보를 기존 "Sun Microsystems, Inc." 에서 "Oracle Corporation" 으로 수정한 것인데요 이클립스의 경우 Sun JRE 에 있는 non-standard 실행 옵션 중의 하나인 -XX:MaxPermSize 적용 가능 여부를 java.dll의 제조사 정보 문자열의 "Sun Microsystems"로 구분하고 있다고 하네요. 실제로 -XX:MaxPermSize 옵션을 지원하지 않는 몇몇 JVM에 해당 옵션을 적용하면 이클립스 구동이 실패한다고 합니다. 이클립스 런처는 Windows에서 실행되는 SUN VM인 경우 자동으로 -XX:MaxPermSize=256m 옵션을 적용한다고 하네요.
JAVA가 Oracle의 자산이 된 이상 개발사 정보를 변경하는 것을 뭐라고 할 순 없지만 기존에 개발된 어플리케이션에 미치는 영향을 생각한다면 오라클이 어떤식으로든 액션을 취하지 않으면 안될것 같습니다. Java 6u21에서 이클립스 구동이 실패한다면 당분간은 JDK를 Java 6u20으로 다운그래이드 해야할 듯 합니다.
제가 만든 서버에서 보낸 데이터가 xml 형식으로 바이트 스트림으로 해서 받는데 in.read로 받았더니 byte 버퍼에 태그단위로 하나씩 들어가는데다가 디버그해봤더니 in.read라는 문장은 받은 xml 태그 수만큼 반복해서 실행되고 전체 xml을 받아서 파싱하려고 Stringbuffer를 이용해서 append 하려고 했더니 이것도 안되네요..
안녕하세요 질문자님. 질문 내용을 제가 정확히 이해한 건진 모르겠습니다만 제가 이해한 내용은 보내는 서버 측에서는 예를 들어, "<tag>내용</tag>" 스타일의 문자열을 byte[]로 변환하여 outputStream.write( byte[] ); 하고 있고 클라이언트 측에서는
while ((readLength = inputStream.read(input, 0, input.length)) != -1) { stringBuffer.append( new String( input ) ); }
과 같은 동작을 하고 있다고 생각이 됩니다.
질문 내용 중 ' in.read라는 문장은 받은 xml 태그 수만큼 반복해서 실행되고' 라고 하신 걸로 미루어보아 데이터는 정상적으로 들어오고 있다고 판단됩니다. 받은 데이터를 가공하는데 어려움을 느끼고 계신 건 아닌가 하는 생각이 드네요.
우선 작성하신 클라이언트 쪽이 서버에서 보내주는 xml을 다 받으면 while 문을 빠져 나오는지 확인해 보시고요. 정상적으로 while문을 빠져 나온다면 유입된 Data를 가공하는 문제가 될 거고 그렇지 않다면 서버 측의 outputStream 에 write() 하는 부분을 확인하셔서 stream을 확실히 끝내고 있는지 확인하셔야 할 것 같습니다.
참고로 제가 작성한 소스를 첨부합니다. 첨부한 소스는 xml 형식의 문서를 읽어들여 byte 형식으로 전송하여 수신부에서 file과 문자열로 복원하는 코드가 작성되어 있습니다. Server.java 와 Client.java 는 일반적인 자바 bolocked Socket 프로그래밍 방식을 취하고 있습니다. 실제로 확인해야 하는 부분은 ByteArrayTransporter 클래스에서 클라이언트에 Data를 전송하는 부분과 Client 클래스에서 java.nio.ByteBuffer 를 이용하여 입력 데이터를 처리하는 부분 정도가 될 거 같습니다.
왜 똑같이 소수점 세 자리 숫자를 더했는데 어떤 때는 소수점 아래 자릿수가 늘고 어떤 때는 세 자리로 출력되었을까요?
소수자리 숫자는 인간이 생각하는 10진수의 개념으로 접근 하면 안되기 때문인데요.. 알고있듯이 컴퓨터는 0,1 로 모든 연산을 처리하는데 int, long 같은 정수라면 0,1로 표현할 수 있지만 float, double 같은 소수자리 수는 IEEE 754 표준에 의한 binary의 일부(fractions)로 표현하게 됩니다. ( http://www.math.byu.edu/~schow/work/IEEEFloatingPoint.htm 참조하시면 됩니다만 제게는 참.. 어렵네요.) 어쨌거나 저쨌거나 결과만 놓고 보면 '소수자리 숫자는 컴퓨터는 근사값 밖에 알 수 없다.' 인데요.
그럼, 저렇게 계산되도록 놔둬야 하느냐? 그렇지는 않습니다. 위 같은 경우는 DecimalFormat.parse() 메소드를 이용하면 됩니다. 맨 처음 코드를 아래와 같이 다시 작성해 볼 수 있겠지요.
java.text.DecimalFormat format = new java.text.DecimalFormat(".###");
새로운 hotspot, UI 어플리케이션의 시작과 구동 성능 향상, 우분투 8.04와 레드햇 엔터프라이즈 리눅스 5.3 및 윈도우즈7 지원, 357개의 버그 픽스가 이루어진 sun java 6 update 18 가 출시되었습니다. JavaSE 6 Update Release Note
엔터프라이즈 개발자가 특히 흥미를 가질만한것은 가비지 컬렉션의 성능 향상일듯합니다. Garbage First(G1) 가비지 컬렉터( 드디어 experimental 딱지를 뗐습니다.)가 신뢰성과 성능에서 괄목할 만한 향상을 이루어 냈다는겁니다. 가비지 대상 수집 처리를 병렬화(Parallel Scavenger)하고 향상된 NUMA ( Non Uniform Memory Access ) 지원이 포함됩니다. NUMA 아키텍처는 메모리에 액세스하는 방식 중 하나로 프로세스들은 서로 다른 메모리 영역에 엑세스하는데 동일하지 않은 시간을 소비하는 특징이 있습니다.
NUMA 아키텍처..
저도 이 방면으로는 겉핥기식의 지식 밖에 없습니다. NUMA 모델을 이야기 하자면 UMA(Uniform Memory Accescc)모델을 우선 설명해야합니다. NUMA, UMA하는 모델들은 컴퓨터의 병렬 프로세싱 관련된 내용으로 멀티 코어 프로세서가 메모리에 접근하는 방식을 설명하고 있습니다. UMA 모델은 모든 프로세서가 버스를 통하여 주기억장치에 엑세스하며 각 프로세스는 주 기억장치의 어느영역이든 엑세스 할 수 있으며, 엑세스에 소비하는 시간은 동일한 특성을 보이지만 프로세서 수가 늘어날 수록 공유자원에 대한 경합이 높아지므로 프로세서 수를 늘여 성능을 올리는데 한계가 발생합니다. NUMA는 UMA모델의 한계를 극복하기위한 모델로 다수의 UMA 모델이 전역 BUS를 통해 자원을 공유하게 됩니다. 때문에 메모리 엑세스 시간은 메모리의 위치에 따라 달라지는 특성이 있습니다.
아래는 텀즈 ( http://www.terms.co.kr/NUMA.htm ) 에서 인용한 NUMA의 뜻입니다. NUMA[누마]는 멀티프로세싱 시스템에서 지역적으로는 메모리를 공유하며, 성능을 향상시키고, 시스템 확장성이 있도록 마이크로프로세서 클러스터를 구성하기 위한 방법이다. NUMA는 SMP 시스템에서 사용된다. SMP 시스템은 서로 밀접하게 결합되어, 모든 것을 공유하는 시스템으로서, 다중 프로세서들이 하나의 단일 운영체계 하에서 공통의 버스를 통해 각자의 메모리를 액세스한다. 보통, SMP의 한계는 마이크로프로세서가 추가됨에 따라, 공유 버스나 데이터 경로가 과중한 부하가 생기게 되어, 성능에 병목현상이 일어나는데 있다. NUMA는 몇 개의 마이크로프로세서들 간에 중간 단계의 공유메모리를 추가함으로써, 모든 데이터 액세스가 주버스 상에서 움직이지 않아도 되도록 한다.NUMA는 하나의 상자 속에 있는 클러스터로 생각할 수 있다. 클러스터는 대체로 마더보드 상의 하나의 공유 메모리 (L3 캐시라고도 부른다)로 향하는 로컬버스에, 서로 연결된 네 개의 마이크로프로세서들로 구성된다. 이 유니트는 모든 클러스터들을 서로 연결하는 공용 버스 내에서 SMP를 구성하기 위하여 비슷한 유니트에 추가될 수 있다. 이러한 시스템은 대체로 16~256개의 마이크로프로세서를 가지고 있다. SMP 시스템에서 실행되는 응용프로그램에게는, 모든 개별 프로세서 메모리들이 하나의 단일 메모리인 것처럼 비쳐진다.프로세서가 어떤 메모리 주소에 있는 데이터를 찾을 때, 그것은 마이크로프로세서 그 자체에 붙어 있는 L1 캐시를 먼저 찾은 다음, 근처에 있는 다소 큰 L2 캐시칩을 찾는다. 그 다음에는 다른 마이크로프로세서 인근에 있는 원격 메모리의 데이터를 찾기 전에, NUMA 구성에 의해 제공되는 제3의 캐시를 찾는다. NUMA에게는, 이러한 클러스터들 각각이 서로 연결된 네트웍 내에 있는 하나의 노드들 처럼 비쳐진다. NUMA는 모든 노드들 상에 있는 데이터를 계층 체계로 유지한다. NUMA SMP 시스템의 클러스터들 사이에 있는 버스에서는 SCI (scalable coherent interface) 기술을 사용하여 데이터가 움직인다. SCI는 다중 클러스터의 노드에 걸쳐 캐시 일관성이라고 불리는 것과 대등하다.SMP와 NUMA 시스템은 대체로 공통의 데이터베이스 상에 집단적으로 작업하는 많은 수의 프로세서들에게, 작업 처리를 분담시킬 수 있는 데이터 마이닝과 의사결정 시스템 등과 같은 분야에 사용된다. 시퀀트, 데이터제너럴, NCR 등이 NUMA SMP 시스템을 생산하는 회사들이다.
대부분의 현대적인 컴퓨터는 이 NUMA 아키텍처에 기반하고 있습니다. Java HotSpot VM에서는 NUMA 를 이용 할 수 있는 시스템이라면 -XX:+UseNUMA 플래그를 통하여 병렬로 가비지 대상을 수집할 수 있습니다. 이 옵션의 효과는 꽤나 훌륭해서 8코어 옵테론 시스템에서 측정한 SPEC JBB 2005 ( http://www.spec.org/jbb2005/index.html ) 벤치마킹에서 32비트에서 30%, 64비트에서 40%성능 향상이 있었습니다.
데스크탑 어플리케이션과 Web Start의 업데이트 주요 항목을 보고있자면 썬은 데스크탑과 RIA 마켓도 무시하지 않고 있음을 엿볼 수 있습니다. ( 개인적으로 java가 이 두 영역에서의 그다지 큰 영향력을 행사하지 못할것 같다는 생각을 하지만요..) - 클라이언트 서버 양쪽 VM에 새로운 java heap configuration을 적용하여 가비지 컬렉션 성능 향상. - 빠른 시작을 위한 클래스로딩 최적화. - Direct 3D를 사용할 경우 시스템에 따라 100-200ms가량 어플리케이션 시작 시간 단축. - JavaFX 어플리케이션의 warm start 시 15%가량 빠른 구동. - Web Start와 애플릿의 jar파일의 동시 다운로드 - Java Web Start 스펙 JSR-056 을 6.0.18로 버전업하고 다수의 버그 픽스.
이 외에도 다음과 같은 변화를 포함 - jar 파일 생성시간 20% 단축 - JavaDB 버전 10.5.3으로 업데이트 - VisualVM 버전 1.2.1로 업데이트 - StaX(Streaming API for XML) 마이너 업데이트
이번 버전에 보안관련 버그 픽스 사항은 포함되지 않았습니만 이번 분기에 발표 할 다음번 업데이트에 포함될것으로 예상하고있습니다.
JRebel는 훌륭한 도구이긴 하지만, 위 링크에 설명된 몇 가지 이유로 완전한 Hot Deploy를 제공하는 것은 아니다. 다만, 분명한 것은 개발 시 로컬 서버나, 테스트 서버의 shutdown 횟수를 줄여줄 뿐만 아니라 클래스 리로딩 시간을 현격히 줄여주는 것으로도 JRebel을 사용할 충분한 가치가 있다고 생각한다.
덧. 위에 소개한 JRebel은 Open Source나 Freeware가 아님. 단, Open Source Software개발자와 Scala 개발자에 한해 무료로 제공하고 있음.
OpenJDK core-libs-dev 메일링 리스트에 재미있는 쓰레드가 진행되고 있습니다. ( 재미있다고 적긴 했지만 재미있기만 한 것은 아니지만요..) What methods should go into a java.util.Objects class in JDK 7? 이란 타이틀로 진행 중인 이 쓰레드의 내용인즉, '자바 개발자가 흔히 사용하는 유틸리티 성 메소드를 구현하는 java.util.Objects 같은 클래스를 만든다면 이 Objects 클래스에서 꼭 포함 했으면 하는 메소드는 무엇인가?' 하는 내용입니다. 썬社의 Joe Darcy로부터 시작된 이 쓰레드에는 많은 회신 메일로 해당 이슈에 대한 자바 개발자의 높은 관심도를 엿볼 수 있습니다.
Darcy는 그의 첫 번째 포스트에서 Null-safe 한 equals(arg1,arg2) 와 모든 primitive type에 대응하는 compareTo(arg1, arg2) 를 제안하고 있네요.
Andrew John Hughes 같은 경우엔 toString(arg) 메소드에 대해 자바 리플랙션을 통하여 해당 객체의 상세를 보여주면 어떻겠냐는 것과 비슷한 방법으로 clone() 메소드도 구현해 버리자는 내용을 제안했습니다.
이 쓰레드가 커뮤니티의 긍정적인 회신을 받고 있기만 한 것은 아닙니다. 이런 내용의 글을 접한 Stephan Oudmaijer 같은 사람은 infoQ의 해당 내용에 대한 기사에 댓글을 통해 stupid idea란 표현과 함께 그런 유틸성 메소드는 jakarta-commons에서 구현하도록 하고 제발 JDK는 그냥 내버려 뒀으면 좋겠다고 표현하고 있네요. ^^;
여러분도 평소에 '아.. 이런 메쏘드는 기본적으로 JDK에 있었으면 좋겠는데...' 하고 생각한게 하나 둘쯤은 있을 거라 생각되는데요.. 해당 메일링 리스트에 가입하셔서 의견을 피력해 보시는것도 재미있을것 같습니다.
org.apache.jasper.JasperException: Expression parameters.parseContent is undefined on line 45, column 28 in template/ajax/head.ftl. - Class: freemarker.core.TemplateObject File: TemplateObject.java Method: assertNonNull
Expression parameters.pushId is undefined on line 24, column 6 in template/ajax/a-close.ftl. The problematic instruction: ---------- ==> if parameters.pushId [on line 24, column 1 in template/ajax/a-close.ftl]
원인은 스트럿츠 2.1 릴리즈!! Committer 인터뷰에서도 언급되었던 내용에서 기인합니다. 기존 strtus2 에서 Dojo 툴킷을 이용한 ajax를 이용하기 위해서 <s:head theme="ajax" /> 같이 기술하던 부분이 deprecated 되었습니다. strtus2.1에서 ajax 태그를 이용하기 위해서는 문서 상단에 <%@ taglib prefix="sx" uri="/struts-dojo-tags" %> 와 같이 새로운 태그 라이브러리를 지정하고 <s:head theme="ajax" /> 를 <sx:head parseContent="true"/> 로 수정, <s:div ... /> 부분도 <sx:div ... /> 로 바뀔 뿐만 아니라 각 태그의 속성들도 변화가 있습니다.
Sun은 G1이라는 애칭으로 불리는 Garbage First 가비지 컬렉터를 Java Update 1.6.0.14와 함께 릴리즈 하였습니다. 하지만, 많은 개발자 커뮤니티에서 기다려온, 서버에 적합한 이 가비지 컬렉터를 현 시점에서는 비용을 지불하는 고객에 한해서만 사용할 수 있도록 하고 있습니다.
이 Garbage First(이하 G1) 가비지 컬렉터는 update 6u14 이상에서 작동합니다.
G1은 가비지 콜렉팅 시 시스템 pause를 줄여, 서버 측에 적합합니다. G1의 가장 큰 장점은 compaction 성능과 예측성이 향상된 Concurrent Mark-Sweep(CMS)과 사용의 간편함입니다.
많은 사람이 이는 썬의 정책 변경의 징조이며 오라클과의 합병과 무관치 않다고 생각하고 있습니다.
Java의 제약이 시작되었다. 썬은 새로운 G1 가비지 컬렉터를 포함한 Java 1.6.0.14 JDK와 JRE를 출시하며 릴리즈 노트에 'Although G1 is available for use in this release, note that production use of G1 is only permitted where a Java support contract has been purchased.'와 같이 명시했다. 이는 이미 오라클의 입김이 작용하기 시작한 것은 아닌가. 새롭고 멋진 기능들을 Business commercial version의 Java SE에 넣는 동안 OpenJDK는 침체 한 길을 걷게 될 것이다.
릴리즈 노트를 읽고 받은 첫 느낌은 '현재의 코드는 제품으로써 미숙하지만, 출시를 진행합니다. G1은 기본적으로 비활성화되어 있지만, 여러분의 어플리케이션에 G1을 적용하여 테스트하고 싶을지도 모릅니다. G1을 활성화 하여 생기는 문제에 대해서는 Sun Support contact를 이용하지 않는다면 어떤 공식적인 도움을 기대할 수 없습니다.' 정도 였습니다.
G1이 JDK/OpenJDK7 의 중요한 기능으로 선정되면서, 현재의 상용화 결정이 이후에도 계속되지는 않을까 심히 걱정이 됩니다. 오라클에 특별히 반감을 품고 있거나 하진 않지만, 썬 보다 사업 수완 좋은 오라클이라는 게 마음에 계속 걸리는군요..
자바 레퍼런스타입이 정말 call by reference에 의한 전달이라면 changeObject( TargetClass obj)이 수행되고 나면 tc는 null 이어야 하지만 그렇지 않죠. 실제로 자바도 reference type을 인자로 전달할 때에 reference를 넘기지만 바로 그 reference가 아니라 reference의 사본의 값을 넘기므로 진정한 의미에서 call by reference로 볼 수 없으며, 이는 위 코드로도 충분히 증명이 되고 있습니다.
사실, 자바에서 인자 전달이 call by value냐 call by reference냐 하는 해묵은 논쟁보다는 실제로 어떻게 인자가 전달되는지 이해하고 코드를 작성하는 게 더 중요하겠지요.
올해로 10번째를 맞이하는 한국 자바 개발자 컨퍼런스. 해를 맞이할수록 강의 내용도 알차지고, 진행도 매끄러워지는걸 느낀다. 그에 반해 올해는 어쩐 일인지 참관자 수가 그 어느 해보다 적은 것 같다. 재작년의 절반정도일까..? 불과 이삼 년 전만 해도 북적거렸는데.. 올 핸 조용하고 차분한 느낌. 뭐, 북적대는 것보단 이편이 훨씬 좋긴 하지만 주최 측인 JCO나 협찬 기업의 느낌은 좀 다르겠지? 이것도 다 어수선한 시국탓인가....?
스트럿츠 2.1.이 릴리즈 되었습니다. 요즘 MS쪽 어플리케이션 개발 프로젝트를 하고있지만 여전히 자바쪽 흐름을 읽는것도 게을리 하고 있지 않습니다만, 쉽지 않네요.
스트럿츠 2.1은 많은 양의 코드를 Plug-In Framework로 옮기는 리펙토링, Convention plug-in에 의한 XML 설정 감소, 향상된 REST 지원에 초첨을 두고 진행되었습니다.
InfoQ에서 스트럿츠2 커미터인 Musachy Barroso씨와 인터뷰한 기사가 올라와서 포스팅 합니다.
2.0과 2.1의 차이점은 무엇인가요? 많은 수의 버그픽스가 있었습니다. 그리고 REST, Convention, Java Template과 같은 플러그인이 추가되었습니다.
많은 기능이 플러그-인 형태로 변경되었습니다. 이렇게 한 이유는 무엇인가요? 스트럿츠 코어에는 진정한 core만을 남기자는 아이디어에서 출발했습니다. 그리고 나머지는 플러그인에 집어 넣는거죠. 이렇게 하면서 코드의 유지보수가 쉬워 졌습니다. 그러면서 Dojo 플러그인 같은 것들은 더 이상 스트럿츠에서 지원하지 않습니다. 이런 변화는 제거된 플러그인을 사용하지 않는 개발자와 작은 footprint를 원하는 개발자 이외의 사람에게 직접적인 장점은 없습니다.
Ajax 태그를 depreciate 한 이유는 무엇인가요? Struts2의 ajax 태그는 Dojo 0.4.x에 기반하고 있습니다. 그것을 Dojo의 최신버전에 맞춰 포팅하는것은 모든 ajax 태그의 코드를 다시 작성해야한 다는것과도 같은 이야기입니다. Dojo의 새로운 버전은 너무 빨리 출시되고 마이너 버전에서도 변경되는 코드의 양이 너무 많습니다. 태그가 Dojo의 모든 기능을 다 포함하고 있지 않기 때문에 개발자는 주로 Dojo 라이브러리를 직접 사용하는 경향이 있습니다. 이런 이유들과 ajax 태그 개발 지원자의 부족으로 ajax 태그를 depreciate 했습니다.
어떤 이유로 CodeBehind 플러그인들을 Convention 플러그인으로 바꾸게 되었나요? Convention은 외부 프로젝트였고 늦게 Struts에 추가되었습니다. Convention은 좀 더 빠른 ClassPath Scanner, 더 나은 Configuration elements, 로깅, 다양한 configuration 옵션, configuation reloading, 더 나은 문서화 등을 지원합니다.
Java Template 플러그인은 무엇인가요? Java Template은 FreeMarker를 이용하여 java만으로 구현한 'simple theme' 구현체입니다. 이 플러그인의 태그는 재작성이 불가능한 약점이 있는 원래의 그것보다 4~5배 가량 빠르게 동작합니다.
다른 많은 Web Framework가 있는데 우리는 왜 Strtus2를 선택해야 하나요? 스트럿츠2는 아마도 가장 약한 커플링(loosely-coupled)으로 구현된 프레임워크일 겁니다. 많은 기능이 커스터마이징 없이, 혹은 약간의 커스터마이징만으로 사용할 수 있으며, 프레임워크를 익히기가 쉽습니다. 약한 커플링은 스트럿츠의 실체에 대한 지식 없이도 비지니스 로직을 작성 할 수 있도록 해 줍니다. 그러면서도 스트럿츠는 대용량 트래픽을 발생하는 사이트에서 유연한 확장성을 담보하고 있다는 점입니다.
마지막으로 한마디. 스트럿츠 2.1 출시까지 오랜 기간 공을들였습니다. 우리는 스트럿츠 프레임워크의 빌드와 릴리즈 프로세스 개선을 위해 정말 열심히 일하고 있습니다. 앞으로는 좀 더 짧은 주기로 새로운 버전이 릴리즈 되는것을 기대하셔도 좋습니다.
자바 객체와 XML간의 변환에관해서는 몇 가지 라이브러리들이 존재하고 있습니다만 이번 시간에는 Java SDK에 기본으로 포함되어 있는 java.beans.XMLDecoder와 java.beans.XMLEncoder를 이용하여 자바객체<->XML간 변환 방법을 알아보겠습니다.
java.beans.XMLDecoder와 java.beans.XMLEncoder클래스는 J2SE 1.4 버전부터 이용할 수 있습니다.
//자.. 객체를 XML로 변환 시킵니다. XMLEncoder encoder = new XMLEncoder( new BufferedOutputStream( new FileOutputStream("C:\\Sample.xml"))); encoder.writeObject(sample); encoder.close(); //객체 레퍼런스를 찍어보구요.. System.out.println(sample);
//이젠 XML에서 객체로 복원시켜 봅니다. XMLDecoder decoder = new XMLDecoder( new BufferedInputStream( new FileInputStream("C:\\Sample.xml"))); SampleBean sample2 = (SampleBean) decoder.readObject(); decoder.close(); //객체 레퍼런스를 찍어보구요.. System.out.println(sample2); } }
예.. 변환의 핵심은 XMLEncoder 클래스의 writeObject() 메소드와 XMLDecoder 클래스의 readObject() 메소드 에 있습니다.
자바에는 객체 직렬화(Serialize) 란게 있지요.. 위 XMLDecoder와 XMLEncoder가 직렬화 기능을 이용하는건지 아닌지 확인 해 볼까요? 가장 정확한 방법은 XMLDecoder와 XMLEncoder의 소스를 보는것이겠지만 이미 위 예제 소스만으로도 충분히 예상 하실 수 있습니다. 위 예제의 SampleBean 이 Serializable 하지 않음에도 xml문서로 생성되었습니다. 예.. XMLDecoder와 XMLEncoder 내부적으로 java Reflection을 이용하여 xml, 객체간 변환을 수행하고 있습니다.
java Reflection을 이용한다고 했습니다. 이는 getXXX, setXXX 메소드가 없다면 해당 변수를 xml로 만들어내지 못하고 객체로 복원해 내지도 못함을 의미합니다.
또 하나, XMLEncoder를 통해 변환된 xml은 문서의 형태로 보아도 외부 시스템과의 정보의 교환보다는 객체의 상태저장/복원을 목적으로 사용하는게 더 어울릴거란 생각이 드네요.
2010년 초반 출시를 목표하고있는 Java 7의 기능을 Java SE의 수석 엔지니어 Mark Reinhold가 Devoxx에 게시한 이후 여러 반응이 나오고 있습니다. 비록 그의 발표가 완전히 결정나지 않은 사항에 대한 잠정적인 내용이라곤 해도 커뮤니티 - 특히 클로저(Closure)의 누락을 주시하는 - 의 반응은 대단합니다.
모듈화 - JSR-294와 Project Jigsaw. JSR 292 - JVM의 dynamic language 지원 JSR 203 - 진정한 비동기 I/O( non blocking I/O가 아닌)로 구현되는 더 새로워진 I/O API JSR TBD - 아래에 기술하는것 같은 약간의 언어적 변화 - 안전한 rethrow - Null dereference 표현식 : '?' 신택스를 이용한 Null 체크 - 향상된 타입 추론 - Multi-catch : catch 절에 ','를 이용하여 다수의 Exception 기술 JSR 296 - 스윙 어플리케이션 프레임워크 6u10 기능들의 개선(자바 커널, 퀵스타트,플러그인 등)
So it's confirmed. Despite James Gosling wanting closures, despite 3 working closure prototype compilers, despite every other JVM language supporting closures, Java 7 will not have closures.
It should have closures instead of the new style "for" loop added in Java 5. It should have closures in Java 6. Now it seems that it will not get closures in Java 7. Closures are not that difficult to understand. At least when you compare them to anonymous inner classes in Java. Others disagree. I don't follow the reasoning of the closure opponents when they say that because there are stupid Java programmers out there you should limit the Language trying to prevent them from doing too much harm. That's just impossible. Incompetent programmers will shoot themselves in the foot in any language. Fortunately there are other languages on the JVM that can use the real strength of Java: libraries, portability, and (to some extent) tooling.
이 외에도 정말 많은 개발자들이 자바언어의 Closure 미 지원을 아쉬워합니다.
이번 발표와 커뮤니티의 반응을 통해 너무나 많은 개발자들이 클로저를 원하고 있다는 사실을 알수 있었습니다. 아직 Java 7의 모든 기능 확정되지 않은 상황이기에 커뮤니티의 반응에따라 기능이 추가될 여지도 배제할 순 없지만 개인적으로도 개발의 편의성을 고려하여 언어차원에서 클로저를 지원하면 좋겠다는 생각입니다. 현재 한국 자바 개발 현장에선 1.4가 주류를 이루고 있다고 보여지고 많지 않은 곳에서 1.5 이상이 쓰이고 있는 현실에 비추어보면 1.7이 현장에서 침투하기까진 적지않은 시간이 필요하겠지만요..
Closure에 대해 관심을 갖으신 자바개발자라면 "Neal Gafter의 자바를위한 클로저 프리젠테이션" 을 훑어 보시는것을 추천합니다.
Generics(JSR-14 였었나요?)가 JSR에 올라가서 1.5에 추가되기까지 8년이라는 시간이 걸렸죠.
기존 코드와의 역방향 호환성을 유지하면서 도입의 영향을 최소화하기 위해 그렇게나 긴 시간을 들여 고민을 한 것인데요.
클로저를 도입하는데도 저런 긴 시간을 들인다면 그 사이 어떤 전개가 펼쳐질지 궁금합니다.