자바는 반드시 .NET에게 진다!

geekforum의 이미지

.NET을 단지 뒤늦은 자바의 클론, MS의 발악 정도로 치부해버리는 경향이 있는 것 같다. 심지어 MS쪽 사람들까지도 .NET의 미래를 불투명하게 예측하거나 좋게 봐줘도 윈도우즈 플랫폼에서의 제한된 성공 정도로 본다. 그러나 내가 보는 .NET은 그렇지 않다.

다들 아시다시피 자바는 그린 프로젝트의 산물, 애초부터 임베디드 기기에서 수행되는 것을 목적으로 태어난 언어이자 환경이다. 그만큼 임베디드 기기에 필요한 장점들을 모두 가지고 있고 최적화 되어있다.
그런데도 불구하고 현재 자바는 임베디드 환경에서 별로 힘을 못쓰고 엉뚱한 서버쪽에서만 위세를 떨치고 있다. 물론 임베디드 환경의 컴퓨팅 파워가 아직 VM을 부담스러워 하기 때문이기도 할 것이다. 그러나 자바가 임베디드 환경에서 널리 쓰이지 못하는데는 더 중요한 이유가 있다.

첫째. 자바의 라이센스다. SUN은 "자바는 내꺼"라는걸 너무나 강조하고 있어서 다들 자바를 부담스러워한다. 라이센스 비용도 만만치 않다. 내가 아는 바에 따르면 LG가 iBook에 KVM을 싣는데 일시불 30만불, 1년에 7만불, 한대에 6불이라는 비용을 지불한다고 한다. 상당한 비용이다.
리눅스는 여기저기서 포팅해도 자바는 포팅하는 경우가 많지 않다. 클린룸으로 개발하면 라이센스 비용이 없다는데도 다들 자바라고 하면 일단 고개를 설레설레 젓는 것이다. 자바가 리눅스 세계에서 배척당하는 것도 비슷한 이유 아닌가? SUN에 목매게되면 후환이 두렵다는 것인가...

둘째. 자바환경의 언어적 폐쇄성이다.
자바는 자바언어만 사용가능하다. 물론 자바언어가 나쁘지 않다. 정말 훌륭한 언어임은 인정한다. 그러나 자바밖에 안된다! 라는 것은 너무 심하다. 모든 개발자가 자바를 배워야만 하는 것인가?
특히 자바가 PC나 서버에서처럼 선택사양이 아니라 임베디드 환경에서 OS수준으로 사용된다면 그 임베디드 기기는 개발을 위해 자바언어 하나만 쓸 수 있는 그런 닫힌 OS가 되어버리는 것이다. 스스로 대문을 닫아버리는 셈이다. 자바유저가 늘었다지만 C/C++ 유저가 그 몇 배는 될 것이다.

이 두가지 문제점이 자바가 임베디드 시장에 제대로 진입하지 못하는 최고의 진입장벽이라고 본다.

그렇다면 .NET을 볼까?
우리가 착각하고 있는 것은 .NET이 자바하고 서버시장에서 경쟁하기 위해 나오는건 아니다. 자바가 아직 잡지 못한 임베디드 시장을 노리고 나오는 것이다. 자바가 가진 단점들을 모두 극복하고서 말이다.

잠시 딴 얘기를 하자면 WinCE는 임베디드 OS시장 독점의 야욕을 품고 다양한 CPU와 하드웨어 위에서 동작할 수 있도록 Portable하게 만들어졌다. 그러나 MS 애들이 실수한게 있으니 OS 만 포터블하다고 해서 그게 전부가 아니라는거다.
WinCE는 돌아가는 기계가 많다보니 어플을 하나 개발하면 각 기계별로 바이너리를 따로 준비해야한다. 물론 설치할때도 사용자는 자기 PDA가 무슨 CPU 쓰는지 조사해서 맞는걸 골라 설치해야만 한다.
이 얼마나 골때리는 일인가.. WinCE가 아무리 Windows와 비슷하다지만 그래도 환경이 제법 틀린데 거기에 개발한 어플은 바이너리 호환성조차 없다니.. WinCE로 어플개발을 주저할만도 하다. WinCE는 이런 현실의 문제에 봉착하고 있는 것이다.. 어쩜 .NET은 이 문제를 해결하기 위해 등장했는지도 모르는 일이다.

자 하여튼.. 그럼 .NET이 자바의 문제점들을 어떻게 해결하고 있는지 살펴보겠다.

첫째, .NET의 라이센스..
이것은 자바와 마찬가지다. 아니 오히려 .NET은 자바보다 더욱 폐쇄적일 것이다. 개인적으로 .NET이 소스를 공개할 가능성은 거의 없다고 본다.
그럼에도 불구하고 .NET의 라이센스는 별 문제가 안된다. 왜냐면 MS는 윈도우즈를 가지고 있기 때문이다. .NET의 시나리오는 아마 다음과 같을 것이다.

1. .NET을 데스크탑에 포팅한다.
2. 데스크탑 윈도우즈의 수많은.. 실질적으로 거의 모든 개발자가 반강제적으로 .NET에 적응해야만 한다.
(사실 .NET은 언어를 가리지 않으므로 정확히 말하면 .NET Framework에 적응하는 것이다. 이건 매우 쉬운 일이다. 여기까지 실현될 확률은 100%에 가깝다.)
3. .NET은 임베디드 환경에도 포팅된다. WinCE와 스팅거야 MS꺼니까 당연히 포팅할테고 EPOC이나 PalmOS등에도 포팅해줄런지는 장담못하겠다..
4. 개발자들은 관성에 의해 임베디드 역시 동일한 .NET 기반위에서 개발하는 것을 선호하게 될 것이다. 그리고 실제로 .NET은 지금보다 임베디드 개발을 훨씬 편하게 만들어줄 것이다.
5. WinCE와 스팅거는 .NET을 가장 잘 지원하는 OS가 될 것이며 때가 되면 .NET은 다른 임베디드 환경에서의 지원을 멈출지도 모른다.
6. WinCE와 스팅거는 .NET의 힘으로 임베디드 시장을 정복할 것이다.

대충 이런 시나리오다. .NET은 데스크탑->임베디드의 가교역할을 하게 되는 것이 궁극적인 목표인 것이다. 라이센스 문제라던가 플랫폼 독립성은 저 시나리오에서 별로 중요하지 않다.
시나리오는 너무 간단해보이지만 MS는 저걸 해낼 수 있는 힘을 가지고 있다. 단 하나 걱정되는게 있다면 .NET이 너무 늦게 나왔다는거다. .NET도 버그잡고 안정화, 최적화되려면 최소 1-2년은 필요할텐데... 그게 불안요소일뿐이다.

둘째, 당근 .NET은 언어를 가리지 않는다. 현재 데스크탑에서 개발할 수 있는 능력을 가진 모든 개발자는 .NET을 통해 임베디드에서 개발할 수 있는 능력을 저절로 갖추게 될 것이다. 임베디드는 데스크탑의 연장선상에 서게 될 것이다.

설명이 충분했는지 모르겠으나.. 하여간 이상의 이유로 .NET은 자바를 제치고 임베디드 시장을 석권할 가능성이 매우 높다.

졸려서 두서없이 글을 적었는데.. SUN이 지금의 자바 라이센스 정책을 고수하다면 임베디드 환경에서의 영향력 확대는 요원할 것이고 .NET은 무섭게 성장해서 임베디드 역시 윈도우 천지를 만들어버릴 것이다. SUN이 .NET에 어떻게 대응할지 모르겠는데 아마 내 예측으로는 자바 라이센스를 좀더 LIGHT하게 가지 않을까 싶다. QT의 라이센스가 GPL로 완전히 풀려버린 것처럼..

당장 라이센스료 조금 많이 받는다고 해서 그게 전부는 아니다. SUN은 정신차리고 자바의 라이센스를 풀어서 임베디드 시장을 석권하고 .NET을 몰아내라. 시장지배력을 가지게 되면 딴데서 얼마든 돈 벌 수 있을거다. 안그런가?

개인적으론 GNU가 자바 비스무리한거 하나 만들어주면 좋겠다... 하지만 아마 특허권에 걸려서 어려울 것 같은데.. 이래저래 앞으로 PDA는 자바 아님 .NET 둘중의 하나로 가게될 것 같다. 솔직히 솔직히 나는 .NET이 낫다. 왜냐면 자바 배우기가 귀찮고 나는 C언어가 가장 좋은 사람이기 때문이다. C#도 괜찮아뵈고..

그래도 워낙 MS가 싫어서.. 어쩔 수 없이 자바를 응원한다.

댓글

익명 사용자의 이미지

배부르고 싶어하는 돼지는 M$, Sun뿐만아니라, IBM, SGI, Redhat등등도
포함됩니다.
영리목적을 추고하는데 돈되면 쫓아가야죠...
그들이 땅파서 회사 운영하는것도 아니고...
그리고 PostMS를 노린다는건 이해가 안가는 군요.
Sun이 M$보다 회사규모나 사업규모는 좀금 더 큽니다.
나름대로의 사업전략도 있고, M$와는 조금의 차이가 있지만

익명 사용자의 이미지

맞는 말씀입니다..
다들 배부르고 싶어하는 돼지들이죠..
다른점은.. 마케팅정도.. 기술력과..
적어도SGI, IBM, SUN REDHAT은..
다른 사람꺼 가져다가 쓰면..
썼다고 말합니다..
MS처럼 전부다 지들이 했으니..
니네 돈.. 얼만큼내.. 라던가..
정부에서 너네.. 헤쳐모여.. 라고 해고
간단하게 개기면서 씹어버리는 M$와는 다르죠..
한마디로 버릇없는 M$..

전이삭의 이미지

물론 현재의 PDA를 볼때 PDA의 기능이 기껐해야~~ 라는 생각을 하실수도 있겠지만

혹시라도 옛날에 수많은 사람들이 생각했듯이...

PC가 아무리 발달해도 얼마나 가겠어...라든지

개인이 1기가 이상의 하드가 무슨 필요가 있겠어...

모뎀이 9600bps이상되면 화면이 너무 빨라서 읽기도 힘들어...

이런 식의 잘못된 판단이 되지 않을까 하는 우려가 되는군요.

휴대용 컴퓨터로 무슨 대단한 작업을 하지는 않겠지만

나중에는 또 어떤 강력한 기능들을 필요로 할지 아무도 모릅니다.

실제로 PC의 잠재적인 시장성을 먼저 파악한 MS가 성공했듯이 말입니다.

익명 사용자의 이미지

흠냥...글도 잘 읽었구 답글도 읽어 봤는데 나름대로 일리가 있는 말입니다. 그냥 제가 하구 싶은 말은 너무도 진부한 말이긴 한데 그냥 상황에 따라서 골라쓰는게 제일 좋겠죠...
자바가 더 유리한 환경이면 자바쓰고 .NET 이 유리한 환경이면 그거 쓰고 이러면 되져...항상 자바가 좋고 항상 .NET 이 좋다고 말할 수는 없겠죠...

여러가지 언어를 다 잘한다는게 현실성이 없긴하지만 직장을 다니는 프로그래머라면 자바로 개발하는 프로젝트가 있는데 자긴 C 밖에 못한다고 배를 쨀 수도 없는 노릇이구...머..공부해야겠죠...죽을 때까지 공부해야하는게 프로그래머의 숙명이니까요

익명 사용자의 이미지

윗 분에 어느 분이 윈도우즈의 환경을 embeded까지 끌고 간다고 하셨는데
좀 위협적이긴 합니다.
하지만..
우리가 embeded기기에서 할 일을 생각해 보면 구지 윈도우 환경을 가지고 갈필요가 있을까라는 생각이 듭니다.
그리고 브라우져말인데..
어차피 xml로 포멧이 통일이 되어 버리면 그 문제도 자연 스래 해결이 되지 않을런지..
우리가 pda나 휴대폰으로 하는 것은 고작 해야 스케줄, 메모, 간단한 게임,email일텐데.. 나중에 화상통신되면.. 그거 할테고.. mp3듣고 인터넷방송듣고.. 과연 그 조그만한 화면으로 포토샵하고 3d 작업할 사람은 없겠져
제가 생각하기엔.. 모바일 환경은 좀 다른 각도에서 접근을 해야하지 않을까 생각이 듭니다.
또 한가지..
휴대폰에서 만약에 포토샵과 같은 엄청난 양에 프로그램이 돈다면 밧데리가 금방 방전이 될것입니다.
아마 미래에 가장 돈이 되는 산업은 밧데리 산업이 아닐까 하는 엉뚱한 결론을 내고 글을 마칠렵니다.
이상 ^^v~

munggo_의 이미지

저랑 생각이 비슷하네요 :)

전이삭의 이미지

(에구...실수로 본문에 답장을 눌렀네요..^^ 위에 글은 지워주세요~ 죄송~)

물론 현재의 PDA를 볼때 PDA의 기능이 기껐해야~~ 라는 생각을 하실수도 있겠지만

혹시라도 옛날에 수많은 사람들이 생각했듯이...

PC가 아무리 발달해도 얼마나 가겠어...라든지

개인이 1기가 이상의 하드가 무슨 필요가 있겠어...

모뎀이 9600bps이상되면 화면이 너무 빨라서 읽기도 힘들어...

이런 식의 잘못된 판단이 되지 않을까 하는 우려가 되는군요.

휴대용 컴퓨터로 무슨 대단한 작업을 하지는 않겠지만

나중에는 또 어떤 강력한 기능들을 필요로 할지 아무도 모릅니다.

실제로 PC의 잠재적인 시장성을 먼저 파악한 MS가 성공했듯이 말입니다

m105의 이미지

........
하긴 3d작업할 사람이 있을수도 있겠군요..
요즘은 폰도 3d환경으로 나오니..

익명 사용자의 이미지

.NET은 위의 씨나리오 보다...
X Box라는 게임기를 통해서 보다 활성화 되리라 예상된다.

X Box는 단순한 게임기가 아니라...
인터넷으로 게임을 사고 파는 전자상거래 단말기인 것이다.

그 전자 상거래를 위해서 .NET이 쓰일 것이고
헤일스톰이 사용될 것이다.

빌 게이츠가 한 이 말은 다시 씹어 볼 필요가 있다.
"나는 X Box를 처음 보았을때 원도우를 접했을 때 느꼈던 흥분을 느꼈다."
동경게임쇼인가 어디서 연설한 내용이다.

그리고 MS는 X Box 홍보에 사운을 걸고 돈을 쏟아 붓는다 했다.
다 무슨 의미인지 꼽씹어 본다면...
두려움을 느낄 것이다.

익명 사용자의 이미지

X Box는 단순한 게임기라고 합니다. (출처 게임비 x-box관계자 인터뷰내용중)
그 인터뷰에서 질문역시 .NET의 일환으로 X Box에 적용 계획은 없는가에 대한

질문이 있었는데, 긍정도 하지 않고 극구 부정을 하고 있습니다.
제 생각에는 X Box에 .NET이 적용될려면 더 상위 하드웨어가 필요한

다음 버전이 될꺼 같습니다. X Box2 정도,
현재 .NET환경을 클라이언트에서 사용하기에는 하드웨어의 고사양을 요구하는

바가 너무 큼니다. 오히려 X Box는 MS가 그간 그래픽에 투자했던 엄청난 돈을
뽑아네는데 일조 할거 같습니다.

이번달 마소에 나왔듯이, 미국의 유수 그래픽 관련 학자들(교수, 박사)들이
MS에 들어가서 연구하면서 밥벌이 하고, 그 산출물로 현재의 미래의 api라 극찬을

받는 DirectX 8을 내놨습니다. 먼저 이거에 따른 돈을 뽑아야죠. --;

익명 사용자의 이미지

공감이 감니다.
그리고 잠시 달필에 넋을 잃었네요.
논술고사 가정교사해도 되겠음다........

익명 사용자의 이미지

저..저기 sun 홈페이지 가보면 vm에서 쓰이는 자바의 다른 언어도 있는데요.
더구나 현재 진행중인 Jython의 경우 산출물이 class파일이라 java VM에서
도아가는데.. 역시 제한된 C VM도 자바용으로 있고..

MSIL이 등장한 이후 이런 분야의 연구 계발이 가속화가 된다는 느낌이 듭니다.
.NET환경우 멀티 랭귀지 표방이지만, 실제로는 MSIL이고 최적화는 C#내지 기타

한두개 언어 뿐이고..
어떤 분께서인가 Java VM용으로 다른 언어가 나오기는 class파일 내부에서 자바

문법의 채용으로 한계가 있다고 한말이 생각나는데, 정확히 아시는 분이 말씀해
주셨으면..

마지막으로 sun사의 java에 대한 라이선스는 어떻게 해결 되었으면 좋겠습니다.
sun의 주력 사업이 거의 하드웨어 인지라, 소프트웨어에 투자하고 회수하기가

어려운가 본데, 미래의 시장 장악(?)을 생각하면 현재의 이것도 너무 버겁다는
거에 동의합니다.

익명 사용자의 이미지

헉 맞춤법이 진짜 엉망이네.. 역시 찍기 수능의 폐해 --;

익명 사용자의 이미지

Apple의 WebObject가 다 이겨버린다.
우헤헤

익명 사용자의 이미지

모순이네.. 썬에 목매는 것은 두렵다면서 M$에 목내는 것은 두렵지 않은가?

그리고 언어로 자바밖에 선택할 수밖에 없으므로 폐쇄적이다?
그런데 폐쇄적인 M$ 플랫폼에서만 돌아가는 건 문제가 전혀 없을까?
말로는 .NET이 멀티플랫폼을 지원한다고 떠들지만 그 말 믿는 사람 있을까?

아직 제대로 나오지도 않은 것을 가지고 누가 이기고 지고 논하는 것도
우습지만 시장을 100% 장악하리라 기대하는 것도 우습네요.

freesoft의 이미지

짝짝짝~~! ^_^

JAVA가 그리 쉽게 망하지도, C#이 그렇게 쉽게 시장을 장악하지도 않을겁니다.
나름대로의 용도와 목적을 가지고, 때로는 감언이설에 의해서, 때로는 필요에 의해서
선택될 뿐이죠.

어차피 중간코드를 생성해아 하기는 마찬가지입니다. 말만 슬쩍 바꿔서 그렇지
자바가 문제라면 마찬가지로 그것때문에 C#도 문제인 겁니다.

시장 장악하면 MS 도 라이센스료 당근 올릴거구요, 그렇다고 JAVA처럼 API나 소스코드 공개할리는 절대 없구요...

두고 볼 일입니다.

익명 사용자의 이미지

>그리고 언어로 자바밖에 선택할 수밖에 없으므로 폐쇄적이다?
>그런데 폐쇄적인 M$ 플랫폼에서만 돌아가는 건 문제가 전혀 없을까?
>말로는 .NET이 멀티플랫폼을 지원한다고 떠들지만 그 말 믿는 사람 있을까?

현재 오픈소스 진영에서 CRE인가? 먼가가 만들어지고 있다더군요.
전 자바만 좋아하지도 .NET을 옹호하지도 않는 유씨 유저일뿐입니다.

익명 사용자의 이미지

이미 모두들 MS에 목을 매고 있죠. 이것은 피할 수 없는 현실입니다.
그러니까 목맬 대상이 하나 더 늘어나는 것에 대하여 잠재적으로
두려워하는겁니다.

그리고 위의 글에서 설명드렸다시피 .NET은 멀티플랫폼에서 구지 안돌아도
충분히 위력적입니다. MS의 데스크탑과 임베디드 OS에서 동일한 환경을
제공한다는 것만으로 엄청난 파괴력을 가져올 것입니다. 멀티플랫폼은
그냥 자바대응 선전용 양념...정도겠죠.

현재 흐름을 보건데 하드웨어 배경이 다양한 임베디드 환경에선
특정 OS보다는 VM이 대세가 될 가능성이 높습니다. WinCE, 팜의
절반의 성공 절반의 실패가 가르쳐주듯이 말이죠.

허나 현재의 자바 라이센스라던가 언어적 폐쇄성으론 자바를
임베디드 환경의 주류로 만들 수 없고 결국 몇년이 지난 후에는
MS의 .NET이 그 탁월한 마케팅 전략과 능력으로 임베디드 시장도
지배하리라는 예측입니다.

최적화? 그런건 나중에 천천히, 그저 시장상황에 맞춰 필요한
만큼만 하면 됩니다..

저로선 VM에 관련해서 뭔가 오픈 스탠다드가 나와주었으면 하는게
진짜 바램입니다. 그럼 이만..

익명 사용자의 이미지

논지가 무엇인지 모르겠군요.
M$에 목매는 것이 피할 수 없는 대세라고 하셨는데 아닌 사람들도 많습니다.
저 같은 경우 일부러 M$계열을 하지 않습니다. 회사에서도 요구하지 않고 앞으로 할 계획도 없습니다. M$ 독점적인 기술에 발을 들여놓는 순간부터 M$제품만 사용해야하는 것이 너무 싫습니다. 차라리 자바를 사용하면 이 플랫폼이다 저 플랫폼이다 별로 따질 일이 없어서 선호합니다. 어쨌거나 한 회사에만 목매는 것은 개발자로써 좋은 자세는 아닙니다. 또한 기술의 발전이라는 측면에서도 한 회사에 모든 것을 의존하는 것은 결국 폐해를 가져올 뿐입니다. 썬이 자바를 자사의 지배하에 두려는 것도 별로 좋아보이지는 않지만, M$가 이걸 보고 뭐라 그럴처지는 아니죠. 뭐 묻은개가 뭐 묻은 개 나무란다는 속담처럼...

또 하나 멀티플랫폼에서 돌아가지 않아도 위력적이기는 하겠지만.. 역시 폐쇄적이라는것과 일맥상통한다는 겁니다. 임베디드 환경에서 특정 하드웨어에 의존한다는 것은 많은 문제점이 있을겁니다.

님은 단일 플랫폼에서도 .NET이 위력적이고 자바 대응 선전용 양념이라고 하셨다가 VM 찬양을 하시다가 하니 종잡을 수 없군요. 분명 임베디드나 앞으로 대세는 특정 OS나 하드웨어 종속적이 아닌 VM이 대세라고 하시면서 자바 대응 선전용 양념이라고 또 하시니 도대체 진실이 무었입니까?

밑에 자바 라이센스와 언어적 폐쇄성이라는 것은 더 언급할 필요가 없을 것 같군요.
M$ .NET 플랫폼은 더하면 더했지 덜하지는 않을겁니다. 늘 그랬듯이...

마지막 썬이 살길은 결국 자바를 오픈소프트웨어로 만드는 것일겁니다. 이미 소스는 공개했지만 아직도 썬은 자바에 대한 제어권을 놓치는 것을 두려워하고 있는듯합니다.
만약 오픈된다면 보다 널리 사용되는 표준으로 될테고 시장은 더욱 확대될텐데 말입니다.

요약하면 VM은 앞으로 필수적인 것이고 M$의 독점적인 플랫폼에서만 돌아가는 개발환경은 한계를 가질 수 밖에 없을것이다.
그리고 썬은 자바를 오픈소프트웨어로 만드는 것이 바람직하다.

덧붙임: 어떤 기술이 우수하냐 아니냐도 중요하겠지만, IBM PC의 아키텍쳐 공개로 IBM PC가 주류를 이룬것 처럼 반드시 우수한 기술이 아니더라도 모두가 이용할 수 있는 공개된
표준이 된다는 것은 정말 중요한 문제입니다.

익명 사용자의 이미지

MS에 목매지 않는 사람도 분명 많습니다. 하지만 MS에 목매는 사람은
그보다 훨씬 더 많습니다. 그래서 대세라는 것 아니겠습니까? 대세라는
표현이 백이면 백 천이면 천 모두가 그렇다.. 라는 뜻은 분명 아닐겁니다.
저야말로 무슨 말을 하고 싶으신건지 모르겠군요.

VM이라는 표현은 하드웨어 플랫폼에 대하여 비종속적이라는 뜻입니다.
자바도 .NET도 VM입니다. 하지만 자바는 하드웨어 플랫폼뿐만 아니라
OS 플랫폼에 대해서도 비종속적입니다. .NET은 하드웨어 플랫폼에 대해서는
비종속적이지만 OS는 오직 윈도우즈위에서만 돌테니까 OS 플랫폼에 대해서는
종속적입니다.

표현이 섞여서 사용되기 때문에 잠시 혼란스러웠습니다만, 정리하자면
.NET은 OS 플랫폼에는 종속적이다. 그러나 그 종속되는 OS가 윈도우즈이기
때문에, 그리고 MS가 윈도우즈를 가지고 있기 때문에 OS 플랫폼 종속성은
별 문제도 아니고 하드웨어 플랫폼에 대한 비종속성만 가지고도
.NET은 여전히 강력하다는 것입니다.

물론 .NET은 윈도우즈이외의 다른 OS도 지원하여 OS 플랫폼에도 자바처럼
독립성을 보장할 것처럼 광고하고 있지만 그게 바로 자바대응 선전용
양념이라는 겁니다. 분명 윈도우즈이외의 OS에서 .NET은 지원되지 않거나
부실하게 지원되거나 언젠가는 지원을 끊어버릴테니까요.

플랫폼이라는게 2계층이 있다보니 여기서 이해가 어긋난 것 같습니다.
그럼 이만

익명 사용자의 이미지

덧붙임에 대하여 한마디 찔러보자면...
IBM PC가 아키텍쳐를 공개하여 IBM PC가 주류를 이룬 것이 사실입니다. 그렇지만, 그래서 IBM이 무슨 이익을 남겼죠? 정작 이 모든 것을 시작했던 IBM은 PC 시장에서 맥을 못 추고 있습니다. (그동안 많이 벌어먹긴 했겠지만... 얼마나 먹었을까요?)

제가 생각하기에는 썬은 그것을 두려워 하는 것 같습니다. 만일 자바를 오픈소스로 마구마구 풀어버리면 자바가 엄청난 위력을 발휘하게 될 것이라는 것은 80% 정도는 확신하고 있습니다. 그렇지만 그렇게 자기 자신의 독점적 권한을 포기한다면 썬은 뭘 먹고 살죠? 기업이라고 하면 돈을 벌어야 먹고 사는데, 돈 안 되는 짓을 할 리 없겠죠?

만일 썬이 자바를 오픈소프트웨어로 만들면 제가 생각하기에는 뻔한 결과를 초래할 듯 합니다. 분명 엄청나게 많은 기업들이 벌떼처럼 달려들어 너도나도 자바로 뭔가 해보겠고, 결국 Java는 C나 C++과 같이 대중화(?)가 되더라도 썬에게는 돈 별로 안 되는 짓 밖에 안 되는 것일 겁니다...

머 돈 많이 퍼부어서 인류 사회에 공헌한 셈(?)이 되겠죵..
SUN은 사실 자바 빼면 회사 절반쯤은 날라간 셈일텐데.. ㅡ.ㅡ
(아닌가요?? 아님 말구...ㅡ.ㅡ)

글구... 만일 썬이 자바에 대한 제어권을 놓아버린다면 여러가지 면에서 말썽이 생길 수 있을 것 같습니다. 그동안에는 여러가지 API들이 표준화 되어 있다보니, 그냥 API대로 짜기만 하면 실제로 돌아가는 게 뭐든지 간에 잘 돌아가는 시스템이 되어있었죠... JDBC, EJB, 서블릿 등등이 그렇죠... DB가 뭐든간에, 컨테이너가 뭐든간에, 동일한 API를 적용해서 짜면 되니까요...

그렇지만 썬이 이 제어권을 놓아버리게 되면 분명 이런 것을 어떤 표준기관에서 하지 않는 한, 회사마다 지맴대루식의 API가 구축되지 않을까 걱정됩니다.
뭐 썬이 계속 그런 API를 정의하고 나서면 되겠지만, 제어권을 놓아버린 상황에서 과연 썬의 목소리가 얼마나 먹힐까요?

익명 사용자의 이미지

기실 자바가 선의 매출에 별 영향을 못주는 것은 사실입니다.
선은 하드웨어 업체이고 서버와 웍스테이션을 팔아서 매출을 올립니다.
선이 자바를 적극 지원하는 이유는 제가 알기로는 자바의 성장이
인터넷의 활성화에 도움이 되고 인터넷이 활성화되면 자사의 서버가
더욱 잘 팔리기 때문이라는 간접적인 이유입니다.
또한 자바를 통해 선은 MS에 저항하는 반독점 세력의 선두로서의
좋은 이미지를 굳혔습니다. 하지만 실제로 자바에 투자한 금액을
회수하기엔 현재로선 무리가 있는 것 같습니다.
그리고 자바가 선의 수중에 있는한 앞으로도 자바가 WWW이나
XML처럼 폭넓은 지원을 받을 수 있을거라고 기대되진 않습니다.
분명 선은 언젠가 품안의 자바를 하늘로 날려보낼 것입니다.
그 때가 너무 늦지 않기를 바랄 뿐입니다.

white23의 이미지

반드시 안지면 어쩔거유?

위에 든 이유들은 하나하나 답변 달기도 귀찮다...
당신은 위 두개를 한번 빡씨게 사용해 보셨는지?

그렇다면은 당신 말이 옳을지도?

<어떠한 역경에도 굴하지 않는 '하양 지훈'>

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

익명 사용자의 이미지

iron의 이미지

주제와 별로 상관없는 얘기지만.
java binary 로 컹파일을 지원하는 언어도
있지 않던가요?
봤던거 같기도 한데.. -.-a
라이센스 문제가 아니라면 불가능 할것
같지도 않구요...

익명 사용자의 이미지

.net 반드시 리눅스한테 진다.

qt, gtk 기반등등으로 .net 은 리눅스한테 지게 되어 있다.

리눅스 만세이~~~~

익명 사용자의 이미지

자바는 정말 재섭는 언어다..
개넘들.. $UN .. 자바 프로그래머 다 주그라..
그것도 Skill 이냐?

익명 사용자의 이미지

자바 최고의 미덕은 개발자를 스킬의 늪에서 엔지니어링의 초원으로 끌어올리려고 시도나마 하는 언어라는 거 아닐까.
스킬이 그리 좋은가. 난 지겹다.

익명 사용자의 이미지

동의함다.

익명 사용자의 이미지

그런 뭐가 Skill이냐?

조기태의 이미지

과거 프로그래머의 스킬이라면, 특정 하드웨어나 플랫폼 등에 특징적인 기술들을 많이 알고 있고 효율적으로 메모리를 관리하고 퍼포먼스를 끌어올리는게 중요한 미덕이었다고 생각합니다.

하지만 특히 최근의 엔터프라이즈 컴퓨팅 환경에서는 단지 로우레벨의 시스템 리소스 핸들링이나 복잡한 자신만의 알고리즘으로 약간의 퍼포먼스를 끌어내는 것보다는 컴포넌트 기반 분산 환경에서 얼마나 빠른 시간에 안정적으로 동작하는 대규모의 어플리케이션을 조합할 수 있는가가 관건이라고 봅니다. 그런 관점에서 선의 J2EE나 MS의 .NET처럼 전통적인 '스킬'보다는 보다 높은 관점에서 프로그래밍을 보게 하는 플랫폼들이 부상하고 있는 것입니다.

그럼.

익명 사용자의 이미지

읽고 보니 공감이 가는군요.
자바는 시스템 풀그리밍을 위한 언어는 아니죠.
필요한 목적에 따라 적절한 언어가 있는 거겠죠. 글쿠 풀그래밍은 기능적인
구현이 중요한 것이지 기술이 중요한 건 아니죠.. 풀그래머라면 역시 언어에
제약받지 않구 프로젝트에 적합한 환경에서 작업할 수 있는 능력이 있어야 하겠죠.
개인적으루 C/C++ 기반의 VM 프로젝트나 C를 맹글었던 아저씨였던가?
아님 Unix를 맹글었던 아저씨였던지 정확히 기억은 안 납니다만 그 아저씨가 주축이
돼서 개발하고 있다던 또 다른 VM 프로젝트가 가시화돼서 Java, .Net 과
경쟁하는 모습을 보고 싶습니다.

좀 두서가 없었죠? 그럼 즐통..

shei77의 이미지

자바에 애착이 가고 기능 또한 괜찮습니다.

J2EE쪽으로요..응용app 만들기에는 다소 힘든 점이 있지만,

솔직히 C좀 하던 사람이 자바하면 빨리 배웁니다. 저만 생각하는 건 아니겠죠..

MS와 다른 독자적인 길을 걸어온 자바와 .net을 우열을 비교하는 거나

승패를 겨룬다라는 건 이상합니다.

나름대로의 특수성이 있으니까 쓰는거고 IBM회사가 견제를 위해 은근히 투자해준

eclipse도 있고.. 할 만하다고 봅니다.

----------------------------------------------------------
It's feasible to make an inspiration on your own.

rx78gd의 이미지

2001년에 쓴 글을 2007년 지금 다시 보게 되니 매우 흥미롭습니다..^^

근데 현역개발자로서 말한다면 저때 죽는다던 자바는 아직도 쌩쌩히 살아있죠..^^;; 프로젝트들도 보면 아직도 닷넷쪽 프로젝트들은 자바관련 프로젝트에 비해서 현격히 그 수가 적은게 사실이구요. 모르겠습니다. 닷넷쪽은 이제야 프로젝트들이 슬슬 시작하는 분위기인 사이트들이 있어서 한 5년후즈음 보면 닷넷이 득세할수도 있겠지만 어쨌든 저 글을 쓴지 6년이 지난 지금까지도 자바는 쌩쌩히 살아있다는 것은 사실이니까요.

뭐, 5년후즈음 닷넷이 득세할때즈음이면 뭐 또 다른게 나와서 '닷넷은 죽었다'소리가 나올지도...

ps: 근데 자바라는 언어와 플랫폼을 비교한다는것도 참 웃긴 일이기는 하네요... 차라리 C/C++에 비해 자바가 죽는다는 소리라면 모를까..쩝
-------------------------------------------------------------------------------------------
나에겐 할 수 있다는 의지와
하면 된다는 신념과
해야 한다는 의무가 있다.

http://rx78gd.egloos.com

-------------------------------------------------------------------------------------------
나에겐 할 수 있다는 의지와
하면 된다는 신념과
해야 한다는 의무가 있다.

http://rx78gd.tistory.com

nalrim의 이미지

현재 스코어는 아직까지도 자바 우세인것 같네요.
부족한 식견으로는 앞으로도 자바가 60% 닷넷이 30% 루비,파이썬,PHP가 10% 정도로 시장을 나눠가지게 될 것같습니다.

예전에 면접보면서 느낀건데 Java개발자는 구하긴 힘든 사람들, 비싼 인력, 고급 기술자라는 인식이 박혀있는듯 했습니다. 같은 개발자인 제가 봐도 Java하시는 분들은 대게 품질좋고 훌륭한 코딩능력을 가진것으로 보여집니다.

익명사용자의 이미지

구루 가라사데 '도구는 도구일 뿐이다'
해커 가라사데 '이 도구로 어떤 일들을 할 수 있는지 파헤쳐 보리라'
초보 가라사데 '내 도구가 최고다'

도구는 도구일뿐 잘 쓰면 그만이다.

익명사용자의 이미지

도구는 도구일뿐 따지지 말자

익명사용자의 이미지

java VM위에서(이하 JVM) 돌아가는 언어 많이 있어요.
JVM이 java언어 종속적이라고 말하기에는 좀 그렇죠.
java만큼 범용이 아니고 제대로 설계되어 주목받는 언어가 없다 뿐이죠.

넓게 봤을때 'JAVA는 서버기술에 국한되어 사용된다'에 한표 던집니다.
윈도 비스타 이후부터는 .NET이 기본으로 장착되어 나올텐데...
현재 웹이 리치클라이언트로 간다고 봤을때 .NET의 선택은 필연적이게 되지요.
더불어 서버사이드에서도 .NET의 입지는 넓어지기 쉽다고 봐야겠지요.
포터블 디바이스의 경우도 데스크탑과의 호환성을 위해 .NET이 현 시점보다 많이 고려되겠죠.
JVM이 올라가는데 CLR이 못올라갈 이유가 없다고 생각하거든요.

저의 결론은.. '자바는 입지를 조금씻 빼앗긴다.' 구요.
차후 자바가 유력하게 고려되는 시점은 (윈도우 비스타 이상의 OS가 주류가 되었을때)
.NET보다 공개된 라이브러리가 많이 때문에 개발 속도면에서 이득이 된다고 판단될때와
서버에서 .NET을 선택할수 없을때 정도?? 라고 말씀드리고 싶습니다.

익명사용자의 이미지

자바는 너무 느리고... 배우기도 힘들고.. 설치하기도 힘들고..
심지어는 특히 자바하는사람들중 (물론일부라고 믿고 싶습니다만) 말만번드르하게 해놓고
정작 시키면 할줄아는거도 없고...

자바 실망이큼..

익명 사용자의 이미지

언어가 아니라 플랫폼이죠

win32 api가 몇개인줄 아십니까?

java 클래스랑 메소드가 몇개인지는?

.net 클래스랑 메소드도 엄청나죠-_-;

어느 한곳의 플랫폼에서 만개의 메소드를 알고있다면 대단한것입니다.
이러한 사람이 다른곳으로 옴겨갈수 있을까요???
이쯤 대면 경력이 쌓여서 움직일수도 없죠

자바의 단점은 OS가 없다는것입니다. OS상의 한가지 어플로 동작을 하는것이죠
하지만 MS의 닷넷은 OS안에 내장을 시킬수 있다는 것입니다.
자바의 속도향상은 한계가 있지만 닷넷은 그보다는 더 빠를수 있다는점이죠

제가 생각하는 가장 큰 단점은 디자인입니다.
자바가 일반 어플에서 많이 안쓰이는 이유는 느리것도 있지만 디자인이 영 이상하기 때문이죠
win95 시절의 어플보다 더 구려보이는...
물론 스윙이니 SWT니 하는 기술이 있지만 MS가 CLR을 OS 안에 내장을 시키면
OS -> CLR -> JVM -> 어플-_-; 이런 괴상한 구조가 나오겠죠
이러면 J#이 더 좋지 않을런지?

전 C#은 조만간 사라질거라 생각합니다. 개인적인 생각이지만 C++의 편리한 버젼 정도? 언어적인 개성이 없습니다.
2010년 쯤에 새로운 언어를 내놓을지도...

이정도 되면 윈도우즈 환경에서 java를 이용할 필요가 없습니다. 임배디드 환경도 CE를 탑재하면 되는것이죠
여러분들이 생각하기에 CE 보다 강력한 임배디드용 OS가 있나요? 기준은 이미 만들어진 것을 기준으로 합니다.

한가지 다른 가능성이 있다면
개발자들이 MS의 횡포를 알고 있다는 것입니다.

lunarboy의 이미지

닷넷이니 자바니 연식으로 보면 이제 뭐 같이 늙어가는 처지입니다.
그만큼 세상에 출현한 지 오래되었고, 어느 분야든 현 상황에서 그다지 큰 변화가 있을 껀덕지가 없어 보이네요.
그나마 비스타의 대중화에 따른 데스크탑 분야에서 지금보다야 닷넷용 어플이 많아지겠지만,
굳이 Win32 나두고 닷넷 프레임웍 위로 올릴 필요가 없어 보이기도 하고요.

creativeidler의 이미지

이 쓰레드를 지금 다시 보니 새롭네요. 5년이 지난 지금 여전히 자바는 점유율 1위를 굳건히 지키고 있고 C#은 상승세가 한풀 꺾인 상태, 파이썬에게 다시 밀렸고 루비의 위협을 받고 있죠. 물론 데스크탑 애플리케이션은 .NET이 잡아가겠습니다만 엔터프라이즈는 앞으로도 자바가 강세일 테고 자바를 위협할 가능성이 있는 건 .NET보다는 RoR류가 아닐까 싶네요.

magingax의 이미지

그럴리가요..푸후..

LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr

bookgekgom의 이미지

날짜를 보니 6년 전 꺼군요...

어쩐지..

미국대학에서는 자바를 배웁니다.

일자리에서도 자바를 원합니다.

----------------------------------------------------
허접한 페도라 가이드 http://oniichan.shii.org

---------------------------------------------------------------------------------------------------------------
루비 온 레일즈로 만들고 있는 홈페이지 입니다.

http://jihwankim.co.nr

여러 프로그램 소스들이 있습니다.

필요하신분은 받아가세요.

wizzet의 이미지

제가 생각하는 결론은 다음과 같습니다.

"처음 글은 쓰신 분은 지금 매우 열심히 .NET을 공부하고 있다."

--
Good design requires compromise.

--
Good design requires compromise.

jinho 의 이미지

안녕하세요? 서진호 입니다.

위의 글들을 모두 하나씩 하나씩 다 읽어 봤습니다. 마치 닭이 먼저냐? 달걀이 먼저냐? 그런 싸움 같습니다. 제 생각에는 둘다 앞으로 영원히 존재할 것 같습니다. COBOL이나 Fortran 이 아직도 사용되는 곳이 많습니다. 몇가지 글들 중에 사실이 아닌 것이 있어서 정보를 드리고자 메시지를 남깁니다.

첫째, Windows CE 및 스팅거(현재는 Windows Mobile for Smartphone 이라고 부름)과 같은 데 공통적으로 돌아가는 런타임(4대 프로세서 모두 지원)이 .NET Compact Framework 입니다. Java 가 Embedded java 또는 Mobile Java 로 동작한다면 Microsoft는 .NET Compact Framework 에서 지원합니다. 단, 임베디드는 Real-Time 이라는 특수성을 제공해야 합니다. 따라서 그러한 디바이스 드라이버는 여전히 하드웨어 이식성 때문에 C나 C++이 많이 사용되고 있습니다. 그래서 좀더 CPU와 메모리 성능이 높아진다면 virtual Machine 이나 Managed 환경에서 임베디드 소프트웨어를 동작시킬 수 있을 것 같습니다. 그러한 컴퓨팅을 네트워크 컴퓨터(NC)라는 것을 SUN이 도입했었지요. 그러나 고객들에게 호응이 못 얻어서 실패했지요 -_-

둘째, .NET두 이번에 .NET Framework 3.5를 Visual Studio 2008 개발도구를 발표하면서 .NET Framework 3.5 라이브러리를 공개합니다. 과거 Visual C++ 때 MFC 라이브러리 소스를 공개한 것처럼 .NET Framework 또한 라이브러리 소스를 공개하여 개발자들에게 디버깅을 좀더 원활히 지원하고자 하는 데 목적이 있습니다. 그리고 .NET이 현재 1.0, 1.1, 2.0, 3.0, 3.5 버전으로 다섯번 업그레이드 되면서 많이 안정화 되었고 최신 Windows Vista 를 지원한답니다. 도대체 MS 엔지니어들이 어떻게 코드를 짜는 지 궁금한 분들은 Visual Studio 2008 평가판을 다운로드 받아서 사용해 보세요. 왜? 개발툴에 소스 코드를 통합시켰냐고 반발하시겠지만 .NET Framework 소스를 직접 디자인(Design)이나 수정하는 일 보다 현재 개발하고 있는 프로젝트 코드가 Managed(.NET) 환경에서 올바르게 동작(메모리 누수 및 핸들 누수,쓰레드 락킹)이 있는지 더 잘 파악하기 위함입니다.
자세한 내용은 http://blogs.msdn.com/jinhoseo/archive/2007/10/16/net-framework.aspx 를 참조하시기 바라고 .NET Framework 소스를 수정하거나 디자인에 참여하고 싶다면 ECMA에 공개 되어 있으니 참고하시기 바랍니다.

셋째, .NET Framework 나 C# 언어는 ECMA에 벌써 표준이 된지 오래된 일입니다. 그래서 리눅스에서 동작하는 모노(Mono)와 같은 프로젝트가 이루어지게 되었고 현재 노벨에서 투자하여 Silverlight와 같은 멀티 브라우저 런타임을 리눅스에서도 동작하기 위해 프로젝트 중에 있습니다. 참고로 Silverlight 는 이미 Firefox 나 Opera 와 같은 웹 브라우저를 지원합니다.

trrr의 이미지

넘길어서 중간부터는 대충봤는데.. 아직은 자바가 우세하네요 ^^

kaeri17의 이미지

자바는 제일 널리 쓰는 언어가 되었지만 .Net 플랫폼은 아직 걸음마 수준.

게다가 UI개발에 .Net이 좋아도 속도는 느리고 ms에서도 아직 mfc를 포기 안함. 오히려 더 밀고 있다나?

임베디드쪽은 자바보다 훨씬 불투명한 .Net, 라이브러리도 무겁고

나는 C/C++만을 주로 사용하고 좋아하지만 아무리 WIN32 API가 불편하다고 생각해도

.NET은 별로 끌리지 않는다..

all4you의 이미지

1메가도 안되는 실행파일 돌리려고 20메가 넘는 런타임 돌릴래

뭘로 작성해도 닷넷없으면 안되는거 ..한마디로 윈도우 아니면 안되는 환경에서 어떻게 일할래...

g0rg0n의 이미지

오프토픽이긴 하지만
아르에스에스에 떠서 왔는데 칠년전 글이네효;;

18

sangheon의 이미지

2001년의 글을 다시 보니 재미있군요.

요즘 Java와 .Net은 어떤가요? 매일 리눅스에서만 개발하다 보니 이쪽은 둔감하군요.

--

B/o/o/k/w/o/r/m/

--

Minimalist Programmer

avelose의 이미지

오래된 글이지만 몇자 첨언해 봅니다.

저도 MS진형에서 일하는 사람이고 그 중에서 돈 벌이로 .Net과 .Net CF를 사용하고 있는 사람입니다.
자바 진형의 J2ME나 KVM쪽에도 관심이 있고, 최근 Android를 계기로 다시 Java쪽도 손을 대려고 하고 있습니다.

일단 두 진영 다 호환성이 형편없습니다.
외려 리눅스를 기반의 환경이 임베디드와 데스크탑쪽에서는 호환성을 살릴 수 있는 방식으로 보입니다.

VM이라는 종자가 왜 있는 지도 모를 정도로 SUN과 MS는 VM에서도 호환성(그런 것이 있어선 안되지만..)을 갖게 만들었더군요.
저수준 제어를 해야만하는 환경은 퍼포먼스를 살려야 하는 부분에서만 생각했으면 되었을 것 같은데, GUI를 구성하는데도 각 플랫폼에 따라 별도의 라이브러리를 써야 하는 놈이 있는가하면, 분명 동일한 객체처럼 보이지만 전혀 다른 객체를 만들어 내어 놓기도 했습니다.

그런 의미에서 리눅스쪽의 소스 호환성은 혀를 내두를 정도입니다.(물론 제대로 짠 코드여야 겠지만 말이겠죠.)
호환성은 둘째치고 퍼포먼스 면에서도 뛰어난 환경입니다. 그에 비에 JAVA나 .Net은 엄청나게 떨어지죠.

.Net CF는 이걸로 밥을 먹고 살기 때문에 확실히 말할 수 있는데, MS에서 과연 .Net CF를 계속 진행하려고 하긴 하는지 궁금할 정도입니다.
소형화를 꾸미려고 제한되고 작은 환경을 꾸미는 것은 좋았으나, 개발환경으로는 영...
.Net CF개발자 중에 .Net 코딩만으로 해서 프로그램을 만들었다는 사람이 있다면, 그 프로그램이 아주 단순한 것이거나 예외처리 등이 없는 싸구려 코드라고 밖에 말할 수 없을 정도로(pda프로그래밍을 하면서 전원에 대한 처리조차 안했다면..) winCE API를 써야 함에도 불구하고 API용 invoke라이브러리 지원이 없어서 WinAPI를 별도로 알아야하며(뭐 데스크탑 환경도 거기서 거기지만...), 때에 따라서 서드파티 툴을 사용해야 하는 경우가 빈번하게 발생합니다.(.Net CF개발자라면 OpenNetCF 라이브러리를 기본적으로 알아야 할 정도로..)

제가 봤을 때는 이러한 모습은 자바에서도 나타날 수 밖에 없는 문제로 보입니다.

개발이 어렵고 자료를 구하는 것이 쉽지 않으며, 자신이 어렵게 배웠기 때문에 남에게 자료를 공개하기도 어렵게 만드는 것이 현재의 임베디드 진형이죠.

개인적으로 느낀 점은 자바나 .Net이나 그놈이 그놈이고, 두 진형 다 개발툴은 싸질러 놨으니 개발은 알아서 해라 식인거죠.

그나마 요즘은 시리얼라이즈를 통해서 완벽하게 공통된 라이브러리 등을 사용할 수 있어서 좋기는 하지만 배포상의 문제, 인터페이스의 설계 등의 문제가 있어서 실무에서는 써먹지도 못합니다.

---

그나저나 한국 MS쪽의 서진호 차장님도 KLDP쪽의 스레드를 보고 계시군요.
임베디드쪽 담당자이기 때문에 글을 읽다가 댓글을 다셨던 듯 하네요.

'현실은 수학으로 표현할 수 없다.'
'수학은 거짓의 학문이다.'
'난 수학이 정말 싫다.'

'현실은 수학으로 표현할 수 없다.'
'수학은 거짓의 학문이다.'
'난 수학이 정말 싫다.'

kenndryke의 이미지

.NET과 Java의 미래는 그 둘의 기반인 Windows와 Multi OS의 지원을 보면 알수 있지 않을까요?

1. 임베디드환경
- 저는 솔직히 임베디드경에서는 .NET을 좀더 점수를 주겠습니다. .NET Platform은 GUI특성상 임베디드환경에서
매우 우수한 그래픽 유저 인터페이스를 제공해 주고 있습니다. 다른 OS들도 일부 선전하고 있지만, GUI면에서
Windows 계열 Platform을 못따라 가더군여.. 임베디드환경에서 Windows계열 OS가 깔려 있는데 Java VM을 또
설치해서 Java App.를 수행할 사람은 없겠죠?

2. 일반 사용자환경
- 일반사용자 환경이라면 다들 Windows와 Internet Explorer의 절대적 우세라고 생각하시는데 오히려
이 환경에서 Windows가 위협을 받고 있습니다. 다들 아시다시피 그동안 사용자가 Windows를 쓰는 이유는
보통 일반적으로 많이 쓰는 OS이길래 쓴다는 이유 외에 다음과 같은 어쩔수 없는 상황이 그동안 지속되었습니다.

1) Game
2) Microsoft Office
3) Internet Explorer의 ActiveX 기능 (인터넷뱅킹, 온라인결제 등)

물론 이 외에도 여러가지 이유가 있겟지만 상기의 3가지 이유는 어떤 다른 OS로도 대치가 불가능했었고
그부분은 Windows를 쓸수밖에 없도록 만들었습니다.

그러나 현재 상황이 조금 바꼈죠

1) 기존에는 PC게임이 절대적 우세였으나 현재는 온라인게임을 제외하고 일반 게임은 전용게임기로 주류가
넘어간 상황입니다. 온라인게임에서도 스타크래프트정도는 집보다는 PC방이고 일부 소프트웨어(WOW)는
타 OS(Mac버전)이 있습니다.

2) Office는 예전 Windows의 킬러소프트웨어였습니다. 업무상으로 필수적인 소프트웨어 였죠.. 하지만
Sun의 OpenOffice를 한번 써보세요 Windows, Mac, UNIX, LINUX를 모두 지원합니다. 게다가 MS Office
와 100% 호환합니다 (매크로 일부기능제외) 물론 꼭 이것뿐만아니라 MS Office호환되는 많은 타 OS용
소프트웨어가 개발되고 있습니다.

3) 이게 치명적입니다. Internet Explorer의 ActiveX기능은 Windows의 OS의 기능을 사용하기 때문에
둘을 분리할수도 다른 OS에서 사용가능하지도 않습니다. 물론 해외에서는 인터넷뱅킹, 온라인결제등을
ActiveX기능을 사용하지 않고 구현해 (특히 ebay, PayPal 등) 놓았습니다만, 한국은 무조건 ActiveX입니다.
하지만 최근에 나온 Ajax기술은 ActiveX기술을 쓰지 않고서도 ActiveX의 기능을 구현할 수 있고 게다가
OS독립적으로 구현하도록 만들어진 기술입니다. 만약 이것이 확산될경우에는 Windows는 치명적이겠죠..
그런데 ActiveX기술로 인해 MS가 소송이 걸린 이후부터 AJax기술을 추천은 하더군요.. ㅋㅋㅋ

이와 같은 상황으로 현재 사용자 PC환경에서 Windows의 장래는 과거와 같이 독점적이기 힘들게 되었습니다.
예를들자면 점점더 Apple사의 iPod처럼 Mac이 점점더 사용자층을 넓혀갈수 있습니다. 아시다시피 현재 MacOS는
Intel CPU에서 UNIX기반입니다.

이 경우 PC환경에서 과거와 같이 .Net이 매우 우세한 기술이 되기는 힘들듯 합니다. 게다가 최근에 Windows Vista는 극악의 하드웨어 환경과 더 극악의 보안관련부분으로 인해 확산에 제동이 걸리고 있습니다. 더이상 사용자들이 Windows XP이상의 GUI를 원치 않고 있구요

따라서 앞으로는 Windows의 독점보다 Mac과 LINUX를 필두로 여러OS가 사용될 가능성이 높습니다. 이런 환경에서는 두말할것도 없이 OS독립적인 Java가 현재보다는 사용자환경에서 좀더 많이 사용되지 않을까요?

3. 서버환경
이것은 구체적으로 설명드릴필요없이 Java의 우세라고 말씀드립니다.

이와 같은 것으로 보면.. 전체적으로 .NET Platform이 Sun의 Java VM에 조금씩 밀리는 형국으로 보입니다.

avelose의 이미지

kenndryke님 몇 글타래 위에 보면 서진호 차장님도 얘기를 꺼낸 얘기이지만요.
현재 .Net의 경우 모노 프로젝트라는 명칭으로 리눅스와 맥에서 사용이 가능합니다.

우선 자바환경이 임베디드에서 밀리는 것은 썬사의 라이센스 정책이 워낙에 비싸고, UI환경에서도 아도브의 플래쉬임베디드 버전에 비해 떨어지기 때문에 문제가 되는 경웁니다.

CE진영의 경우 개발회사에서의 라이센스(CE용)를 제외하면 닷넷의 경우엔 라이센스 비용이 없습니다. 또한 소형 데이터 베이스인 MSSQLCE등도 무료입니다.

마소의 경우엔 유비쿼터스쪽을 또 다른 전쟁터로 잡았지만, 썬의 자바는 임베디드에서 시작을 했지만 외려 서버쪽이나 데스크탑을 노리고 있습니다.

비싼 라이센스 비용만 봐도 시장의 확대를 저해하는 요소임이 분명하죠.

임베디드 쪽은 거의 아도브와 마소의 싸움으로 일단락 되었습니다.
마소의 경우 아도브의 진입을 막기 위해 실버라이트를 CE플랫폼으로 옮기는 것만봐도 아도브를 견제하는 거지 썬을 견제하는 것이 아니라는 것은 쉽게 알 수 있습니다.

안드로이드 등의 임베디드 환경을 좋아하는지라 리눅스용의 별도 환경도 꾸며놓고 사용하는데, 현재 WxWidget 라이버리를 이용한 업무용 프로그램들의 경우엔 윈도우, 리눅스, 맥에서 공통으로 사용이 가능할 정도입니다.

리눅스 환경에서 모노디벨로퍼로 개발해 본 느낌으론 마소에서 잘한 선택으로 보입니다. 리눅스 환경에서 힘겹게 코딩하던(물론 그걸 즐기시고, 퍼포먼스 때문에 쓰시던 분들도 많았겠지만) 것과는 천지차이나게 쉽게 개발이 가능하더군요.

일반적인 어플의 경우에 많은 부분을 잠식해 들어갈 가능성이 있습니다.
윈도우 측에서도 wxWidget을 이용해서 개발할 경우, 각 플랫폼에서 빌드만 해서 돌려도 문제 없을 정도의 코딩이 가능한 부분도 어면히 존재합니다.(API를 제외했을 경우.)

AJAX는 신기술이 아닙니다.
외려 오래된 기술이며, 기능적인 한계로 인해 ActiveX와는 완전히 다른 기술입니다.
한 때, 익스플로러에서 프로그램과 같은 환경을 꾸미기 위해 적은 노력으로 처리하기 위해 액티브엑스를 많이 사용했지만, 원래 이런 용도로 만든 기술이 아닙니다. OCX 기술쪽에서 파생된 기능이기 때문에 형태가 무척이나 다릅니다.

파이어폭스의 플로그인과 같은 용도로 사용하기 위해서 만들어졌으나, 편함을 추구하던 개발자들의 의해 변질된 케이스입니다. 그리고 이런 케이스는 우리나라의 암호화정책과 맞물려 어쩔 수 없던 선택이 될 수밖에 없었습니다.

개발자들의 대부분이 액티브엑스의 문제점을 알고 있는데, 은행이나 관공서에서 괜히 액티브엑스를 아직도 만드는 것이 아닙니다.

서버환경.
압도적으로 자바가 유리합니다.
성능상 많은 저해 요소가 있지만, 압도적인 이유는 엔터프라이즈환경에서 윈도우즈 환경을 선호하지 않기 때문입니다.
윈도우즈 서버의 성능은 아직 유닉스 계열의 성능과 호환성을 따라잡기엔 힘듭니다. 몇몇 엔터프라이즈 환경용 디바이스의 경우엔 윈도우즈용 드라이버는 없는 경우도 존재합니다.

이런 환경에서 빠른 개발이 필요할 경우, 어쩔 수 없이 고룰 수 밖에 없는 것이 자바 환경이죠.
성능이 뛰어나서 자바를 쓰는 것은 아닙니다.

막말로 TCP소켓 서버를 자바로 만들어 놓은 놈 보다, C++로 만들어 놓은 놈이 더 빠르고 자원 소모도 적습니다. 그러나 개발 기간 등을 놓고 보면 그런 우위는 하드웨어로 충당할 수 있습니다.

게임은... 글쎄요.
게임은 게임기에서... 윈도우즈의 게임은.. 에휴.
게임 개발환경이 압도적으로 윈도우즈가 좋습니다.
다만, 닷넷을 이용한 게임 개발의 경우엔 씨뿔이나 어셈의 지원이 없을 경우에 너무 어이없는 퍼포먼스를 제공하기 때문에.. 자바진형과의 비교에서 나올 필요는 없을 것 같습니다.

어짜피 자바나 닷넷이나 사용자가 많은 환경에는 다들 사용이 가능한 현재의 환경에선.. 여러 플랫폼을 지원한다 보다는 진정한 호환성이 이뤄지는 버츄얼머신이 승리할 것으로 보입니다.
다만, 자바 진영에선 그 것을 기대하기란 어렵다고 느끼는 부분이 임베디드 분야였을 뿐입니다.
(그런데, 이 부분도 구굴에서 뒤엎어 놓았으니.. 앞으로 재미있는 현상이 벌어질 것은 확실합니다. 안드로이드의 경우엔 리눅스커널에 자바 루트환경이니 ㅎㅎ 기대가 됩니다.)

'현실은 수학으로 표현할 수 없다.'
'수학은 거짓의 학문이다.'
'난 수학이 정말 싫다.'

'현실은 수학으로 표현할 수 없다.'
'수학은 거짓의 학문이다.'
'난 수학이 정말 싫다.'

bluewolf의 이미지

뭐.. 결과적으로 지금은 틀린 얘기지만^^;

소프트웨어 엔지니어
- MHP 미들웨어 개발
- WAS 개발 (현)

소프트웨어 엔지니어
- MHP 미들웨어 개발
- WAS 개발
- Backend 서버 소프트웨어 개발

abcdefgefghxxx의 이미지

아무거나 배워서~ 썬사 망하면 ms에 붙고 ms망하면 썬사에 붙으면 되죠~ㅋ

둘다 망할리야 없는 회사지만..

결론은.. 너무 걱정할 필요 없다는거.. 서민개발자..ㅠㅠ 화이팅

God bless you^^

bluedisk의 이미지

8년간에 걸친 댓글에서 도통 발전할지 모르는건

플렛폼/OS/언어/개발환경 구분 좀 하고나서 아는척을 합시다.

장님 코끼리만지기도 아니고 한 1/3은 자기가 아는것만

얘기하면서 도통 엉뚱한 소릴 하고 있으니 참...

bookgekgom의 이미지

저도 그말하려고 했는데 ㅋㅋㅋㅋㅋ

---------------------------------------------------------------------------------------------------------------
루비 온 레일즈로 만들고 있는 홈페이지 입니다.

http://jihwankim.co.nr

여러 프로그램 소스들이 있습니다.

필요하신분은 받아가세요.

reikir의 이미지

자바 언제 망하나요?

iolo의 이미지

언젠가.... 망하겠죠.

그런 의미에서 본다면 이 글의 결과는 "참"일 가능성이 훨씬 높네요.
자바보다 닷넷이 더 나중에 나왔으니까요^^'

----
the smile has left your eyes...

----
the smile has left your eyes...

sora24의 이미지

오라클 + 썬 합체 IMB 대항마로 부상!

익명 사용자의 이미지

이글 쓰신 분 지금 시점에 자바를 하고 있을것같은데요. ㅋㅋㅋㅋㅋ
결국 자바는 하나의 언어 이상의 영역을 아우르게 되었습니다.
자바를 만들었던 일원 중에 한분인 제임스 고슬링 할아버지도 오라클을 떠나면서 자바는 이제 스스로 자생력을
가졌다 라고 했으닌깐요.사실 개발자한테는 언어는 도구일뿐 이라고 하지만 그건 정말 경지가 높으신 분들이나 해당되는
말인것 같습니다.언어에 따라 의도치 않은 타격(?) 을 받으시는 개발자들도 있으닌깐요.

mirheekl의 이미지


10년도 훨씬 전에 쓰여진 글인데 비교적 정확한 예측이 되어 있네요.

다만 모바일로 넘어오면서 발생하게 되는 MS의 거한 삽질(내지는 안일한 대처)때문에 판도가 바뀐 것이겠지요. 이것까지 예측할 수는 없는 노릇.

그럼에도 불구하고 닷넷의 현 입지가 자바에 못지 않은 걸 보면 (물론 한국은 예외) MS도 참 대단합니다.

--

24년에 왔다갑니다.의 이미지

둥근펜이던 형광펜이던 샤프던 중요한건 종이에 뭘 적냐는 거죠.
중요한건 내용물이지 기술이 아니라는걸 모르는 헛똑똑이의 말이 심지어 틀리기까지 했으니 빅웃음만 짓고 갑니다.
드보락에서 배운게 아무것도 없는 범부여

페이지

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.