JDK 5.0 (Code명 Tiger)가 드디어 release 되었군요...

JDK 5.0..

이렇게 쓰는것은 처음 봤네요. ^^;

전 1.4.x버젼에서 5.대로 점프했나 했네요... ^^;; 설마설마 하면서..

근데 모노가 모에요? -_-
(이런 왕초보를 봤나 무식해서 지송 )

.NET도 Java도 미덥진 않지만,
사실 그에 상응하는 오픈소스플랫폼이 존재하지 않는다는 것도 사실이죠.
그래서 Mono와 같은 프로젝트가 의미가 있는것이 아닌가 합니다.

Mono가 이런저런 딴지가 걸려 WinForm, ASP.NET과 같은 부분을 버린다해도
그 남은 부분이 전혀 쓸모없는 것이 아니니까요.
오픈소스플랫폼 중에 그에 상응할만한 것이 있다면 모르겠습니다만,
적어도 현재까지는 없죠. dotGNU 프로젝트도 시들하고요.

현재까지 해왔듯 그냥 C나 C++로 개발하는 방법도 있긴하겠습니다만,
C++는 productivity 측면에서 Java나 C#보다 떨어지는게 사실이기도 하고,
뭔가 대안이 필요하다고 생각합니다.
이러한 상황에서 Mono가 그저 부질없는 프로젝트라고 보긴 어려운것같네요.

그리고 궁금한 것이 있는데,
인터페이스만 가져다가 구현은 전부 새로 했을 경우
법적인 문제에 대해 자세히 알고 싶습니다.
사실 API를 베낀다, 라고 보자면 Wine 프로젝트도 마찬가지 같은데요.
Wine은 MS에서 관대해서 내버려두는 것이라고 봐야 하는것인지요 ?
Mono에 대해 Novell이 법적인 문제를 전혀 고려하지 않고 지원하는 것인지도
다소 의문이 들고요.

흠...

mozilla Project에 .Net에 대응될만한 뭔가가 있나요??

아시다시피 mozilla Project는 Internet 관련 성향이 크고, .Net은 개발관련인데, 대응이 되나요?

정확히 1:1 로 대응될 만한 것을 찾기에는 딱히 말할 것은 없네요.

mozilla 프로젝트를 브라우저 프로젝트에 한정한다면 그렇지만, 일종의 플랫폼이라고 봐야 하지 않을까 하는 생각에 말씀 드린 것이었습니다.

제가 잘못 알고 있는것인가요?

잘 아는 내용은 아니니, 기술적인 논쟁은 피하고 싶네요. ^^

GCJ/Classpath는 Sun에 대해 안전한가요 ?
( Sun의 Java API등의 사용에 대해서요. )

동기가 별로 없었어서 직접 써본적이 없네요.
간략히 소개해주시면 감사하겠습니다.

API를 베끼는 것은 법적으로 아무 문제가 없습니다. API는 "공개된" 인터페이스의 일종입니다. 여기서 말하는 인터페이스는 유저 인터페이스가 아니고 기술적인 계층 (layer) 사이를 이어주는 가교 역할을 하는 인터페이스를 얘기합니다.

따라서 Wine은 MS에서 관대(?)해서 내버려두고 있는 것이 아니라 Wine의 접근 방법 자체가 공개된 인터페이스를 기술적으로 구현해 나가고 있기 때문에 별다르게 딴지를 걸만한 이유가 없습니다. 굳이 MS의 입장에서 신경쓰이는 부분은 사소하지만 Wine과 같은 프로젝트를 잘못 건드렸다가 반독점 이슈에 휘말리는 상황 정도겠지요.

gcj는 gcc와 대응되는 GNU 자바 컴파일러입니다. Classpath는 GNU 환경에서 자바 프로그램을 실행하고 컴파일하기 위해 필요한 J2SE 코어 API 구현물입니다.

gcj 프로젝트는 gij를 통해 Sun Java의 java 명령 처럼 자바 프로그램을 인터프리트 방식으로 구동할 수도 있지만, 더욱 관심이 가는 기능은 gcj를 통해 자바 프로그램을 C/C++과 마찬가지로 JVM이 필요 없는 일반 바이너리로 컴파일 가능하다는 점입니다.

현재 데스크탑 자바의 가장 큰 걸림돌은 속도가 아니라 JRE의 패키징입니다. 최신 버전의 Classpath와 최신 버전의 자바를 비교해보면 주로 스윙 관련 패키지가 부족함을 알 수 있는데, 반대로 생각하면 SWT를 이용할 경우 GCJ/Classpath를 통해 자바 언어로 JRE가 불필요한 완전한 네이티브 GUI 어플리케이션을 만들 수 있다는 뜻입니다. 또한 SWT의 특성상 하나의 소스로 윈도우즈, 리눅스(GTK2, Motif, Fox), 맥 OSX 등을 동시에 지원할 수 있다는 강점이 있습니다.

아직은 특히 윈도우즈 플랫폼에서 GCJ 컴파일에 어느 정도 어려움이 있지만 azureus, g2gui(몇일 전에 이미지 갤러리에 올라왔던 mldonkey 공식 GUI 클라이언트), rss owl등 이런 방식으로 빌드된 SWT 기반 데스크탑 어플리케이션들이 인기를 끌고 있는 점을 보면 빠른 시간 안에 오픈소스 자바 진영의 표준적인 GUI 개발 방법으로 자리 잡을 것으로 생각합니다.

사실 모노의 경우 GTK#으로 인해 더욱 주목받고 있지만 자바의 경우도 Java-GNOME이라는 GTK/GNOME 바인딩이 있습니다. 하지만 SWT나 스윙, SwingWT, wx4j등의 여러 크로스 플랫폼 대안들이 있기 때문에 크게 주목 받지 못하는 점도 있습니다.

흠...

저는 gcj/classpath가 Java나 .Net에 상응한다고 생각지 않습니다...

Java나 .Net이 주장하는 가장 중요한 특징은 바로 Independence입니다...

Java에서는 Platform Independence를 .Net에서는 Language Independence를 주장합니다... 뭐... .Net도 Platform Independence를 한다고 하지만, MS의 전략상 그건 불가능하다고 보고요...

Independence는 사실 엄청 중요한 개념이라고 봅니다... 특히, 프로그램들이 기기를 옮겨다니면서 컴파일 없이 사용될 수 있다는 것은 상당히 중요한 부분이죠...

핸드헬드나 모바일, 나중의 유비퀴터스 환경 등등에서 재컴파일 없는 코드의 활용은 꽤나 중요한 부분이겠죠.

그런 면에서 GCJ/Classpath Project는 Java나 .Net과는 보는 그림 자체의 크기가 다르다고 봅니다...

Java나 .Net이 전략가들의 산물이라고 본다면, GCJ/Classpath의 경우 전장에서 잔뼈가 굵은 장수의 모습이라고나 할까요...

물론, 아직 완전히 구현되지도 않았고 헛점도 무지 많은 개념이기는 하지만, 저는 Java의 WORA가 마음에 드네요... 또 그렇게 되는 것이 세상을 위해서도 유익한 거 같구요...

자주 나오는 이야기입니다만, JVM의 언어 독립성에 대해서는 다음 페이지를 읽어보시고 말씀해 주시기 바랍니다.

http://www.robert-tolksdorf.de/vmlanguages.html

*현재* 상황만 보면, JVM에서 돌아가는 언어가 .NET에서 돌아가는 언어보다 많습니다.

--feanor

허허... 이거참...

좀 전에 GCJ site에 가보고 왔습니다...

간단하게 몇몇 문서를 읽어보고 왔는데요... 젠장...

뭘 좀 알고 글을 올려야 겠군요... 잘 모르는 상태에서 생각없이 글을 올리면 안되겠다는 생각이 듭니다...

간단하게 제가 잘못 알고 있었던 부분을 정리하자면, GCJ는 그냥 Native Code만 생성하는 건 아니더군요...

1. .java file -> architecture specific output

2. .java file -> .class file (이후에 Java로 실행하면 됨다...)

3. .class file -> architecture specific output

이런 정도 되네요...

함부로 말하면 안되겠습니다... GCJ를 만들기 위해서 노력하시는 분들께 죄송한 마음이 드네요...