누가 자바를 느리다고 했나?

geekforum의 이미지

오늘도 인터넷을 뒤지다 제임스 고슬링의 인터뷰 기사가 있어서 관심있게 읽어 나가다 지금까지 당연시 되어왔던 문제인 자바의 실행 속도에 관한 언급이 있어 글을 씁니다. 자세한 내용은 관련 링크를 참고하세요.

요는 "자바는 느리다고 주장하는 것이 최악이다. 현재 사용되고 있는 JIT 컴파일러는 탁월하다. 벤치마크 결과 C와 C++ 코드를 앞섰다. 사용자가 사용하고 있는 칩셋을 정확히 알고 있기 때문에 일반적인 최적화가 아닌 칩셋에 맞는 최적화를 할 수 있다. 정적인 컴파일러는 프로그램에서 무엇을 수행하는지 알지 못한다." 라는 말인데 정말 맞는 건지 궁금해 집니다.

뭐 저도 자바로 개발을 하지만 저는 주로 서버쪽(JSP,Servlet,Bean)이라 자바의 실행 속도 보다는 다른(네트웍) 부분이 더 속도에 있어 민감한지라...이 부분에 대한 여러분들의 견해나 경험을 듣고 싶습니다.

익명 사용자의 이미지

^^
자바자체가 느리고 빠르다고 말해봐야 소용없을듯 한데요.
대부분 사용자들은 MS환경에서 자바를 돌려 봤을때나 LINUX환경 같은데서 돌려보고 느리다고 말하는거고 SUN에서는 자신들의 OS에서 돌려서 느리지 않다고 말하는 걸껍니다.

예전에 친구하나가 자바가 느린줄 알고 있었는데 스팍머신에서 돌려보고 이렇게 빠른줄 몰랐다고 하더군요. ^^

MS의 .NET인가... (전 여기에 대해서는 잘모릅니다. 미리 밝혀둡니다. 오해의 소지가 없도록..^^;) 다른 OS에서 사용이 안되는 걸로 알고 있습니다.(다른 OS를 지원할 예정이라는건 빼겠습니다.)

썬의 OS의 경우 현재 많은 부분을 JAVA로 대체하고 있다고 알고 있습니다.(틀렸다면 ^^ 이해를......) 위에 자바가 느리지 않다고 한 말도 이 맥락에서 이해해야 되지 않을까요..^^

지나가다 생각나서 주절거려봤습니다.

익명 사용자의 이미지

고만쓰고 집에가서 잠이나 자~

익명 사용자의 이미지

체감속도를 보면....

익명 사용자의 이미지

점점 격화되는군요.

(참고로 저도 자바를 하는 사람입니다.)

자바 하는 사람들 끼리도 자바의 단점을 얘기하고,

자바를 하지 않는 사람들과 각 언어의 장단점을 얘기하곤 합니다.

결론은 대부분 XX는 이래서 안되~ 식이 아닌

~~ 했으면 더 좋았을 텐데..로 끝납니다.

무조건적인 상호 비판은 시간낭비&감정싸움일 뿐입니다.

단순히 저 글을 제가 받아들이는 입장에서는

'누가 자바를 느리다고 했는가' 라는 말은

분명히 마케팅적 요소가 섞여있는 말이지만,

무조건 빨라졌다라는게 아닌

'예전에 생각하는 것 만큼 느리지는 않다'

라는 의미를 내포하고 있습니다.

(또한 개발자들간의 이런 논쟁(?)을 불러일으켜서

광고효과를 극대화하는 방법이기도 하지요.

MS에서도 이런 방식을 자주 취하죠.^^;;)

빠르다는 말도 관점에 따라서는 매우 다르게 해석될 수 도 있구요

그리고 JCP에 대한 좋지않은 (그렇지 않은 얘기들도 있었지만) 내용들이 많은데

Apache의 강력한 요청으로 점점 개방적으로 변해가고 있습니다.

아래 링크는 6월 25일 자로 http://servlets.com 에 올라온 내용입니다.

http://www.servlets.com/blog/archives/000028.html

Apache has signed a newly formed (and much improved) TCK License covering all the JSRs on which it's active, allowing Apache to continue participating in the JCP. This new TCK License is becoming the Sun boilerplate and promises to bring benefits to all JSR licensees, both commercial and open source, by allowing true legitimate independent implementations of Java technology for the first time.......

조기태의 이미지

lamp님, 일단 당신의 인신공격이나 도배에 가까운 동어반복식의 억지 주장들은 무시하겠습니다.

당신의 처음 글에 대해 조목조목 반론을 제기했지만, 당신은 모바일 기기에 대한 라이센스 부분을 제외하면 어떠한 논리적 주장도 제시하지 못했습니다.

모바일 라이센스에 대한 부분은, 대부분의 개발 툴킷이나 관련 패키지는 J2SE와 마찬가지인 무료로 다운 받아 사용할 수 있는 BCL이 적용되고 있습니다.

모바일 기기에 탑재되는 J2ME profile이나 configuration은 호환성 테스트를 위해 라이센스를 받아야 합니다. 아마 이부분을 가지고 그토록 광적으로 "MS천국 자바 지옥"을 외치고 다니는 것 같은데,
이게 문제가 있다면 대안을 한번 제시해 보시지요.

휴대폰에 모노를 탑재해서 쓸 수 있습니까? 쓸 수 있다고 해도 그게 2-3년안에 국가 표준으로 실현될 수 있습니까? 아니면 MS는 모바일 관련 기술을 공짜로 제공합니까? 윈도우즈나 비주얼 스튜디오는 공짜입니까?

무슨 썬사가 소프트웨어로 세계 정복을 꿈꾸는 '악마와 같은 존재'인양 묘사했는데 도대체 MS의 패스포트나 XP의 라이센스 정책 같은 건 알고 있기나 한지 모르겠습니다.

전 세계 데스크탑 시장의 90% 이상이 MS제품입니다. 도대체 휴대폰에 탑재되는 J2ME를 무료로 안준다고 악마니 뭐니 한다면 그보다 훨씬 비싼 데스크탑 OS를 한 회사가 독점하는 상황은 어떻게 생각하십니까?

모노는 몰라도 임베디드 리눅스는 대안이 될 수 있을지 모릅니다. 저도 썬이나 MS같은 기업의 제품보단 오픈소스 진영의 소프트웨어가 모바일 기기에도 사용될 수 있다면 좋겠습니다.

하지만 그렇다고 MS보다는 훨씬 오픈소스 진영에 가까운 썬이나 자바 개발자 일반에 대해 근거 없는 비방은 삼가해 주시기 바랍니다.

그리고 만일 게시판 관리자님께서 이글을 보신다면 최소한 직접적으로 상대방을 지목하는 비방이나 욕설, 혹은 동일한 주장을 반복하는 도배에 대해서는 점수를 내릴게 아니라 삭제해 주셨으면 좋겠습니다.

그럼...

익명 사용자의 이미지

당신이 나의 주장에 조목조목 반박한 내용이 전혀 없을뿐만 아니라 오히려 논의의 핵심을 비껴서 나를 인신 공격적으로 깍아내린 것 외에 나는 어떠한 글도 보지 못했습니다.
그리고 분명히 언급했지만 모바일기기는 컴퓨터 탑재 기기의 아주작은 일부일 뿐임을 밝혔지만 그점을 의도적으로 계속 무시하고 있는데 그 점에서 당신의 의도가 불순하다는 점을 엿볼 수 있습니다.
저는 마이크로소프트를 두둔한 적이 없고 마이크로소프트를 적대세력화해서 반사적 이익을 얻고 있는 것은 오히려 썬사이고 그것이 또한 썬사의 전략이기도 합니다.
마이크로소프트사의 비주얼 스튜디오는 많은 개발도구중의 하나일 뿐인데 그것이 전부인양 말하는 것도 당신의 억지일 뿐입니다.
리눅스에서는 KDevelop이라는 좋은 공짜 개발도구도 있으며 아마 멀지않은 시기에 여기에 모노의 결과물도 통합되리라 믿고 있습니다.
저는 상대를 특별히 지목해서 비방한 것이 아니라 근거도 없이 나를 불순한 의도로 비방하는 사람에게 한번 자신을 되돌아 볼 기회를 제공했습니다.
당신이 벌레나 주워먹는 괴물이라고 밝혔었는데 그렇다면 이런 곳이 아니라 썬사의 시궁창이나 뒤져보는 것이 좋을 듯합니다.

권순선의 이미지

게시판이 더이상 지저분해지기 전에 두분은 이 주제에 대해 더이상 글올리기를 자제해 주십시오. 찾아다니면서 -1점 매기기도 귀찮고 글 지우는건 더 귀찮습니다.
--
WTFM :-)

익명 사용자의 이미지

조기태씨 글에도 -1을 부여하여야 공평하지 않겠습니까?
균형감각을 가지고 읽어보세요
그리고 ip를 보시면 그분의 글을 모두 알 수 있을 것인데

조기태의 이미지

제가 쓴 글은 모두 실명으로 작성했습니다. 당신의 글만 -1인 것은 익명의 글은 기본적으로 -1 점이 부여되기 때문입니다.

저는 순선님 말씀대로 토론에서 빠지겠습니다. 하지만 위의 글에서 제 글만 삭제된 건 납득할 수 없습니다. 긴 이야기는 하지 않겠지만 '마약중독자'니 '벌레나 주워먹는 괴물' 같은 식의 인신공격과 도배에 가까운 반복적 주장들이 그대로 남아있는데 단지 직접적인 욕설이 들어갔다고 제 글만 삭제 하는 건 이해가 가지 않습니다. 그런 경우라면 저 역시 얼마든지 좀 더 '세련된' 인신공격으로 게시판을 도배할 능력은 있습니다.

어쨌거나 진흙탕 싸움에 말려들어 게시판을 어지럽힌 건 분명한 제 실수이며, 그 점에서는 순선님과 게시판에 오시는 다른 분들께 진심으로 사과드립니다.

권순선의 이미지

잘못 알고 계십니다. 기본 점수는 실명이 1점, 익명은 0점이며 -1점은 점수 관리자(현재로서는 저 혼자입니다.)가 별도로 조정을 해야만 주어집니다.

제가 글을 지운건 직접적인 욕설이 포함되었기 때문이지만 인신공격은 할수 있더라도 정말 그러는 일은 없으면 좋겠군요.

그리고 저 역시 더이상 직접 글까지 올려 가며 중재하기도 귀찮고, 글을 왜 지웠는지, 점수는 왜 다르게 매겨 두었는지 일일이 설명하기는 더욱 귀찮군요. 그냥 그런가 보다 하고 넘어가 주십시오. :-)

온라인 상에서 의견충돌이 있을때는 본인 스스로 자기 감정을 컨트롤하기 어렵다고 생각되면 더이상 글을 올리지 말고 무시하는 것이 상책입니다. 자기 생각에 아무리 상대방이 잘못되었다고 하더라도 자제력을 잃고 계속해서 싸우다 보면 결국은 둘다 스타일 구기게 마련입니다.
--
WTFM :-)

lamp의 이미지

조기태씨 글이 사실인지 확인차 등록했는데 권 선생님 답변을 보니 괜한 짓 했네요. 제가 -1받은 경우가 워낙 많다보니..
피곤하시면 제가 점수관리 해드릴 수도 있습니다.

익명 사용자의 이미지

아마 오라클도 헛짓(자바기술적용)하다가 망할가능성이 상당히 높다고 볼 수 있음.

linux apache mysql php 나 시간나면 심심풀이로 봐 두시요

자바 광신도님들께 권함.

익명 사용자의 이미지

글쓴이 : lamp

다시한번 수고하겠습니다.

썬사는 모든 것을 컴퓨터로 제어하는 것을 미래 사회의 모습으로 가정하고 있으며 JVM이 핵심적 역활을 하도록 만들려고 하고 있습니다.

지금은 사용자와 개발자 그리고 우호적 기업을 늘이는데 사력을 다하고 있습니다.
그러나 썬사의 의도대로 될 경우 그 결과는 재앙으로 나타나게 될 것입니다.
현명한 사람이라면 자바에 시간을 투자하지 말아야 합니다.
단지 입문이 쉽다는 이유때문에 이런 언어를 익힌다는 것은 정말 위험한 생각입니다.

엘지 텔레컴에서 자바기술을 이용하지만 기기하나마다 적지 않은 비용을 지불하고 있습니다.
만약 시간이 지나서 집안의 모든 전자제품에 작고 싼 컴퓨터가 장착되고 제어를 자바기술을 통해서 하게 될 경우 비용은 국가적으로 상상할 수도 없습니다.
그리고 라이센스가 개별 기업별로 이루어지게 될 것이므로 지금의 MS에 지불하는 세금과는 차원이 다릅니다.
즉 소비자로서는 선택권 자체가 박탈되어 버립니다.

썬사의 CEO는 악마와 같은 존재임을 알기 바랍니다.

저는 MS직원이 아니고 MS를 좋아하지도 않으니 썬사의 광신도들이 제게 퍼붓는 비난에 신경쓰지 마십시오.

저는 MS에서 자바기술을 2년후 완전 제거할 계획이라는 데 적극적으로 찬성합니다.
저는 아예 JVM이 구동조차 되지 못하도록 조치를 취했으면 하는 것이 제 바램입니다.
98%의 컴퓨터에서 문제가 생기는 JVM은 당연히 퇴출될 것입니다.

익명 사용자의 이미지

대안?

번잡하지만 임베디드리눅스가 있을 수 있고
사용되는 프로그램이 이종플랫폼이나 다른 운영체제사이에 호환이 필요하다면 모노가 있을 수 있습니다.
여기에 대해서도 썬사의 광신도는 악담을 하겠지만 이제 시작일 뿐이니 신경 쓰지 마십시오.

자바가 처음 나올때를 상상하시면 되지요. --> 되는 것이 별로 없던 시절을.

오히려 모노는 사정이 훨씬 나을 것입니다.

익명 사용자의 이미지

누가 자바가 느리다고 했나?
이런 질문에는 기존에 자바는 느리다는 통념이 있었다는 것을 말하는 것 아닌가?

그리고 속도에 대해서는 비교의 대상이 있을 것이고 그러니 C,C++,C#같은 언어들이 언급될 수 밖에!

그런데 그런 언어에 대해 언급하면 자바를 비난하는 것인 양 과민반응을 보이는 작자들은 제정신이 있는 인간들인지?

익명 사용자의 이미지

썬사는 멀지 않아서 망할 것이 확실하니 빨리 자바같은 망상에서 헤어나길 빕니다.

하드웨어도 별 볼일없이 비싸기만 하고 소프트웨어는 속이 뻔히 보이는 짓만하니 망하는 것이 당연하지.

망하는데 4년도 걸리지 않을 것임을 확신함.

자바?
당연히 퇴출되지!

익명 사용자의 이미지

원래 자신의 주장에 자신없는 인간들이 상대의 표현에 시비를 걸면서 논의와는 관계없는 인간성을 문제삼다가 상대의 주장까지 도매급으로 평가절하하지.
썬사의 정책이 문제이기 때문에 자바기술이 보편화 되는 것은 많은 문제가 있다는 주장을 하는데 자바라는 마약에 빠진 인간들은 표현이나 태도에 문제를 제기하면서 주장자체를 비난한다.
도대체 논리나 상식이 전혀없는 인간들이 자바만세만 외치고 있으니 자바는 망할 것이다.

그런 비논리적인 인간이 주장하는 것은
결국 자바亡世! 代代孫孫亡世!
라는 것을 깨달도록

익명 사용자의 이미지

원래 자신의 주장에 자신없는 인간들이 상대의 표현에 시비를 걸면서 논의와는 관계없는 인간성을 문제삼다가 상대의 주장까지 도매급으로 평가절하하지

=> lamp라는 사람 말입니까?

익명 사용자의 이미지

You! java fanatic!

익명 사용자의 이미지

lamp님께. 이건 가슴에 손을 얹고 말하건데 비꼬는 의도가 아님니다만, 자신의 성격에 심각한 문제가 있지 않은지 반성해 보시기 바랍니다.

아래 글들을 천천히 처음부터 다시 읽어 보시고 누가 먼저 인신공격을 했는지, 또 누가 상대방의 논리에 대해 논리가 아닌 우격다짐식의 동어 반복으로 게시판을 난장판으로 만들었는지 객관적으로 판단해 보시기 바랍니다. 애초에 님이 정신이 나간 헛소리라느니 마약중독자라느니 하는 식의 인신공격 대신 정확하게 논리로 대응했다면 jcp 관련 이야기 같은 건 나오지도 않았을 겁니다.

개인적으로 자바에 무척 애착을 가지고 있지만 님처럼 상대 진영에 대해 맹목적인 반감을 가지고 있지도 않습니다. #C, 닷넷 다 좋습니다만 MS의 영업사원이 아닌 개발자로 남으시려면 광신도는 되지 마시기 바랍니다. 저도 자바를 좋아하고 MS보다는 썬에 호감을 가지고 있는 건 사실이지만, 논리적 비판이라면 얼마든지 받아들일 자세가 되어 있습니다.

이글에 어느 정도 공감하실 수 있는 분이라면 부디 다음부터는 이성적인 모습으로 토론에 임하는 모습을 보여주셨으면 합니다. 만약 이런 글로도 무언가 떠오르는게 없다면... 글쎄요 정말 불쌍한 분이군요.

익명 사용자의 이미지

무언가를 이루는 것은 어떤 방법으로든 가능합니다.
다만 누가 먼저 시작하고 얼마만큼의 노력을 투여하느냐가 관건일 뿐
문제는 그걸 통해서 그들이 무엇을 얻으려 하느냐가 중요합니다.
나는 그점에 대해서 언급했는데 많은 사람은 그 점을 이해를 못하거나 아니면 이해하기 싫거나 둘중하나인 것 같아 보입니다.
그리고 당신은 대화의 시간상 선후관계를 따져보지 않고 무조건 나의 글을 문제삼는다면 그건 당신에게도 성격은 달라도 마찬가지의 문제점이 있다고 볼 수 밖에요.
내가 보인 반응은 당연히 그런 반응을 받을 만한 사람에게 가해진 것이니 당신이 그런 부류가 아니라면 시간낭비하지 마시요.

Clyde Lee의 이미지

저는 C#, java 둘다 잘 모릅니다. 그래서 용어가 이상하더라도 이해해 주기 바랍니다.

.NET과 JVM 서로 치고 받고 하다가 서로 거의 똑같은 모양이 되지 않을까요 ?

JVM(?)쪽도 java만이 아닌 languge를 VM에서 실행되게 VM만드는 회사들이 '정식'으로 지원하고, VM도 커널안으로 들어가고( .NET의 개념이 앞서 있는것 같아 JVM쪽이 .NET을 벤치마킹 할거라고 생각했습니다. 마찬가지로 .NET도 JVM의 장점을 벤치 마킹 하겠지요..)

이럴 거라고 생각하는데 다른분들은 어떻게 생각하는지 ?

익명 사용자의 이미지

글쓴이 : lamp

인신공격적 발언들이 나오는 것을 보니
상당히 밥줄이 염려되나 보군요.

삼성멀티캠퍼스같은데서 돈받고 교육시키면서 시험까지 대행하지 않는지? 그곳은 학원 아닌가?

그리고 지방의 몇몇대학도 썬사에서 서버설치해주면서 대행계약을 맺은 걸로 알고 있는데

jcp나 scjp나 내가 전달하려는 의사와 부합하면 그만 아닌가? 웬 헛소리 당신은 영어도 못하나?

바보같은 짓 그만하고 내가 쓴 글에 대해서 설득력있는 반박이나 해보세요

조기태의 이미지

영어 잘하시나 보지요? 그럼 다음을 해석해보세요 :

JCP = Java Community Process
SCJP = Sun Certification for Java Programmer

앞으로 당신이 쓰는 모든 글은 무시하겠습니다. 참고로 토익은 900이상 받았습니다, 걱정해주셔서 고맙군요.

익명 사용자의 이미지

bird :

이런 이런 몇일 만에 들어 왔더니
이런 일이 또 발생 했군요..

조기태 님..
미리 예고 해드리지 못해 죄송합니다.
아래의 분석글을 참고하시고, 흥분을 가라 앉히시기 바랍니다.

lamp 에 대한 분석은 아래와 같습니다.
(lamp 에 대한 존칭은 생략합니다. 저는 아무에게나 존칭을 쓰지는 않거든요 ^^ )
이제까지 kldp 에 올린 lamp 의 글들을 통해서 나름대로 분석한것입니다. )

1. 그는 나이가 많다.
2. 늦은 나이인, 최근에 (1 ~2 년정도) 프로그래밍에 입문 했다.
3. 물리학인가를 전공했다.
4. 최근에 java 와 C#을 접했다.
5. 선배인가 누구인가에게 java등에 대해 조언을 구했다.
6. 나름대로 java 와 C#에 대해 분석하고, 판단 한것 같다.
7. C#에 비해, java 는 이미 5 ~ 7 년의 성장기를 거쳐서 현재는 성숙기에 도달했다고 판단했다.
( 물론 c, c++은 분석, 판단할 것도 없지요 )
8. 그래 이 나이에 java를 지금 시작한 들 뭐 먹을게 있겠냐 ?
이제 태동기에 있는 C# 에 "쇼부"를 걸자 !!! 라고 나름대로 판단한 것 같다.
9. "쇼부" 를 걸자 사고가 경직된 듯한 글들을 써댄다.

10. 그래도, 그는 비겁하게 이름을 숨기지는 않고
글을 쓸때는 lamp라는 것은 밝힌다.

익명 사용자의 이미지

글쓴이 : lamp

첨가하다면 나는 프로그래밍을 밥줄로 생각한다기 보다는 놀이정도로 생각하고 있음.
그리고 나는 이쪽을 객관적으로 보려고 노력하고 있고 사고가 너무 자유스러운 것이 문제라는 말을 들을 정도로 경직하고는 거리가 있는 사람입니다.
프로그래밍에 입문한 시기는 정확하게 19년전임.
내가 놀이정도로 대했으니 겸손해질 수밖에 없는 것이지 밥줄로 생각했다면 사정이 달라졌을 것입니다.
그리고 자바는 태동할 무렵부터 관심을 가졌음

이곳에 대단한 사람들도 들릴거라는 판단에 글을 겸손하게 올렸더니 아주 우습게 보는 구만.

물론 그런 인간들 어떤 인간들인지 알만하지만.....

익명 사용자의 이미지

글쓴이 : lamp

'Java 자격증 프로그램'
이라는 뜻으로 쓴 것이니 시비걸지 마시오

당신같이 따지자면 썬사의 자격증 종류별로 모두 거론해야 될 것 아닌가?
당신 머리가 나쁘다는 것은 이제 알았소

썬사에서는 위와같은 명목으로 자격증을 자꾸 늘여가고 있지 않은지?

실제로 몇몇 대학에서는 특기자 입학요강에 통칭해서 jcp라는 명칭을 사용하고 있음.

내가 잘못 사용한것 아니니까 그만 따지시요.

익명 사용자의 이미지

www.sun.co.kr 에가서~~~
검색어에 jcp 하고 scjp 두번만 검색해보세요

능력된다면 www.sun.com 도 좋고요...

익명 사용자의 이미지

아직도 본질 파악을 못하시는군요.

다른 사람의 의견을 "위원회니 뭐니 말도안되는 헛소리"라고 한마디로 묵살하실 수 있는 분이 바로 그 위원회를 뜻하는 JCP와 자바 자격증 시험도 구분 못하시니 딱해서 그러는 겁니다.

익명 사용자의 이미지

등신아 scjd도 있다
그럼 통칭해서 뭐라고 할까?
썬사의 홈에 통칭해서 위와같은 표현이 있으니 찾으려고 노력해 볼 것.

원래 프로그래밍한다고 껍죽되는 인간들 중에 병신들 많은 줄 알고는 있었지만.....

조기태의 이미지

죄송합니다. 제가 어리석었군요. 개가 짖어 대는데 마주 소리를 질러댔으니 입만 아프군요.

익명 사용자의 이미지

개 눈에는 모든게 개로 보이는 법!

익명 사용자의 이미지

글쓴이 : lamp

허허 열받으셨네요
저는 자바에 대해 당신같이 잘 알지 못하니 어떻게 조목조목 당신의 글에 답변을할 수 있겠습니까?
저는 앞으로도 자바하고는 담쌓고 살 생각이거든요.
당신이 잘못알고 있는 것만 언급하겠습니다.
여러회사에서 자바의 서버사이드 프로그램을 양산하는 것은 썬의 정책이 주요한 것 때문이지 자바의 성능이 월등해서가 아닙니다.
그리고 자바의 태생자체가 기계제어를 하기위한 표준화된 명령에서 아이디어가 나온 것이고 이것이 오늘날 웹쪽에서 성공한 것은 웹의 특성이 이와 유사하다는 것 때문 아닙니까?
그러나 진정 자바가 생활 곳곳에서 사용될 가능성은 원래의 의도대로 모든 곳(집. 가전제품. 자동차. 휴대폰 등)에 컴퓨터를 장착하고 거기에 버추얼머신을 탑재하여 컴퓨터로 제어가 가능하도록 하는데 있습니다.
당신은 휴대폰만 생각하시는데 앞으로의 사회에서 그것은 컴퓨터가 장착된 물건의 하나일 뿐입니다.
따라서 썬에서는 일반 PC나 서버의 JVM에 대해서는 관대한 정책을 펴면서 자바의 보편화를 추구하고 있지요.
정말 그들이 노리는 것은 숫적으로 몇십배 내지는 몇백배가 될지 모르는 컴퓨터탑재 전자기기들에서의 JVM사용료입니다.

제 생각으로는 썬의 의도대로 이루어진다면 이것은 우리에게 선택권이 없는 세금을 지불하게 할 수 밖에 없을 것입니다.
왜냐하면 개인과의 거래가 아니라 컴퓨터를 탑재한 물건을 생산하는 기업과의 거래가 이루어지기 때문입니다.
더구나 썬사가 국가나 기업별로 차별정책을 펼 경우 그것이 우리의 산업경쟁력에도 영향을 미칠 수가 있습니다.
제가 생각할 때 MS가 밉고 자바가 배우기 쉽다고 맹종하는 사람들은 마약흡입의 초기단계 환자와 같다는 생각을 하게 됩니다.
자바는 어떠한 경우에라도 도태되어야 합니다.
저도 MS를 미워하지만 C#과 모노는 자바의 대체재로 훌륭하다고 생각됩니다.
능력되신다면 모노나 유사프로젝트에 참여하여 자바를 대체하는 데 앞장이나 쓸 것이지 불평은 하지 맙시다.

조기태의 이미지

당신이 MS직원이든 추종자든 간에 근거를 들어 반박할 능력도 없다면서, 자신의 생각에 반대하는 사람을 마약중독자니 헛소리를 해대느니 매도하는 것은 인격적으로나 전문지식면에서 토론에 참여할 자질이 없다는 걸 나타낼 뿐입니다.

당신이 자바를 싫어한다고, 혹은 닷넷을 추종한다고 뭐라고 한 사람 아무도 없습니다. 다만 근거도 없는 MS선전이나 썬에 대한 비방은 다른데서 하시기 바랍니다. 여기는 논리적으로 토론을 하는 곳이지 당신과 같은 사람이 함부로 글을 올릴 곳이 아닙니다.

익명 사용자의 이미지

첨가

제 생각은 몇년전 한국썬의 부사장이 세미나에서 한 발표를 듣고 제가 내린 판단임을 밝힙니다.

사실 요즘 썬에서는 많은 아군을 확보하고자 JCP를 막 찍어내고 있습니다.
제말이 의심스러우면 알만한 학원이나 시험에 관심있는 주위분에게 물어보세요.

글쓴이 : lamp

조기태의 이미지

웃다가 죽을뻔 했습니다 ㅡ.ㅡ;;;

혹시 JCP를 SCJP와 착각하시는 것 아닙니까? JCP는 학원이나 시험과는 아무런 관계도 없습니다.

당신이야 말로 알만한 사람, 아니 직접 웹 사이트에서 최근에 있었던 오픈소스 논쟁에 대해 확인해 보시기 바랍니다. 근거를 대던가 괜히 토론장 물흐리지 말고 다른데나 알아보시기 바랍니다.

익명 사용자의 이미지

글쓴이 : lamp

남의 것 사서 쓰는 입장에서는 어느쪽이든 한쪽이 압도하는 상황은 좋지 못하지요.
하지만 결국에는 한쪽이 주도하고 한쪽이 사라지게 될 수 밖에 없을 것입니다.
제 생각에는 C#이 주류로 남고 자바는 세력을 작아지다가 한때 사용되던 기술정도로 치부되어질 것이라 생각합니다.

이유를 들자면

1. 성능이 기대에 못 미친다. 아울러 성능개선이 너무 더디다.

2. JVM을 돈벌이로 생각하고 있는 썬사의 정책 - 모르는 사람이 많은 것 같은데 썬사는 PC에는 공짜로 사용하게 하지만 임베디드 기기에 장착되는 JVM에 사용료를 받으려 하고 있습니다. 그리고 향후 이런기기(휴대폰등)들이 기하급수적으로 늘어날 것이 필연적임을 생각할 때 자바는 사장되거나 유사기술로 대체되는 것이 바람직합니다.

3. 너무나 강적을 두고 있다. - 이 부분도 오해하시는 분이 많으신데 마이크로소프트가 강적의 한축이지만 다른축은 Copyleft 지지자들이라는 것을 잊고 있습니다. 리눅스 사용자들이 자바를 꺼리는 데는 그럴만한 이유가 있습니다. 그리고 이런 사람들이 모노프로젝트를 추진하고 있습니다.

여기서 C#을 생각할때 너무 MS만을 염두에 두고 비난하시는 분들이 많은데 C#의 탄생은 따지고 보면 썬의 JVM에 대한 독점에 기인한 것임을 알아야 됩니다.
썬사는 JVM을 배타적으로 관리함으로써 향후에 얻게될 이익을 고수하려 하였는데 MS는 이것을 간파하고 이것의 변형을 꾀하다가 썬사의 소송에 걸려 실패한 후 아예 유사상품 개발로 방향을 바꾸어 생겨난 것이 C#입니다.
자바의 궁극적 목적은 우리의 생활 전영역에 보편적으로 도입되는 것이고 핵심은 각종 임베디드 기기에 장착되는 JVM입니다.
그러니 썬사가 JVM의 관리를 포기하겠습니까?
제대로 상황판단을 못하시는 분은 위원회니 뭐니 말도 안되는 헛소리만 하시는 데 MS가 썬사와 문제를 일으킨 부분이 JVM이었고 SK텔레컴에서 유사기술을 휴대폰에 도입하려다 문제가 된 것도 바로 JVM입니다.
JVM을 자유로이 개발하고 사용할 수 있다면 왜 MS SK가 소송이나 협박에 돈을 지불할까요?

조기태의 이미지

>>제대로 상황판단을 못하시는 분은 위원회니 뭐니 말도 안되는 헛소리만 하시는 데

이게 저를 지칭하는 거라면, 먼저 기본적인 토론 자세도 안되어있는 님 같은 사람에게 일일이 답장을 다는게 시간낭비일 수도 있겠군요.

먼저 모바일 기술과 관련한 썬의 라이센스 정책은 저도 잘모릅니다. 하지만 서버 사이드와 클라이언트 기술, 그리고 MS의 VM변형에 대한 논란에 대해서는 님이 올리신 글 정도 보다는 더 자세히 알고 있다고 생각합니다.

성능개선에 대해서는 이미 관련글이 많이 올라와 있습니다. 비판을 하시려면 이제까지 나왔던 JIT, 하드웨어 성능, SWT등 논점에 대한 비판을 하시기 바랍니다. 무턱대고 "자바는 느리다"라면 싸움밖에 안되지 않을까요?

카피레프트 진영 - 저도 지금 이글을 리눅스에서 쓰고 있고 그놈 한국 사이트에서 버그질라 운영을 맡고 있습니다 - 의 자바에 대한 반감은 잘알려진바 대로입니다. 하지만 그렇다고 모노가 현재 자바의 주요 시장인 서버사이드와 모바일을 위협하리라고 생각하지는 않습니다. 모노측에서도 마이크로소프트와의 어떠한 연계 가능성도 부인하고 있고, 심지어 MS의 닷넷과 호환성도 보증할 수 없다고 합니다. 앞으로 모바일이 대세를 이룰지는 모르지만 그렇다고 서버나 클라이언트 시장이 없어지는 건 아닙니다.

그리고 무엇보다 최근 몇년간 서버 시장의 주류는 J2EE기술임을 부정할 수는없습니다. 님의 말씀대로 자바가 성능도 못 미치고 썬이 독점력을 행사하는 상품에 불과하다면 최근 몇 년간의 IBM, BEA, 오라클을 중심으로한 자바 관련 솔루션의 폭발적인 증가는 어떻게 설명하시겠습니까? 이들 회사가 자바 어플리케이션 서버를 만들면서 썬에 지불하는 비용은 호환성 테스트에 대한 비용이 전부입니다. 또 JBoss같이 완전히 오픈소스로 썬과 관계 없이 개발되는 어플리케이션 서버도 지속적으로 한달에 15만건 이상의 다운로드를 기록 중입니다.

마지막으로 MS가 JVM을 변형한 것은 무슨 썬의 독점을 막으려는 사명감에서 나온 것도 아니고, 반대로 자바 개발자들이 윈도우즈 전용 어플리케이션을 만드는 것을 도와서 궁극적으로 플랫폼 독립적인 자바의 장점을 없애려는 목적에 불과합니다. J++/J#을 써보셨는지는 모르지만 여러 면에서 자바 플랫폼 보다는 VC++이나 VB를 자바 문법으로 변형시킨 쪽에 가깝습니다.

썬이나 MS나 모두 이윤을 추구하는 회사임에는 분명하지만, 썬이 주로 자바를 활성화시켜 하드웨어나 어플리케이션 서버 판매를 늘이는 간접적인 방법에 치중하는 반면 MS는 모든 개발플랫폼, 운영체제, 서버 제품군을 통합해서 자사 제품 없이는 프로그램 개발이나 운영 자체가 불가능하게 하는 전략을 택하고 있습니다.

단적으로 J2EE어플리케이션 서버는 수심가지가 넘지만 MS이외의 닷넷 플랫폼 구현이 몇개나 됩니까? 그런 상황에서 썬의 독점을 막기 위해 MS제품으로 바꾸자는 논리는 넌센스에 가깝습니다.

토론을 하시고 싶다면 조목조목 구체적인 근거를 들어 비판을 해주시기 바랍니다. 무조건 "자바는 느리다", "썬은 나쁘다"는 식의 논리는 소모적인 싸움만을 가져옵니다.

그럼.

익명 사용자의 이미지

제가 하고 싶은말 그대로 입니다. 거기에 약간 더 붙이면

1. 성능 개선 더디다?
이건 이해를 못하겠습니다. 더 설명이 있어야지요.

2.상표, 라이선스 문제
썬에서 모바일에 대한 라이선스를 요구 하지 않습니다.
단, 상표는 요구하지요. 이게 무슨 말이냐면

모바일에 알맞는 자바 스펙을 구현해서 사용하는데는 상관 없다. 하지만
Java의 그 커피잔 모양의 상표는 sun에서 소정의 라이선스를 받아야 한다.

라는 것이지요.
그래서 sk의 vm의 경우 자체 vm을 만들고, 상표권 사용료를 지불했습니다.
제가 잘못 알고 있다면 지적해 주십시오.

3.너무나 강적 을 두는 점은
그런 반면에 너무나 강한 우리 편도 가지고 있습니다.
아파치 그룹과의 오픈 소스 협의가 잘 마무리 되었고, (이번 JavaOne)
MS 빼고 거의 모든 기업
그외에 오픈 진영 쪽에서는 꾸준히 sun에게 더 많은 권한을 풀라고 합니다.

또 한가지, objectworld 세미나에서 이런 말이 인상 깊습니다.

"MS는 구현 된것으로 이야기 하지만, Java는 스펙으로 이야기 한다."

의미 심장하지 않습니까?

익명 사용자의 이미지

자바든 brew 든.. 해당 기술을 사용하는 폰이라면 개발사에서 폰 한대당 몇달러씩의 기술사용료를 지불하는 걸로 알고 있습니다.
그게 상표권 사용료같은게 포함된건지 아닌지는 몰라도 말이죠.

얼마전에 KTF쪽에서 곧 라이센스가 만료되는 퀄컴 brew 의 재계약을 고려중이라는 이야기가 있었는데.. 확인된건 아니지만 퀄컴에서 brew 의 폰당 라이센스 비용을 올려서.. 그것때문에 KTF쪽에서 재계약 문제를 고려중이라는 이야기도 있었습니다.

LG 의 ez-java 역시 폰당 java 기술 사용료를 몇달러씩 내고 있는걸로 압니다만...

익명 사용자의 이미지

글 잘 쓰셨네요, 동감입니다.

익명 사용자의 이미지

흠... 데스크탑 애플리케이션을 만들 수 있고.. 등등.. 자바로도 못할게 없습니다만.. 그건 단지 머랄까.. 주의 장식일 여지가 있습니다. (심한 표현이지만 ㅡㅡ;)..
여하튼 이렇게 말하는 근거는.. 결국 자바가 먹으려는 시장은 서버 시장이고.. 실제로 돈되는 쪽이 그쪽이고... 또하나를 들자면 모바일쪽이 될 수 있을듯... 이방법 저방법을 개발해내면서 속도를 증가시키고 있지만.. 느린건 느린겁니다. 그걸 갖고 머라고 할 건 안된다고 봅니다. 또한 마찬가지로 .NET도 결국은 윈도 2000시리즈까지 오면서 MS가 독점하려 했던 시장인.. "서버" 시장을 먹기 위해서 나오는 거라고 생각합니다. 머 .NET으로도 못할게 없고.. 일반 데스크탑 애플리케이션도 만들지 못할 것도 없고.. MS 측에서는 선이 그랬듯이 일반 데스크탑 애플리케이션 개발에 있어서의 "한번 작성하면 윈도우즈에도 돌아가고 리눅스에서도 돌아가고.. 등등.."하는 그런 사탕 발림식 말을 할 것입니다.. 자바가 주는 교훈대로.. 결국은 "돈"이 되는 부분은 서버 시장.. 그리고 모바일 쪽을 겨냥해서 나온거라고 봅니다. 여하튼 느린건 느린거고.. 자바가 기존의 C/C++ 같은 언어와 다르게 많은 장점이 있고.. 또한 많은 단점이 있다고 생각하는데.. "생명력"이 있는 이유는.. EJB 등.. 그러한 서버 기술에 있지 않나 합니다. 추가로 .NET을 놓고 보자면.. 이미 운영체제나 DBMS나 웹서버나.. 그러한 점에서 열세에 있었던 MS가 많은 투자를 하면서 경쟁력을 높이면서.. 심지어는 더 낫다는 평가가 나올 정도로 그렇게 투자하면서 먹으려고 했던 시장이 바로 서버 시장인데.. 잘 준비해오다가 리눅스의 급부상이라던지.. 자바가 시장을 선점하는 등의 난점을 만나서 위기를 맞게 되었고 급하게 내놓은 것 (물론 꾸준히 준비를 해왔겠지만 미완의 상태에서 발표를 한..)이 .NET이라고 생각합니다. 여하튼.. 제가 말하려는 요지는.. 그러한 속도 논쟁.. 그리고 무슨 멀티플랫폼이니.. 그런게 장점이 물론 많이 됩니다만.. 실제적으로 볼때 썬이 자바를 통해 돈을 벌어들이고 있는 부분은 서버 시장이라는 점입니다. EJB같은 기술이 서버 시장에서 경쟁력이 높다면 자바는 계속 쓰일 것이고 썬은 돈을 벌여들일 것입니다. 그러면 계속 투자를 하고... 돈을 벌고.. 그렇게 되는 거죠..

익명 사용자의 이미지

자바가 빠른건 아니다.

프로그램이 잘 돌아가면 문제될게 없다.

이건 자바뿐만 아니라 베이직 ,c/c++ 같은 언어에도 적용된다고 본다.

자기 개발에 관심이 많은자는 한가지 언어에만 집착 하기 보다는 유사한 계열의언어도 공부해
보는것이, 나의 주력언어가 어느부분에서 좋고 나쁜지 알수있다.

익명 사용자의 이미지

자바는 태생 자체가 느립니다.
'버추얼 머신' 이게다 뭡니까 -_-;;;
하나를 얻으면 하나는 얻지못하는 것이 세상이치요... 이런글에 답하는 내손이 간지럽소..

-_-;;

익명 사용자의 이미지

문제의 본질을 파악하지 못하시는 군요. 제 손도 간지럽지만,
아래 글을 천천히 읽어 보시고 생각해보시기 바랍니다. 그리고
VM개념이 느리다면 왜 MS가 .NET을 VM으로 구현했겠습니까?

익명 사용자의 이미지

글쎄 왜그랬을까?

익명 사용자의 이미지

.net의 vm은 자바+alpha

익명 사용자의 이미지

자바 1.1.4 + alpha ;;

ps. 농담입니다. 자바보다 이론적으로 더 빠르다고 하지요. ^^;

익명 사용자의 이미지

뭐 복잡한 기술 이야기는 언급하지 않더라도..

.NET 자체로만 이야기한다면 JAVA 플랫폼처럼 VM까지는 거의 똑같습니다.

다만 거기에다가 중간코드를 윈도의 실행코드로 컴파일해주는 기능을 추가해서 속도면으로나 기타 측면으로 장점이 있는것이죠.

익명 사용자의 이미지

VM을 쓸일도 없고... 비베보다도 빨리
돌아갈꺼라 생각합미다.. 로딩도 없을테고..
서버에서는 죄다 지들게. 빠르다구 하는데..
윈도그내에서는 그러겠죠..

익명 사용자의 이미지

느리구만...

조기태의 이미지

클라이언트에서의 자바의 가능성을 보고 싶으시다면 JRE 1.4를 설치하고 http://www.up2go.net에 가보세요.

오늘 나온 1.4.1 베타에는 자바웹스타트 1.2가 포함되어 있습니다. 이는 JVM이 없는 윈도우즈 사용자가 익스플로러에서 JNLP어플리케이션의 링크를 클릭하는 것만으로 최신의 VM과 웹스타트, 그리고 웹스타트 어플리케이션을 동시에 설치할 수 있음을 뜻합니다.

제 생각에는 자바웹스타트, J2SE 1.5, 그리고 내년 이후의 하드웨어 사양이면 충분히 클라이언트에서 자바가 활성화될 수 있다고 봅니다.

그럼.

익명 사용자의 이미지

moonlight

아... java web start가 1.2로 업데이트 되었군요...
제가 사용했던 버젼이 1.0.1인가 였는데... 얼마나 변화되었을지...
내심 기대가 됩니다.

그리고... 올려주신 사이트 디게 cool한거 같네여..
구럼.. 즐거운 프로그래밍 생활~

익명 사용자의 이미지

moonlight

자바로 프로그래밍 하는 사람입니다. 구체적으로 언급하자면 JAVA3D를 이용해서 웹에서 3D를
구현하는 데요...

자바의 속도에 관련된 글을 최근 관심있게 읽게되었습니다.

자바의 속도에 관련해서 예전부터 많은 토론이 되어왔고 외국에서는 구체적인 벤치마크 테스트도 있어왔다고 생각합니다.

여기에 대해서 자바로 클라이언트 프로그램을 개발하는 입장(경력은 미흡합니다. -_-;;)에서 말하자면 '자바는 느리다'라는 말이 맞다고 생각합니다. 최소한 '느리게 보인다'라고 말할 수 있습니다.

사실 자바는 버젼업이 되어 가면서 속도향상에 관해서도 많은 발전을 이루어 낸게 사실입니다.

최근에 발표된 1.4.X대에서 보여지는 몇몇 데모 프로그램들은 '이것이 과연 자바가 맞나' 싶을 정도로 빠른 실행속도를 보여주기도 합니다.

그렇지만 여기서 간과 될 수 없는 요소는 과연 사용자들이 실제로 느껴지는 속도가 빠른가 하는 점입니다.

개인적인 생각입니다만, 사용자들이 보통 프로그램의 속도를 판단할 때 가장 민감하게 느껴지는 부분중에 하나가 바로 초기 로딩 속도라고 여겨집니다. 그리고 gui랜더링 속도도 그렇구요, 그런데 여러분들이 알다시피 자바는 그 두가지 요소에서 가장 큰 약점을 드러냅니다.

자바는 런타임적인 특성으로 인해 객체가 생성되어지는 초기에(즉, 로딩시에) 오버헤드가 많이 발생한다고 생각합니다. 물론 이 로딩이 완료되고 나면 재속도가 나오게 되겠지요, 그렇지만 일반적으로 사용자들은 긴 로딩시간에 상당한 거부감을 갖게 될 것입니다.

사용자들은 어플을 판단할때 단지 초반의 몇분 혹은 몇초 동안의 이미지에 따라 결정이 된다는 것을 생각할때, 이것은 나중에 빨리 작동되는 어플이라 할지라도 느리다는 인상을 지우기에는 쉽지 않다고 생각합니다.

또한, GUI의 경우 훌륭한 아키텍쳐를 갖고 있슴에도 실행속도와 반응속도의 문제로 인해 클라이언트에서 경쟁력이 떨어지는 것은 사실입니다. 최근에는 순수 JAVA로 만들어진 플그림도 많이 나오고 있는데(특히 이클립스는 마치 네이티브 환경인것 처럼 인상적이었습니다.) 개발자가 여간 신경을 쓰지 않는 이상 속도감을 요하는 플그림을 개발하기가 쉽지 않다고 봅니다.

제가 언급하는 부분은 주로 서버사이드에서 개발되어지는 JAVA어플과는 별로 관계가 없는 것일지도 모르겠습니다. 그렇지만 최근에 부상하고 있는 웹서비스도 궁극적으로는 클라이언트 측의 인터페이스를 무시하고서는 서비스라는 의미가 있을지 궁금합니다. 지금처럼 클라이언트와의 상호작용을 웹폼(.net식 표현을 빌자면...)으로 의존하는 것에는 한계가 있을거라고 생각됩니다. 이것이 점진적으로는 윈폼(역시 .net식 표현을 빌립니다. -_-;;) 형태로 변화되어 간다고 생각 되는데,

윈도 쪽에서는 ActiveX라는 형대로, 자바에서는 이것이 Applet이라는 형태로 클라이언트 쪽에서 구현됩니다. Applet이란게 처음에는 자바의 간판이라고 할만큼 큰 파장을 일으켰지만, 이미 지금은 꽤 오래되어 버린 기술이고 이미 사장되어 가는 기술이라고 보시는 분들도 많을지 모르겠습니다. 그러나 제 생각에는 웹에 자연스럽게 포함되어 지는 Applet의 가능성은 앞으로 더 각광받게 되어질 거라 생각됩니다.
지금부터 개발되어질 수많은 어플리케이션들 중에 많은 부분이 Stand alone 형태를 탈피한 웹환경에 밀접히 연계되고 의존적인 어플리케이션이 많이 등장할 거라고 생각됩니다.
더구나 웹서비스란게 추상적인 형태이긴 하지만 이것을 사용자에게 그럴듯하게 보여주기
위해서는 지금보다는 혁신적인 웹인터페이스가 필요하다고 생각합니다.

지금까지 Applet의 실패는 대부분 웹에서 치장하기 위한 보조적 수단으로 applet이 많이 쓰였다는게 큰 원인 중에 하나였다고 생각합니다. 그것들은 이미 flash등에 잠식 되었고, 개발환경이나 효과들도 그것에 미치지 못하는 것이 사실입니다.
그러나 Applet이 좀 더 적극적으로 하나의 어플리케이션으로서 웹환경에 포팅되어 질 수 있다면 기존의 웹이라든지 어플리케이션의 개념을 한단계 끌어올릴 수 있는 계기를 만들 수 있지 않나 생각해 봅니다.

끝으로 앞으로 나올 1.5(tiger라고 했든가..)에서는 새로운 기술을 도입해 로딩속도를 계선한다든지 하는 시도를 한다고 하던데... 앞으로 sun이든 jcp든 java의 클라이언트 측에도 많은 발전을 이루어 주었으면 합니다.
서비스는 결국 고객을 따라가게 되어 있으니까요...

구럼 두서없는 긴글 읽어 주셔서 감사하구요...
즐거운 프로그래밍 생활~~

익명 사용자의 이미지

더 이상 느리지 않습니다.
1.1에서는 C언어보다 많게는 수백배 느리다고 알려져 왔고, 실험을 통해 그러한 것들은 증명되었더랬습니다.
그 누군가가 늦어도 너무 느리다고 했던가...

그러나 1.2에서 이는 상당 부분 개선되었고
1.3으로 넘어오면서(HotSpot..) 자바가 느리다는것은 그야말로 귀신 씨나락 까먹는 소리가 되었습니다.

자세한 내용은 핫스팟 문서를 참고하세요.

익명 사용자의 이미지

다음 windows XP 서비스팩에

JVM 1.1.4가 들어간다고 하는군요

지금처럼 아예 안넣어 주니까, 사용자들이 최신의 JVM을 Sun에서 다운 받아서 설치하니깐,

그것보다는 졸라 옛날 버젼을 짱박아 주겠다는거죠...

이건, 정말 MS놈들만 할 수 있는 오노짓이 아닐 수 없습니다. 씨댕이들... -_-;

_oOoo!

익명 사용자의 이미지

약간 주제와 빗나가는 말이지만..

저는 VB 순수 어플리케이션 개발자입니다
(DB 쪽 아님 -_-;;)

요즘은.하드웨어 사양이 너무 좋아져서
살맛 납니다..
VB의 DB 쪽이야 속도 논쟁은 불필요한것이지만
특히 어플리케이션(유틸리티)쪽은.약간
델파이나 VC 에 비해서 컴플렉스를 가지고
있었죠..
근데..요즘은.. cpu 실행속도야 어쨌던
체감속도는 다른 좋은 언어와 비교할 필요없이
비슷한 속도를 내서..하드웨어 사양의 덕을
톡톡히 보고 있습니다..

자바도 마찬가지라 생각합니다..
솔직히 예전부터 그런 속도문제는 제기되었던
것이며 부정할수 없는 것이지만
요즘와서 그런 논쟁 자체가 필요없다고 봅니다.

누가 자바의 라이브러리가 부족하다고 말하는가?...
누가 비베를 초보자들이 다루는 툴이라고
건방지게 말하는가....

어떤 툴이든 개발자가.어느 한계를 뛰어 넘으면
그 툴에 대해서 오래동안 사용해온.경험을
상대방은 알지 못하기에 그냥 멋대로 말하도록
내버려 둡니다..

자바스크립트로 스트리트 파이터를 오락을
만드는 전문 스크립터를 보셨나요?

비베로 방화벽을 만든 전문 비베개발자를
보셨나요?

결과물을 보고 놀랍니다.

헉..난 이거 C++ 로 만든줄 알았는데
이게 정말 비베로 만든건가요?
거짓말 같아..우와....

현실이 이런것입니다...

저는 아직 옛날 방식 고집해서
비베도 아직 닷넷 컴파일러는 써보지 않았으나
특히 그런 속도 문제에서는 내부적으로
비베도 어셈블러를 도입해서 더 빨라졌다고
주위에서 하기에..아마 날개를 달아준듯합니다.

어차피 날개를 달지 않더라도..요즘 하드웨어
덕을 톡톡히 보고 있는데...

어차피 어떤 툴이든..계속 진화를 하겠죠.
다만.그걸 사용하는 사람이 어느한계까지
그 툴과 언어 그리고 알고리즘을 적절히
구사했는가..

뭔소리인지는 모르겠지만..
결국은 해당 툴을 오래 사용해본 사람만이..
이렇다 저렇다 말할 자격이 있겠죠..

자바 개발자 여러분도..주위말 신경쓸것
없습니다..

여전히 자바는 좋은 언어로..사람들에게
기억될거고 또 발전할테니..

(VB 도 역시 -_-V)

다만 VB 개발자가 DB 쪽 아니면
취직하기가 좀 힘들다는
것만 마이너스 요인일뿐...

익명 사용자의 이미지

GoodJob!

익명 사용자의 이미지

사용자가 불편없이 쓰고 하려고 하는 목적에 별 이상없이 돌아가면 장땡 아니가?

베이직이든 , 자바든,씨든말야

익명 사용자의 이미지

내공은 하나이되 초식은 여러가지이듯

-ISTREE-

익명 사용자의 이미지

SPARC기반의 Solaris에선 날것이고, Pentium 4기반의 Windows XP에선 기어다릴것이다... --;;;

익명 사용자의 이미지

누가 자바를 빠르다 했나~~~~~~~!!!!!!!!!!!

nairrti의 이미지

읽으면서 실소를 금할 수가 없군요...

취미로 만드는 것이라면 모르겠지만, 회사에서 제품 만드는데 자바로 만들지 C++로 만들지 결정하고 제품 만드나요? 거기에 적합하게?

만들기로 한 제품이 먼저고, 그걸 실무로 뛰는 당신이 얼마나 효과적으로 잘 할 수 있느냐가 중요한거지...

이 제품은 자바로 만드는게 빠르니까 자바로 만들어야겠군요 혹은 이 제품은 C++로 짜면 안됩니다 이러고 개발 들어가시나보죠...

멋지군요 그 회사들 어딘지...

못이야 망치로 박든 송곳으로 구멍 뚫고 손으로 밀어 넣든, 돌멩이 집어다가 때려 박든...

못만 잘 박으면 되지...

망치로 박지 않았으니까, 망치보다 박는데 더 느리니까 안좋은거야 라고 할 수는 없는 겁니다.
--
김 종 득 (Nairrti, A.K.A. LorD WhitE)
게임 디자이너

조기태의 이미지

상황에 따라 그럴 수도, 그렇지 않을 수도 있습니다.

일반적인 경우, 일단은 요구 분석이 먼저입니다. 그리고 그 밖의 제약사항 -
예를들어 다양한 플랫폼에서 동작할 필요가 있는지, 기존 시스템과 통합할
필요가 있는지 등을 파악합니다. 그리고 최종적으로 개발팀의 배경과
유지보수 용이성 등을 종합적으로 고려해서 개발 플랫폼을 선택합니다.

못을 박는 예를 드셨는데, 책상 하나를 짜는데 망치로 못을 박는 목수는 2시간이 걸리고 손으로 밀어 넣는 사람은 하루 종일 걸린다면, 또 손으로 못을 박은 책상은 조금만 충격을 줘도 삐걱거린다면 그래도 상관없다고 할 수 있을까요?

플랫폼의 선택은 매우 중요한 문제고, 경우에 따라 여러가지 기준이 적용
될 수 있습니다.

nairrti의 이미지

요지를 잘못 파악하셨군요

손가락으로 못을 박는 게 망치로 박는 것 보다 뛰어난 사람이면 손가락으로 박는게 '상식적인 못으로 박는게 낫다'라는 것을 뛰어넘을 수도 있는 겁니다.

개개인의 능력(자신에게 익숙한 도구)과 목표로 하고 있는 성과물의 기능이 뚜렷하게 결정되어 있는 상황이라면 그 도구가 무엇이든 중요한 것은 아니라고 생각합니다.

만약, 진정 삽질을 하는 것이라면 월급받고 앉아 있느니 물러나 주는게 회사의 M/M을 줄여주는 게 아닌가 싶네요. (그것도 싫으면 만회를 할 만큼 졸라 공부를 하던가 말입니다.)
--
김 종 득 (Nairrti, A.K.A. LorD WhitE)
게임 디자이너

nairrti의 이미지

죄송합니다 '못으로 박다'가 아니라 '망치로 박다'입니다. 정정합니다.
--
김 종 득 (Nairrti, A.K.A. LorD WhitE)
게임 디자이너

조기태의 이미지

정말 문제는 현실에서 "손으로 못을 박는게 망치로 박는 것 보다 빠른 사람"이 거의 없다는 겁니다. 또 설사 10년쯤 내공을 쌓아서 그런 능력을 갖게 되었다고 치더라도, 어차피 못을 박는게 목적이었다면 처음부터 망치로 박았으면 될일을 왜 쓸데없이 10년씩 걸려 손으로 박아야 합니까?

소프트웨어도 마찬가지 입니다. 개인별로 보면 분명히 자신에게 익숙한 전문 분야를 잡는게 중요하지만 프로젝트 단위로 보면 그렇지도 않습니다. 특히 SI 쪽은 고객의 요구사항과 시스템 환경에 최적의 언어/플랫폼이 중요시됩니다. 심지어 언어/환경에 맞게 프로젝트 팀을 재구성 하거나 그때마다 새로 뽑기도 합니다.

익명 사용자의 이미지

전에는 컴퓨터가 느린 관계로 프로그램 실행속도가 중요한 부분을 차지했지만 요즘같이 하드웨어가 빠른시대에는 실행속도의 중요도는 cpu 속도가 빠른만큼 반비레해서 낯아졌다고 생각합니다.

1~2년사이에 cpu 속도는 2,3배 빨라지지 않습니까?

자바로 짠 프로그램이라도 cpu 속도가 2,3 배 빨라지면 1,2년전에 c/c++ 짠 프로그램보다 빠르지 않을까요?

이런 속도문제 보다는 언어가 가지는 장점들의 문제가 더 중요하다고 생각합니다.

기타 다른언어와 비교해서 생산성이나 특정분야에 있어서의 프로그래밍상 장점및 한계 이런것들이 속도보다는 더 중요하게 보아야 할것들이 아닌가 생각합니다.

익명 사용자의 이미지

>> 10여년전에 나왔던 게임과 같은걸 요즘짜는 사람은 없읍니다.
>> 소프트웨어도 더 덩치가 커지고 복잡해졌죠...
>> 여전히 프로그램의 실행속도는 중요합니다.

익명 사용자의 이미지

여전히 실행속도는 중요합니다.

그러나 중요도는 낮아지고 있다는것을 강조한겁니다.

예를들어 A 언어와 B 언어가 있어 같은 내용을 프로그래밍해서 실행속도를 비교한게 있다고 칩시다.

CPU 속도 1:
A 실행속도:1 초
B 실행속도 2 초

시간이 흘러 CPU 속도가 2배가 되었을때

CPU 속도 2:
A 실행속도:0.5 초
B 실행속도 1 초

CPU 속도가 1초가 되었을때 A 와 B 의 실행속도 차는 1초입니다.

그러나 CPU 속도가 2배 되었을때 A 와 B 의 실행속도차는 0.5 초가 됩니다.

만약 CPU 속도가 4배 되었을때는 A 와 B 의 실행속도차는 0.25 초 밖에 차이가 나지 않습니다.

또 CPU 속도는 2의 자승만큼 기하급수적으로 빨라지지만 소프트웨어의 크기는 CPU 속도만큼 커지지는 않는거 같습니다.

즉 하드웨어가 발전하면 할수록 우리가 느끼는 시간의 차는 1초에서 0.25 초
줄어드는 거처럼 가면갈수록 느끼지 못할정도까지 되지않을까 생각합니다.

그러나 게임과 같은 분야의 엔진이나 시스템 소프트웨어같은 하드웨어를 최대한 활용하는 소프트웨어에서는 하드웨어의 발전에 상관없이 실행속도는 여전히 중요하게 생각이 될겁니다.

익명 사용자의 이미지

시간이 지날수록 처리해야 될 자료의 양이 2의 지수승을 월등히 초월한다면 소프트웨어의 성능이 문제가 됩니다.

익명 사용자의 이미지

냠 다 헛소리들 하시네요

당신들은 기껏해야 남이 만든 언어들을 사용하고 있을 뿐입니다.

C# 이 안좋다고요? MS 거라서 싫다구요? 그럼 당신이 직접 만들어보세요.

회사가 어떻든 간에, 일단 그것을 개발하는 것은 엄청난 시간과 지식이 요하는 것은 사실입니다.

애초부터 이 토론 주제는 싸움을 유발시키는 주제였다고 생각합니다.
이 토론주제를 만드신 분 C 에 개인적인 감정을 가지시는 분 같군요.

옛날부터 가장 어리석은 것은, 바로 언어분쟁입니다.
언어는 그 시대에 맞게, 또 용도에 맞게 개발되며, 또 그 분야에서 가장 최적화된 언어를 가지고 2차 개발자들은 프로그램을 개발합니다.

지금 보세요. C/C++ 와 자바 가 개발하는 분야가 명확하진 않아도, 어느정도 구분되어 있다고 할 수 있죠?

또 한가지 어리석은 점 바로 회사가지고 판단하는 점입니다.

개인적으로 전 C# 과 JAVA 를 모두 공부해 보았습니다. 하지만 자바와 C# 모두 어디하나 손색이 없는 멋진 언어입니다.

각 회사들은 물론 뒷배경의 전략도 있겠지만, 순수하게 각각 이 언어들을 바탕으로 미래를 걸고 있는 셈이구요.

이 회사들이 맘에 안드신다면 방법은 하나밖에 없습니다. 그냥 자신이 OS 하나 만들고 언어를 창조하세요.

다시 한번 말하는데, 정말 이 것은 쓸데 없는 토론주제이군요.

익명 사용자의 이미지

저도 동갑입니다.
이런 주제가 올라오다니... 실망입니다.

lovehis의 이미지

"나는 겁쟁이" 너무 과격한 말투만 빼고...
내용은...

동감 임니다...

무.의.미. 하죠... ^^*
--
늘...

익명 사용자의 이미지

멋진글입니다.
이런 쓰레기같은 논쟁 제기하지도 토달지도 맙시다.

대 한 민 국 짝! 짝! 짝!짝! 짝!

이제 4강입니다.

익명 사용자의 이미지

다 잘하면 되지.. 훔..

익명 사용자의 이미지

JVM 기반의 서버라면 몰라도 최소한 JVM올라가고 기계어 컴파일하는 시간은 더 들어야 정상이라고 생각됩니다. JAVA의 최장점인 JVM이 자바를 멀리하는 최악의 원인인셈 인가뵈요...

익명 사용자의 이미지

한 가지 재미있는 사실은, 바로 서버에서 자바가 강력한 이유 중 하나가바로 그런 특성에서 비롯된다는 것입니다.

즉, 클라이언트 프로그램이라면 JVM을 띄우고 JIT 컴파일을 하는 시간이 문제가 됩니다. 아무리 실행이 빨라도 뜨는데 오래 걸리면 사용자에게는 느린 것 처럼 인식될 수 밖에 없습니다.

하지만 서버 프로그램이라면 일단 JVM을 올리고 많이 쓰는 명령들을 JIT 컴파일하는데 걸리는 시간은 무시할 수 있습니다. 서버에서는 서버가 시작하는 시간보다는 서비스시에 성능이 문제가 되기 때문입니다.

JDK 1.5에서는 클라이언트의 이런 한계를 극복하기 위한 시도들이 계획되어 있습니다. 예를들어 VM을 공유하는 개념은, 일단 자바 프로그램이 실행 중이라면 다른 프로그램은 VM을 다시 시작하지 않고 원래의 VM에서 실행되게 됩니다. 그 차이를 실감할 수 있는 것이 텍스트 편집기, 탐색기와 같은 자바 프로그램을 직접 띄울 때 4-5초 걸리는 것이 Jesktop을 이용하면 클릭과 동시에 시작됩니다.

모질라 처럼 OS가 시작할 때 백그라운드에서 공유 VM을 띄울 경우 왠만한 스윙 어플리케이션은 1초 안에 뜰 수 있습니다. 지금도 실행속도는 크게 느리지 않으니 1.5가 나오는 시점에서는 충분히 경쟁력이 있다고 봅니다.

익명 사용자의 이미지

그게 2003년 하반기에 나오고, 보급되어 봤자 2004년 중반기 라고 가정할때
2003년 중반기 부터 Windows의 CRL의 보급이 활성화 될경우

상당히 비교 되겠지요. MS측에서 GUI속도 개선을 위해 지금도 불철주야
무슨 꽁수를 쓰든 그거에 매달릴테니(MFC를 보고 있으면 --;;)
CRL 역시 비슷한 방법을 취하지요.

그리고 결정적으로 2003년의 하드웨어의 발전도 고려 대상이라면,
1.4 대에서 tiger에서 적용될 방법론이 적용이 되어야 한다고

생각합니다.
1.4에서 usability를 고려할때, VM의 공유가 도입이 되기를 바랬는데...

익명 사용자의 이미지

MFC와 직접 경쟁할일은 별로 없어보이네요.

자바 클라이언트 애플리케이션은 특정 애플리케이션에서나 쓰일 확률이 높죠.
예를 들어 오라클의 경우도 관리툴이 모두 자바 기반이죠. 속도가 크게 중요하지
않으면서 다중 플랫폼을 지원해야하는 애플리케이션들이 자바의 시장이죠.
어차피 클라이언트 애플리케이션들 대부분은 그냥 유저 입력을 기다리는데 시간을
대부분 소요하니까요.

워드나 게임 같은 시장에서 C++/C와 직접 경쟁할 일은 거의 없어보입니다.

익명 사용자의 이미지

지금 말씀하신 것들은 속도가 중요시 되지 않고 안정성, 혹은 다중 플렛폼
의 장점을 살린 프로그램의 시장입니다.

그런 면에서는 동의하며, 그런 면의 시장만을 자바가 추구한다면
현재 속도 논의 자체가 필요 없다고 생각합니다.

여기에서 논의 되는 속도에 민감한 클라이언트 들이라면,
워드나 게임으로 생각합니다.

'자바로 일반 사용자들이 사용하는 워드나, 게임같은
속도감 있는 gui대응 할수 없는가'

가 현재 소모성(제 눈에는) 논쟁의 이유가되는 것은 말씀하신 시장이 아닌
일반 사용자대상 시장으로 생각합니다.

익명 사용자의 이미지

MS나 JAVA나 그놈이 그놈인지라....

뭐가 좋다면 왜 그놈쓰지 다른놈 쓰겠습니까?

내버려 두십시오.... 진짜로 좋다면 쓰게 될겁니다.

white23의 이미지

음...

근데 만약 JIT로 자바 코드를 컴파일 한다면은 자바의 최대 장점이었던...
"어디서나 실행된다" 것을 명확히 위반하느 ㄴ행위가 아닌지?
뭐 이렇게 해서라도 속도를 원한다면은 뭐...
굳이 Java 로 코딩을 해야 할 이유가 있을지?
차라리 레퍼런스가 많은 C나 아니면은 Visual-C를 사용하는게 낫지 않을지?

흠흠흠...

그리고 JSP랑 서블릿에 관한 언급이 나왔는데...
이것들은 JVM을 떠나서 생각을 할 수가 없겠죠...
물론 네트웍에 관련된 프로그램들은 회선에 따라서 성능을 많이 좌우 받는건 맞는 말이지면은...
같은 조건일 경우를 생각을 해야 하지 않을지?

그리고 요즘엔 더이상 실행 속도 가지고 왈가왈가 하는 시대는 떠나지 않았나 생각이 드는데...
쩝...
요즘 굳은틀(하드웨어)들이 하도 잘 나와서리...
굳이 속도에 신경을 크게 쓰지 않아도 될듯 합니다.
그냥 자신의 취향에 따라...
업무 영역에 따라 사용하는 랭귀지가 달라질 뿐...
그리고 자신이 진정한 엔지니어가 될라 치면은...
현재 사용되고 있는 랭귀지는 다 한 번씩은 해보고...
체험을 해보는게 좋을것 같네요.
꼭~~~

"知彼知己 百戰不殆"
--
_ 信

어떠한 역경에도 굴하지 않는 '하양 지훈' - It's Now or Never!!!

익명 사용자의 이미지

JIT는 RUNTIME시 기계어로 내부적으로 변환된다는 이야기입니다.
JIT은 VM에 구현되어 있구요. 따라서 JIT이 플랫폼 독립성을 해친다는건 잘못 이해하신게 아닌가 생각됩니다.
플랫폼 독립성은 bytecode 레벨에서만 호환되면 됩니다. 내부적으로 수행성능을 올리기 위해서 뭘로 변환하든 아무 상관이 없는것이죠.

조기태의 이미지

말씀하신 'WORA를 위반하는...' 의 경우는 JIT가 아니라 TowerJ, GJC같은 네이티브 컴파일러에 해당합니다.

JIT는 JVM의 일부입니다. JVM이 플랫폼 마다 다르다고 해서 플랫폼 독립적이지 않은 것은 아니지요.

그럼~

조기태의 이미지

여담이지만 왜 리눅스 개발자들이 자바를 싫어하는지 모르겠습니다. 대부분 C/C++배경을 가지고 있어서 그런가요?

개인적으로 오픈소스 진영에서 엔터프라이즈 자바+리눅스 만큼 MS에 위협적인 결합도 없다고 생각합니다. 최근에 엔터프라이즈 시장에 리눅스가 많이 진출하고 있지만 J2EE에 비교할 만한 솔루션이 없는 것도 사실입니다. 지금도 LAMP(Linux-Apache-MySql-PHP)로 중소규모의 웹사이트를 제작하는데 상당한 성과를 거두고 있긴 하지만 어느정도 규모가 되는 웹어플리케이션의 경우 닷넷이나 J2EE와 경쟁하기 어렵습니다.

설사 모노를 통해 닷넷 플랫폼을 받아들인다고 해도, 수년간 검증된 J2EE에 비해 당장 엔터프라이즈 시장에 진입하기는 어렵다고 봅니다. (그리고 왜 하필이면 닷넷입니까?)

자바가 오픈소스가 아니라고 생각한다면 JCP, 그리고 특히 최근에 있었던 자바-아파치 그룹 간에 오간 논의에 대해 다시 한번 알아보시기 바랍니다.

클라이언트의 경우 GTK나 QT 모두 자바를 포함한 다양한 언어에 대한 바인딩을 지원합니다. 또 최근에는 GCC로도 자바를 네이티브 어플리케이션으로 컴파일할 수 있습니다.

그렇다면 자바는 C/C++과 함께 리눅스에서 최적의 언어로 자리잡을 수도 있습니다. 리눅스의 정신은 자유 아니었던가요? 그렇다면 무슨 언어를 써서 개발하든 그게 왜 문제가 될까요?

C/C++만큼 자바로 제작된 리눅스 어플리케이션이 많이 나왔으면 좋겠고, 서버 측에서도 자바/리눅스의 조합이 윈도우즈/닷넷에 대한 강력한 경쟁자로 남기를 바랍니다.

익명 사용자의 이미지

설사 모노를 통해 닷넷 플랫폼을 받아들인다고 해도, 수년간 검증된 J2EE에 비해 당장 엔터프라이즈 시장에 진입하기는 어렵다고 봅니다. (그리고 왜 하필이면 닷넷입니까?)

자바가 오픈소스가 아니라고 생각한다면 JCP, 그리고 특히 최근에 있었던 자바-아파치 그룹 간에 오간 논의에 대해 다시 한번 알아보시기 바랍니다.

----
님글중에서 윗부분에 의문이 있습니다.

어떤이는 JAVA가 SUN에 묶여있다라고 하며, 어떤이는 님처럼 주장하는 것도 있는데 각자 옳다고 그러니 애매하군요.
서로간의 관계는 어떤지 설명해주실수 있습니까?

그리고 모노는 미구엘씨가 자바의 라이센스보다는 닷넷이 이상적이라고 판단하여서 닷넷으로 구현한것이죠... 아마 미구엘씨생각은 자바가 SUN에 관련이 있다라고 보는 제생각입니다.

토론을 보면 이런 서로간의 관계에 대한 설명은 자세히 나오지 않더군요.

logout_의 이미지

> 어떤이는 JAVA가 SUN에 묶여있다라고 하며, 어떤이는 님처럼 주장하는 것도 있는데 각자 옳다고 그러니 애매하군요.
> 서로간의 관계는 어떤지 설명해주실수 있습니까?
>

자바는 썬에게 묶여 있을 수도, 그렇지 않을 수도 있습니다. :)

자바의 스펙은 JCP라는 곳에서 결정합니다. 이 JCP는 일종의 자바 위원회와 같은 모임으로, 썬은 이곳의 영구 멤버입니다. 어떤 새로운 자바 스펙이 제안되면 JCP에서 토의를 거쳐서 다음 자바 버전에 반영이 됩니다. 상당히 민주적(?)인 구성이죠.

그런데 썬이나 JCP는 둘 다 똑같이 상이한 플랫폼에서도 제대로 작동하는 자바의 호환성 유지에 최우선을 둡니다. 즉, 소스 코드가 공개된 자바의 자유로운 발전보다는 좀 더 통제된(controlled) 버전업을 목표로 하고 있습니다. 이렇게 본다면 JCP는 썬의 꼭두각시가 아닌가 하는 의심이 들만도 하죠.

그러나 전체적으로보면 JCP도 오픈 소스와 마찬가지로 지속적인 피드백을 통한 좀 더 나은 소스코드 진화를 가능하게 하는 역할을 하고 있습니다. 분명히, 썬은 자바 개발 초기에 공개된 썬의 JDK소스에 지나친 영향력을 미치려고 한 것은 사실이고 이 와중에서 오픈소스 쪽 자바 솔루션들이 썬의 자바 솔루션으로 통합되는데 많은 애로사항을 겪었습니다. 특히, 썬이 오픈소스의 블랙다운 JDK 포팅 팀의 credit을 자바 다음 버전을 발표하면서 생략한 것은 상당한 논란을 불러일으켰습니다.

그럼에도 불구하고, 최근의 썬의 행보나 JCP가 자바 스펙을 확정하는 과정은 오픈소스와 큰 차이가 없다고 봐도 무방할 정도입니다. 분명히, 썬의 자바에 대한 영향력은 크고 지금까지도 썬을 무시한 자바는 상상할 수 없지만 이만하면 오픈 소스 진영에서 자바 개발에 참여하더라도 크게 손해볼 일은 없을 것 같습니다. JCP를 통한 자바의 스펙 콘트롤은 본질적으로 소수의 benevolent dictator들이 오픈 소스 프로젝트를 지휘 하는 것과 다르지 않습니다.

하지만 좀 더 확실한 자유의 보장과 썬의 최대의 적인 MS의 '물흐리기'를 막기 위해서는 아무래도 JDK의 소스가 언젠가는 GPL로 공개되는 것이 좋다고 봅니다만 그정도까지 기대하기는 어려울 듯 합니다.

제가 보기에 오픈 소스 진영에서 자바에 많은 노력이 투입되지 않는 것은 자바 초기의 썬의 무리한 소스코드 콘트롤의 악영향 때문인 것 같습니다. 그리고 소스 코드 수준에서 포팅이 용이한 유닉스, 리눅스의 특성상 굳이 Write Once, Run everywhere라는 자바의 캐치 프레이즈가 오픈 소스 개발자들에게는 크게 매력적이지 않은 것도 사실입니다.

어쨌거나, JCP를 통한 자바의 스펙 콘트롤은 이제는 오픈 소스 진영에서도 믿어볼만 하다는게 제 의견입니다. 다만 하나 아쉬운 것은, 썬이나 JCP 모두 아직까지 소스 코드의 자유로운 진화보다 구조화된 통제에 관심이 있다는 점입니다.

조기태의 이미지

중요한 점을 지적하셨군요. 썬에서 자바를 일반적인 의미의 오픈소스(즉, GPL이나 LGPL같은)로 공개하지 않는 가장 큰 이유는 독립적인 호환되지 않는 VM들이 난립하는 상황을 우려하기 때문입니다. 아시다시피 WORA는 썬의 가장 잘알려진 마켓팅 프레이즈지만 JVM 간의 호환성이 깨진다면 의미가 없어지기 때문입니다.

현재 자바의 모든 표준 스펙은 JCP라는 별도의 기구에서 만들고 있습니다. http://www.jcp.org/participation/members/index.en.jsp 에서 JCP의 멤버를 보시면 아시겠지만 썬 이외에도 여러 회사, 단체, 오픈소스그룹, 개인 등이 참여하고 있습니다.

근래에 아파치 그룹을 중심으로 JCP의 룰이 오픈소스 진영의 참여를 저해한다는 비판이 거세게 일었지만 얼마전 Sun측과 아파치 그룹의 합의에 의해 바람직한 방향으로 마무리되었습니다.

자바가 오픈소스이다 아니다라는 논쟁은 바로 이런 JCP의 성격을 어떻게 보는지에 따라 다릅니다.

그래도 GPL버전의 JVM을 꼭 쓰고 싶다면 classpath를 비롯한 몇 가지 대안은 있습니다. 물론 모두 1.x대에서 이제막 Java2로 넘어오는 단계입니다.

가장 큰 문제는 썬이 JVM자체의 소스를 공개하지 않는 점이지만, 최소한 닷넷 보다는 훨씬 오픈소스에 가깝다고 생각합니다.

그럼...Anonymous wrote...

익명 사용자의 이미지

JVM 자체의 소스도 공개되어 있습니다. 물론 그것이 릴리즈 된 버전과
일치한다는 보장은 없다라고 명시되어 있지만 그건 공개를 하는 쪽에서는
당연히 그렇게 말할 수 밖에 없는 일입니다.(같은 소스도 컴파일 하는
방법에 따라, 환경에 따라 다를 수 있으니까..) 저도 소스를 다운로드
받아서 가지고 있기 때문에 이건 확실합니다.

페이지