Java 7 전망
Dolphin은 2007년에는 릴리스 되지 않을 것이다. 내년에 릴리스 될 가망성은 있다. 작업은 진행 중이고, 일부 기능들은 일찌감치 표준 확장으로서 데뷔를 마쳤고, 적어도 베타 버전으로 릴리스 되었다.
언어에 특성을 추가하는 것이 제거하는 것 보다 훨씬 더 쉽다는 것은 불행한 일이다. 시간이 흐를수록 언어가 점점 더 복잡해진다는 것은 피할 수 없는 일이다. 심지어 독립적인 상태로 좋은 기능들 조차도 서로서로 엮이면서 문제가 많은 기능이 되어버린다.
불행히도, 자바 커뮤니티는 아직 이러한 교훈을 터득하지 못한 것 같다. 이것은 매우 일반적인 사실인데도 말이다. 어떤 실질적 문제도 해결해주지 못하는데도 불구하고, 언어 디자이너들에겐 감당하기 힘들만큼 참신하고 흥분되는 신텍스들이 있을 수 있다. 따라서 클로저(closure), 다중 상속, 연산자 오버로딩(operator overloading)을 포함한 Java 7의 새로운 기능들에 대해 언급하고 있는 듯 하다.
실현 가능성이 반반 이겠지만, 올해 안에 Java 7 베타 버전에 클로저가 도입될 것이고, 연산자 오버로딩도 잘하면 볼 수 있을 것이다. 하지만 다중 상속은 불가능 할 것이다. 자바 대부분이 단일 상속 계층에 기반하고 있다. 다중 상속을 이 언어에 도입할 수 있는 그럴듯한 방법이 없다.
현재, 많은 신택스들이 있고, 이중 일부는 합당하지만, 어떤 것은 그렇지 못하다. 많은 제안들이 getFoo() 같은 메소드를 -> 연산자로 대체하는데 초점을 맞추고 있다.
List
집합체에 접근하는 첫 번째 가능한 방법은 배열관련 신텍스를 사용하는 것이다. 예를 들어, 다음과 같이 작성하는 대신,
List content = new LinkedList(10);
content.add(0, "Fred");
content.add(1, "Barney");
String name = content.get(0); |
아래와 같이 작성한다:
List content = new LinkedList(10);
content[0] = "Fred";
content[1] = "Barney";
String name = content[0]; |
또 다른 방법으론 리스트에 대한 배열 초기화 문법을 사용할 수 있다:
LinkedList content = {"Fred", "Barney", "Wilma", "Betty"}
|
이 두 가지 제안 모두 가상 머신(VM)을 수정하지 않고 작은 컴파일러 조작으로도 구현될 수 있었다. 기존의 어떤 소스 코드도 무효로 하지 않았으며 재정의 하지 않았고, 심지어는 새로운 신택스에 보다 중요한 이슈가 되었다.
개발자의 생산성에서 차이를 만들어내는 한 가지 언어 특징은 XML과 SQL로 작업할 때 다루게 되는 테이블, 트리, 맵을 관리하는 내장된 원시타입이다. JavaScript의 E4X와 Microsoft의 Cω와 Linq 프로젝트는 내장된 원시타입을 이용한 개발 향상성에 기여하지만, 자바 플랫폼은 이러한 측면에 대구책이 아직은 없는 듯 하다.
프로퍼티
프로퍼티 액세스용 신택스를 보자. 한 가지 제안은 getFoo 와 setFoo 를 호출할 때 간단히 ->를 사용하는 것이다. 따라서, 다음과 같이 쓰는 대신,
Point p = new Point();
p.setX(56);
p.setY(87);
int z = p.getX(); |
아래와 같이 작성한다.
Point p = new Point();
p->X = 56;
p->Y = 87;
int z = p->X; |
.과 #을 포함한 기타 심볼 역시 ->의 대안으로 제시되었다.
앞으로는, Point 클래스의 프로퍼티로서 관련 필드를 구분하거나, 구분하지 않을 수도 있다.
public class Point {
public int property x;
public int property y;
} |
개인적으로, 전혀 흥미롭지 않다. 나는 자바 플랫폼이 보다 퍼블릭 필드를 실제로 사용할 때 Eiffel 계열의 방식을 채택하기를 바란다. 하지만, getter와 setter는 필드와 같은 이름으로 정의되면, 필드의 읽기와 쓰기는 자동으로 이 메소드로 보내진다. 더 적은 신택스를 사용하고 더 유연하다.
임의 정밀도 연산(Arbitrary precision arithmetic)
 |
연산자 오버로딩
표준 수학 기호를 사용하는 것은 연산자 오버로딩과 같은 것이 아니다. 적어도 C++에서 문제를 일으키는 그러한 종류는 아닌 것이다. '+' 부호와 기타 연산자는 여전히 어떤 프로그램에서든 뚜렷한 의미를 갖고 있다. 이들은 의미를 프로그램마다 수정하지 않는다. 비슷한 연산에 같은 신택스를 사용한다면 코드는 더욱 읽기 쉬워진다. 따라서, 신택스 재정의는 다른 프로그램에서는 다른 것을 의미할 수 있기 때문에 코드 읽기가 더 어려워 질 수 있다. | |
메소드를 연산자로 대체하는 또 다른 제안은 BigDecimal과 BigInteger에도 해당된다. 예를 들어, 현재 무한 정밀도 연산(unlimited precision arithmetic)을 코딩 해야 한다면,
BigInteger low = BigInteger.ONE;
BigInteger high = BigInteger.ONE;
for (int i = 0; i < 500; i++) {
System.out.print(low);
BigInteger temp = high;
high = high.add(low);
low = temp;
}; |
이것은 다음과 같이 명확히 작성될 수 있다.
BigInteger low = 1;
BigInteger high = 1;
for (int i = 0; i < 500; i++) {
System.out.print(low);
BigInteger temp = high;
high = high + low;
low = temp;
}; |
클래스들의 남용과 이에 따른 퍼포먼스 저하가 있을 수 있지만 이 제안은 그렇게 거슬리지 않는다.
JAR에서 JAM 취하기
Java 7은 오랫동안 자바 개발자들을 짜증나게 했던 다양한 클래스 로더들(class loader)과 클래스 패스와 관련된 문제를 해결했다. Sun은 Java Module System을 사용하여 이러한 문제를 해결하고 있다. .jar 파일 대신, 데이터는 .jam 파일로 저장된다. 이것은 모든 코드와 메타데이터를 포함하고 있는 일종의 "superjar"라고 할 수 있다. 가장 중요한 것은, Java Module System은 처음으로 버전 관리를 지원하기 때문에, 해당 프로그램은 Xerces 2.6이 아니라 2.7.1버전을 필요로 한다고 지정할 수 있게 된다. 또한 종속 관계를 지정할 수 있다. 예를 들어, JAM의 프로그램은 JDOM을 필요로 한다고 지정할 수 있다. 모듈 전체를 로딩하지 않고 하나의 모듈을 로딩할 수도 있다. 마지막으로, 다수의 서로 다른 JAM들에 대한 다양한 버전들을 제공하는 중앙 집중화된 레파지토리로의 역할을 제공해 줄 것이고, 애플리케이션은 여기에서 제공하는 것들 중 필요한 것들을 선별할 수 있다. JMS가 작동하면 jre/lib/ext로의 지정 해야할 일련의 과정은 과거로 사라질 것이다.
패키지 액세스
Java 7은 아마도 액세스 제한을 조금 완화할 것이다. 이는 하위 패키지가 상위패키지에 있는 클래스들의 패키지상 보호되어있던 필드들과 메소드들에 접근할 수 있게 해줄 것이다. 또한, 하위 패키지가 상위 패키지의 페키지상 보호되었던 멤버들 중 명시적으로 접근 가능하도록 정의된 멤버들을 접근 할 수 있도록 해줄 것이다. 두 방법 모두, 애플리케이션을 여러 패키지들로 나누어서 보다 단순하고 테스트 성능도 향상시킨다. 단위 테스트가 하위 패키지에 있다면, 이들을 테스트 할 수 있도록 메소드를 공개할 필요도 없다.
파일시스템 액세스
파일시스템 액세스는 1995년부터 자바 플랫폼의 주요한 문제였다. 10년이 넘었지만, 파일을 복사하거나 이동하는 것 같은 기본적인 작동을 수행하는 신뢰성 있는 크로스 플랫폼 방식이 없다. 이러한 문제를 해결하는 것이 지난 세 개의 JDK 버전들(1.4, 5, 6)의 공공연한 이슈였다. 슬프게도 파일을 옮기거나 복사하는 지루하지만 필요한 API들이 메모리 매핑 I/O 같은 덜 일반적이지만 매력적인 연산에 밀려났다. 아마도 JSR 203은 이 문제를 해결할 것이고 우리에게 실현 가능한 크로스 플랫폼 파일 시스템 API를 제공할 것이다. 작업 그룹은 진정한 비동기식 I/O 문제에 대해 많은 관심을 쏟을 것이다. 내년 이맘때쯤 결과가 나올 것이다.
실험
어떤 변화가 일어나든 오픈 소스 세계에서 가장 먼저 구현된다면 더욱 좋을 것이다. 그래야지만 우리가 얼마나 많은 또는 얼마나 적은 차이를 만들어 냈는지를 볼 수 있기 때문이다. Sun의 Peter Ahe는 java.net에서 Kitchen Sink Project를 시작했다. 목표는 javac 컴파일러를 반복적으로 분기하여 다른 많은 아이디어를 테스트 하는 것이다.
클라이언트 GUI
비록 많은 사람들이 알아채지는 못했지만, 자바 플랫폼은 4~5년 동안 데스크탑에 실제로 존재했다. RSSOwl, Limewire, Azureus, Eclipse, NetBeans, CyberDuck 등을 포함한 일부 양질의 데스크탑 애플리케이션들은 자바 코드로 작성되었다. 이러한 애플리케이션은 Swing, AWT, SWT 같은 거의 모든 GUI 툴킷과 심지어 Mac OS X의 Cocoa 같은 플랫폼 툴킷에 의해 작성된다. 이러한 툴킷 중에서 어떤 것이 더 낫다고 단정지을 수는 없지만, Swing은 원래의 느낌을 갖고 있는 애플리케이션을 생성하는데 다른 것 보다 더 나은 기능을 갖출 것이다.
Swing은 여전히 개발하기에는 도전이 되지만, Swing Application Framework의 출현으로 내년에는 상황이 더 나아질 것으로 보인다. 이 프레임웍은 현재 Java Community Process에서 JSR 296으로 개발 중이다. 다음은 JSR에 대한 설명이다.
잘 작성된 Swing 애플리케이션들은 시작시키고 종료시키는 작업과 리소스, 동작, 세션의 상태들을 관리하는데 있어 동일한 핵심요소들을 가지는 경향이 있다. 새로운 애플리케이션들은 이 모든 핵심 엘리먼트들을 처음부터 만들어낸다. Java SE는 어플리케이션들을 구성하는데 어떠한 지원도 제공해 주지 않고 있고, 바로 이것 때문에 개발자들은 SE 문서에서 설명하는 예제 그 이상으로 확장된 애플리케이션을 구현할 때 당황하게 된다.
Swing 애플리케이션의 기본 구조를 정의함으로써 그러한 허점을 채우기 위하여 정의된 사양서를 제공할 것이다. 이는 대부분의 데스크탑 애플리케이션의 일반적인 인프라스트럭처를 정의하는 확장성 있는 클래스 세트나 "프레임웍"을 정의할 것이다.
Swing Application Framework은 대부분의 전형적인 애플리케이션을 지원하면서, 개발자들로 하여금 시작과 종료와 같은 몇몇 커스터마이징 부분을 추가해 넣을 수 있도록 해줄 것이다. 이는 어플리케이션 시작과 종료 와중에 윈도우나 다른 부분들에 대한 저장과 복구를 다룰 수 있게 해줄 것이다. 마지막으로, 개발자들은 Swing 이벤트 디스패치 쓰레드 외부에서 실행되는 비동기식 액션을 작성할 수 있게 된다.
JavaBeans와 Swing을 향상시키고자 하는 노력이 진행 중이다. JSR 295는 빈들을 바인딩 하는 표준 방식을 정의하여, 하나의 빈이 업데이트 되면 이것이 자동으로 다른 빈에 반영될 수 있도록 한다. 예를 들어, GUI 그리드 빈은 연관된 데이터베이스 빈이 변경되면 자동으로 업데이트 된다.
마지막으로 JSR 303은 XML 기반 밸리데이션(validation) 언어 관련 작업을 진행하여 주어진 빈이 취할 값을 지정한다. int 프로퍼티는 1과 10 사이에 있어야 한다거나, String 프로퍼티에는 합법적인 이메일 주소가 포함되어야 한다는 등을 지정할 수 있다. 올해 말에는 베타 버전으로 이러한 기능을 사용할 수 있을 것이고 내년 이맘때쯤 Java 7에 대한 작업이 끝날 것이다.
데스크탑 언어로서 자바 플랫폼
일부 프로그래머들은 자신들이 선호하는 언어이기 때문에 자바 코드로 데스크탑 애플리케이션을 작성하지만, 대부분은 멀티 플랫폼을 수용하기 위해서이다. 데스크탑 언어로서 자바 플랫폼에 대한 관심은 비 Microsoft 계열 데스크탑의 수와 연관되어있다. 세 가지 주요 데스크탑에서의 자바 프로그래밍에 대해 알아보자.
Windows
Swing은 특히 오픈 소스 개발로의 전향과 아울러 여전히 내년까지도 Windows 룩앤필을 향상시킬 것이다. 결국, LimeWire 같은 순수 자바 프로그램들은 Windows 보다 자연스러운 모습을 보이게 될 것이다. 하지만, 원래의 Windows 애플리케이션 개발 언어는 C#(일부 C 와 C++ 포함)이다. 그리고 프레임웍은 .NET이 될 것이다. 자바 코드는 Windows 생태계에 깊이 관여하지는 않을 것이다.
Macintosh
Microsoft와 마찬가지로 Apple Inc.도 자바 코드를 거의 포기했다. Apple은 Objective C 와Cocoa를 선호하지만 그의 결과 또한 같다. Mac 전용 개발자들은 Apple의 주력 언어와 환경에서 자바 코드를 제거하려는 시도를 계속해서 하고 있다.
긍정적인 측면은, Apple은 QuickTime과 Cocoa 같은 상용 API에 대해 자바 코드를 더 이상 지원하지 않지만 Apple VM은 그 어느 때보다도 훨씬 더 나아졌다. Apple의 Java 6 포트가 곧 릴리스 될 것이다. (Sun의 JDK와는 달리) 오픈 소스는 아니지만, 오픈 소스 프로그래머들이 버그를 픽스할 것이다.
Linux
GPL 라이센스로 자바 코드를 가장 순수한 오픈 소스 리눅스로 함께 묶을 수 있는데, 이로써 자바 플랫폼은 매력적인 리눅스 개발용 언어로서 한층 더 다가갈 수 있다. 이러한 상황이 5전 전에만 일어났다면, 리눅스 커뮤니티는 C 때문에 고생을 하지 않아도 되었을 것이고, Mono도 불필요했을 것이다.
Gnome과 KDE용 자바 바인딩은 내년에는 더욱 많은 관심을 끌 것이다. C, C++, 또는 C#이 아닌 자바 코드를 사용하여 리눅스 GUI 프로그램을 개발하는 적어도 한 개 이상의 주요 프로젝트가 시작될 것으로 보인다.
Ruby가 경쟁에서 이기다!
|
Bloatware
JavaScript는 이미 JDK 6에 번들되었다. 추가 언어는 JDK 7에 추가될 것이다. 너무 부풀려지는 느낌이다. Sun이를 멈출 수 있는 방법이 없다. BeanShell을 선택하면 Groovy쪽 사람들도 개입하고 싶어할 것이다. Groovy가 들어오면, Ruby 사용자들도 들어오려고 할 것이다. Ruby가 개입되면 Python은 가만히 있을까? 표준 JDK는 이미 너무 방대해졌다. 여러 스크립팅 언어를 지원하는 것도 큰 일인데, 번들링까지는 무리이다. 해결책으로 이들 모두를 지원은 하겠지만, 어떤 것도 번들하지는 않을 것이다.
긍정적인 측면은, Sun은 초기의 다운로드 사이즈와 애플리케이션 시작 시간을 줄이는 방안을 모색하고 있다. 특히 애플릿과 Java Web Start 애플리케이션에 대해 그렇게 하고 있다. 거대한 클래스 라이브러리가 서버에 남겨지고, 필요한 부분만 다운로드 될 것이다. | |
우리가 단 하나의 언어로만 대화한다면 이 세상은 매우 지루할 것이다. 자바 플랫폼은 애플리케이션 개발에 있어서 최상의 선택이지만, 작은 프로그램이나 매크로에는 절대로 맞지 않는다. Java 6은 이를 인식하고 BeanShell, Python, Perl, Ruby, ECMAScript, Groovy 같은 스크립팅 언어와 통합하기 위해 javax.script 패키지를 추가하고, invokedynamic 가상 머신 명령을 Java VM에 추가하여 Java VM이 직접 동적으로 기술된 언어들을 컴파일 할 수 있도록 했다.
비록 내가 개인적으로 선호하는 것이 아니지만, 2007년에 나는 Ruby에 돈을 투자할 것이다. Python 코드는 훨씬 더 깨끗해진 것 같고, Ruby 코드보다 이해하기가 더 쉽다. 아마도 이 부분에 대해서는 대부분의 자바 프로그래머들도 동의할 것이다. Python은 시기를 잘못 타고 태어났다. 많은 개발자들은 Python을 배우는 것과 자바 코드를 배우는 것 중 선택해야 했고, 대부분이 자바 코드를 선택했다. 그들이 자바 신택스를 다 이해하고 다른 언어를 받아들일 준비가 되었을 때는 과거의 언어가 아닌 미래의 언어를 택하기 마련이고, 그것이 Ruby일 듯 하다. 가장 중요한 것은 Ruby는 Ruby on Rails의 절대적인 킬러 애플리케이션을 갖고 있다. 이것의 단순함은 현실적인 Java Enterprise Edition (JEE) 개발자들에게는 매우 매력적으로 비춰진다.
Rails 이상으로, JRuby 프로젝트는 다른 스크립팅 언어들 보다 기존 자바 코드와 라이브러리와 더 나은 통합을 시도한다. 사실, JRuby는 표준 Ruby를 누르고 Ruby를 사용하는 자바 프로그래머들뿐만 아니라 Ruby 프로그래머들도 선호하는 플랫폼이 되었다. 좋은 일이다. Ruby는 막강하나 Python은 그렇지 못하다는 것은, 슬프지만 진실이다.
다른 스크립팅 언어들은 점점 더 쇠락해 갈 것이다. Perl은 너무 구식이고 현대적인 애플리케이션과 잘 맞지 않는다. Groovy는 뚜렷한 비전이 없이 유용성이나 친숙성을 떠나 컴퓨터-과학 분야의 전문언어로 채택되는 경향이 있다. BeanShell, Jelly, 그리고 일부 언어들도 관리가 되고 있지 않다. Ruby가 자바 프로그래머의 스크립팅 언어가 될 것인지는 내년까지 승부가 갈릴 것이다.
IDE가 점점 나아지고 있다.
2006년은 IDE에게 있어서 최악이었다. 이클립스에 당황한 Sun은 그들의 에너지와 리소스를 NetBeans에 쏟아 부었고, 결국엔 막강한 경쟁자가 되었다. 어떤 면에서, NetBeans는 2006년 말에는 이클립스를 능가하는 것처럼 보였다. 훨씬 더 나은 룩앤필과 GUI를 디자인 하는 훨씬 더 나은 툴을 갖고 있었다. 반면, NetBeans가 갖지 못한 것은 이클립스와 같이 커뮤니티가 활성화 되지 못했다는 것이다. 훨씬 더 많은 플러그인과 서드 파티 제품들이 NetBeans 보다는 이클립스에 기반하고 있다. 이러한 추세는 점점 더 가속화 될 전망이다.
이클립스는 3.3 버전을 위해 힘들게 작업 중이고, 2007년에는 릴리스 될 것이다. Sun은 올해 NetBeans 6를 출시할 것이다. 두 개 모두 메이저 릴리스가 될 것 같지는 않다. 단순히 여기 저기에 작은 기능들을 추가하고, 버그를 픽스하고, 사용자 인터페이스를 정리한 정도이다.
NetBeans는 계속해서 Eclipse의 영역에서 시장 점유율을 높여갈 것이며, 그의 성장 가능성또한 아주 많다. Sun의 집요한 JDK 다운로드에 NetBeans 끼워 넣기는 무리 없어 보인다. 올해 말까지 두 개의 IDE는 시장을 양분할 것이다.
한편, IntelliJ IDEA 사용자들은 이러한 모든 상황에 개의치 않고 자신들이 최상의 Java IDE를 사용하고 있다고 자부하고 있다. 하지만, 대부분의 사용자들은 $500이 넘는 가격을 부담스러워 할 것이고 시장 점유율은 5%에 그칠 것이다.
Java Enterprise Edition
자바 프로그래밍의 어떤 부분도 JEE 만큼 성공적이면서도 욕을 먹은 부분은 없다. 이것은 모든 사람들이 애증을 갖고 있는 기술이다. 복잡하고, 혼란스럽고, 무겁다. 자바 프로그래밍의 어떤 부분도 이를 대체하기 위해 그렇게 많은 노력을 들인 적이 없다. Spring, Hibernate, Restlet, aspects, Struts ...등 끝이 없다. 그럼에도 불구하고, 거의 모든 자바 프로그래머들은 JEE를 찾고 있기 때문에 Sun은 이 부분을 신경을 써야 할 것이다.
엔터프라이즈 세계에서 내가 목격한 경향 중 하나는 단순함에 대한 열망이다. 많은 프레임웍들이 나와 있으며, 그 안에서 작고 단순함을 선호하는 추세다. 점점 더 많은 고객들은 JEE 스택의 큰 부분을 거부하고 있고 이러한 추세는 지속될 전망이다. 대신 고객들은 Spring 같은 단순한 프레임웍으로 전향하거나 Ruby on Rails를 사용하는 추세이다. 더 단순하고, 보다 이해하기 쉬운 시스템에 대한 열망은 서비스 지향 아키텍처(SOA)와 Representational State Transfer (REST)에 대한 관심을 증폭시키고 있다.
2007년에도 단순함에 대한 추세는 지속될 것이다. Rails에 탄력을 받은 많은 사람들은 Python (Turbo Gears), Groovy (Grails), Java (Sails) 같은 다른 언어에서도 성공하기 바란다. 이들 중 하나는 성공하겠지만, 그렇지 않을 경우 더 이상의 새로운 것은 없다. 결국, 비즈니스는 그들이 이미 갖고 있는 SOA, REST, Rails를 계속 사용할 것이다.
Java Micro Edition
단순하고 작은 것에 대한 열망이 임베디드 분야에도 적용될 수 있을까? 지난해 동안 자바 플랫폼은 작은 장치에 있어서 큰 성공을 거두었고 2007년에도 그러한 동력을 계속 이어갈 전망이다. 우선, Mobile Information Device Profile (MIDP)의 버전 3이 기대된다. 특히, 여러 MIDlet을 하나의 VM에서 실행할 수 있게 될 것이고, 백그라운드 에서는 한 개 이상을 실행할 수 있다. 또한 암호화된 레코드 관리 시스템(RMS) 스토어와 IPv6 지원도 기대된다.
현재 개발 중인 Java ME용 Scalable 2D Vector Graphics API 2.0은 많은 장치에서 사용할 수 있는 애니메이션 기능을 확대하고 있다. SVG 애니메이션 외에도 오디오 및 비디오 스트리밍도 실행한다. 모바일 네트워크가 열리면, 정말로 중요해진다. 셀폰의 YouTube를 생각해 보라. (물론, 네트워크가 연결되지 않으면, 이것은 어떤 누구도 보고 싶지 않은 2인치 짜리 기업 광고일 뿐이다. 미국에서 이것이 실현될지 의문이지만, 유럽에서는 가능하리라고 본다.)
모바일 개발자들은 Java ME용 XML API를 지원하는 원년이 될 것이다. 이 API는 전화기의 제한된 메모리 환경에 맞도록 설계된 SAX, DOM, StAX, JAXP의 하위 세트이다. 많은 사람들은 순수한 XML은 전화기에는 맞지 않는다고 생각한다. 올해에는 이것이 옳은지, 그른지 판가름 날 것이다.
모든 좋은 소식에도 불구하고 Apple의 iPhone은 여전히 모바일 폰 개발 플랫폼으로서 자바 플랫폼에 위협적인 존재가 될 것이다. iPhone은 출시된 지 여섯 달 만에 최고의 주목을 받고 있다. 문제는 폐쇄 플랫폼이라는 것이고, 셀폰 네트워크 표준에 의해서도 자바 코드를 실행할 것 같지 않다. 이는 모바일 폰, PDA, 개인용 커뮤니케이터용 서드 파티 애플리케이션을 판매하려는 사람들에게 끔찍한 소식이 아닐 수 없다.
요약
JDK의 오픈 소스 전향 덕택에, 2007년은 자바 프로그래밍 역사 이래 최고로 흥미로운 한 해가 될 것이다. 지금까지, 자바 플랫폼은 Sun의 목표나 투자로만 제한되었지만, 이러한 현상도 곧 바뀔 전망이다. 개발자 커뮤니티의 막강한 힘으로 자바 프로그래밍은 어디든 항해할 수 있다. 개발자들은 전보다 더 자바 코드로 더 많은 일들을 할 수 있다. 데스크탑, 서버, 임베디드 이 모든 것들이 가속화 될 것이다. 하지만 이러한 엔진들도 일시적으로 멈출 때가 있을 것이다. 좋은 것은 살아남고, 그렇지 않은 것은 사장될 것이다. 자바 플랫폼에서 좋아하지 않는 부분이나 여러분을 괴롭혔던 것이 있다면 여러분의 IDE를 띄워 해킹을 시작해 보는 것도 좋다.
여러분이 갖고 있는 컴파일러를 지금 시작해 보기 바란다.
기사의 원문보기
Comment on this post!