nobocop

SWT 가 처음 mac os x 으로 porting 된 기반이 carbon 인건 너무도 당연한 얘기 이겠습니다.
java 의 jni 를 통해서 objective c 를 콜한다는건 상상하기도 힘든 일이니까요.

apple 에서도 carbon 을 내다 버리려는 시도가 leopard 에서부터 시작 된 듯 해서 내심 걱정이었습니다. x86 호환 프로세서들이 64bit 으로 이전하면서 과거 x86 호환 instruction set 을 EMT64 에서 제거 하듯이 애플도 64bit os 인 leopard 를 내놓으면서 carbon 지원을 32bit 에만 한하려고 하네요. (다들 아시다 시피 Tiger 는 64bit os 라고 부르기에 어려움이 있었죠. backend 에 headless process 를 올리고 ui part 는 32bit 으로 만들어야 했으니까요)

애플에서 내린 결정에 당혹 스러워 한 것이 이번이 두번째 인데요.
첫번째는 java cocoa binding 을 drop 한다는 소식이었습니다. 역시 java 개발자 눈엔 이런것만 보이게 마련인거죠. ㅡ.ㅡ;;;
그리고 이번 leopard 부터 64빗은 cocoa 만 지원 한다는 결정이 었습니다. objective-c 가 smalltalk 만큼이나 OO 를 지향하는 멋진 툴이고, java 만큼이나 유연한 것은 인정하더라도 cross-platform 을 추구하는 개발자들에겐 커다란 걸림ㄷ로입니다. carbon 은 꼬옥 필요한 물건 이었던 거죠.

서론이 길었네요. 그런데 얼마전 갑자기... 자타가 공인하는 SWT의 아버지인 Steve Northover 가 SWT를 cocoa 로 포팅을 시작 했습니다. 그간 소문이 무성 했죠 SWT는 왜 cocoa 기반이 아닌가 하고.. 몇몇은 SWT 나 cocoa 나 둘다 1st class citizen 으로 대접받을 동등한 레벨이기 때문에 어려웠을 거라는 둥 ...
제 짐작은 objective-c 라이브러리와 binding 하는 문제 일거라고 믿었습니다만..
object->method(args...) 의 형태가 아니라 [id sel args...] 이므로 보기부터 어려워 보입니다. ㅡ.ㅡ;
헌데 steve 가 gcc 가 생서한 넘을 asm 으로 확인 하더니 OS.msgSend(id, sel, args...) 형태로 내부 구현 되는 것을 확인 하더니 몇일 후 obj.method(...) 스타일로 콜할 방법을 찾아 낸 듯 하더군요.
일주일 만에 SWT 위젯들이 보이기 시작 하더니 2주일 후 eclipse 가 실행은 되었다고 합니다. 아무리 능력있는 개발자지만 이쯤 되면 미친 사람으로 보이네요 ㅡ.ㅡ; 아 자존심 구겨져..
Inside SWT: Hacking at Apple

SWT: The Standard Widget Toolkit 에 보시면 news 에 좀더 자세한 내용들 링크가 있습니다. eclipse 가 cocoa 로 이사가는 그날까지... 밤잠이 안올듯 합니다.

yoonopt

내용을 끝까지 읽어보았습니다만, 프로그래밍을 알지 못하는 전 대충 이클립스가 맥에서는 안되었는데 코코아로 포팅되었다 이건가요? 암튼 맥 프로그래밍에 관심이 있는 저로선 무척 흥미로운 내용입니다. 잘 읽었습니다.

__________________
똥을 더럽다고 생각하지 않은 사람을 경계하라.

그 사람은 삶을 초월했거나 전생에 소똥구리 였을 것이다.

- oum 13:1~4 -

nobocop

글이 좀 모호 했나보네요. 횡설 수설이 제 주특기 인지라...

Eclipse 는 지금도 돌아갑니다. 다만 Cocoa 가 아니라 Carbon 위에서 돌았던 것 이죠.
새로운 기능들은 죄다 Cocoa 로 만들어지다보니 Carbon 은 이런 저런 신기능들을 지원 받지 못합니다. 많은 기능들을 구현 할 수 없는 것은 아니더라도 스스로 만들어 써야 하는거죠 Cocoa 에선 이미 있는 기능일지라도..

헌데 이번에 Cocoa 로 옮기려는 노력이 시작 되었고 무심히 있다가 오늘 3.3.2(아직 release 는 아닙니다) org.eclipse.swt.internal.cocoa 인가 하는 패키지가 있더군요. 3.4 에 들어 갈 수 있으면 합니다만.. swt-devel 뉴스그룹을 뒤져볼 시간은 없었습니다.

neofeel

드디어 SWT가 cocoa 기반으로 돌아가게 되는 건가요? 아주 반가운 소식이네요. 이제 java6 정식판만 나오면 되겠네요.

Lee,Chan-gu

그냥 몇 가지 문득 떠오는 것들이 있어서 적어봤습니다.

저는 Java 개발자는 아닙니다만, Mac OSX의 Java VM은 애초에 Sun이 아닌 Apple이 개발했다는 점에서 Java 이식성에 대해서는 별로 믿음이 가질 않았습니다. 그도 그럴 것이 Java 개발을 했던 시절에는 Windows 환경에서 MS가 개발한 Java VM으로 개발했었습니다만, MS 입맛대로 만든 것이라 Java VM이라 불리기에도 민망한 놈이었죠. 그때의 기억이 그대로 Apple이 개발한 JavaVM에 겹쳐지다 보니 Mac OSX에서 Java 언어를 이용한 개발도 가능할 것이다라는 정도의 생각만 들지 Mac OSX에서도 Java 개발이 가능하다라는 생각은 안 들더군요. 이 점에 대해서는 Apple 보다는 Sun이 좀 더 원망 스러운 것이 나름대로의 사정이 있을 수 있겠지만, Windows에서도 MS Java VM과 Sun Java VM을 골라서 쓸 수 있었던 것 처럼 Mac OSX에서도 나름대로의 선택사항이 가능했으면 좋겠다는 생각이 듭니다. 또 한편으로 드는 생각은 Mac OSX에서 Java 개발을 하는 분들은 어떤 생각을 가지고 계신지도 궁금하기도 합니다.

마찬가지로 Java에 대해서는 깊게 알지 못해 요즘 흔히 얘기하는 Java 기술이나 용어에 대해서는 너무 생소한 관계로 좀 깊은 얘기를 하기는 힘듭니다만,
제가 언급하고자 하는 부분만 추려봤습니다.
미숙한 제가 느끼기에 왜 Java VM에서 Object C루틴을 콜하는 것을 어렵게 생각하나 하는 생각입니다. mono 프로젝트에 대해 얇게나마 살펴본 제 입장에서 Java VM의 확장성은 말 그대로 충격이었습니다. Wrapper의 수준에 불과했지만, Cocoa#만 해도 Java VM을 이용해서 .NET 언어들이 Cocoa 라이브러리와 연동하는 모습을 일부분이나마 보여줬기 때문입니다. 그렇기 때문에 Java 개발자 들이 Cocoa Binding에 대해서 난감해하고 있다는 사실이 조금 의아하네요.
또 한가지 의아한 사실은 Object C Reference를 보면 Object C의 콜 방식인 [obj message]는 실제로는 컴파일러에 의해서 objc_msgSend(obj, sel, arg1, ...) 라는 형태로 변환된다는 사실을 알 수 있는데 굳이 어셈블리 코드를 해킹해가면서까지 봐야 알 수 있는 것인가하는 생각이 듭니다. 그래서, 설마 그런 사실 가지고 뭔가 발견한 듯한 내용을 썼을 리는 없을 것이라 생각이 들고, 과연 어떤 내용일까 하는 점에는 흥미가 좀 생깁니다.
그리고, 제 생각에는 단순히 호출 문제보다는 nil object에 대한 호출, Object 클래스의 구현등이 과연 얼마나 유연하게 이식될 수 있을까 하는 생각이 들고, 과연 이러한 문제를 어떻게 해결할까 하는 점에 관심이 생기는 군요. 그도 그럴 것이 더할나위 없이 정적인 Java에 비해서 ObjC는 더할나위 없이 동적인 언어이기 때문에 구현 자체는 가능할지라도 언어가 가진 철학이 너무도 대조적이기 때문입니다 - 정적과 동적의 의미는 컴파일러가 객체나 객체의 메시지에 대해서 철저하게 검사하는 가에 촛점을 두었을 뿐 언어의 확장성과는 무관함을 밝혀둡니다.

한편, 제가 알기로는 Java의 이러한 언어적 특징 때문에 Apple에서 Java와 Cocoa Binding을 유지하는 것을 Tiger에 와서는 (포기하는 수준에서) 답보 상태로 두었고, Leopard에 와서는 급기야 포기한 것으로 압니다. 제 예상으로는 Leopard 부터는 아예 Cocoa Binding 자체가 없어져 버려 호환성 문제를 야기하지는 않을까 했습니다만, Tiger 수준으로 남겨둔 것 같습니다. 그리고, Java 대신 선택한 것이 Python과 Ruby로 알고 있습니다. 그러나, 사실 Python도 정적인 특성이 강한 나머지, Apple 개발진은 Python을 좋아함에도 불구하고 - 모 컬럼의 내용을 인용한 것으로 사실과는 다를 수 있습니다 - Python 보다는 Ruby 쪽이 더 유연하게 Cocoa와 Binding이 이루어 지는 것을 알 수 있죠.

사실 Ruby on Rails를 보면 이 프레임 웍에서 장점으로 내세우고 있는 기능 중 몇몇은 이미 Obj C + Cocoa에서는 너무도 당연하고 기본적인 내용이라는 것입니다. 다만, Obj C 이외의 언어에서도 Obj C와 같은 확장성을 얻을 수 있다는 것은 반가운 일이죠. 오늘 ZD.NET을 보니, BBC에서는 Perl on Rails Project를 시작한다고 하더군요. 굳이 Obj C가 아니어도 그와 같은 언어의 동적 확장성이 점점 다른 언어에서도 경험할 수 있다는 사실이 즐겁긴 합니다. 기왕 시작한 김에 조금 더 삼천포로 빠져본다면 .NET 언어들이 가장 실망스러운 점은 Java를 너무 의식하고 있다는 느낌이 든다는 것입니다. Java 개발자 진영과 .NET 개발자 진영의 대결 구도가 너무 강해서 그렇게 느껴지는 지는 모르겠습니다만, VM부터 프레임웍까지 1:1로 비교되는 모습은 그냥 Java 틱한 새로운 언어가 나왔다는 생각만 들지, 점점 뭔가를 알아갈 수록 기술적으로 끌리는 것은 크게 없다는 생각이 들더군요. .NET 3.5에서 LintQ가 추가되긴 했지만, 언어적인 표현법이 단순화 되었을 뿐 그다지 기술적으로 큰 혁신은 없다는 생각이 듭니다. 오히려 MS의 지금까지의 행태를 돌이켜 보면 퍼포먼스 나쁘고 이식성 나쁜 또 하나의 쓸데 없는 확장이 생겼나 싶은 의심까지들 정도입니다 - 뭐, 워낙 Apple에게서 받은 감명이 큰 나머지 지금까지의 MS에 대한 충성 이상으로 회의적인 감정에 빠져서 그럴 수도 있겠습니다만.

요즘 Java쪽으로 일거리를 옮겨볼까 하는 생각에 새롭게 공부하는 중이기도 하거니와, 지난 몇년동안 그렇게 해보려고 해도 못해왔던 open project의 빌드를 요 며칠 동안 Perian이나 Vlc등의 빌드도 성공해 보았고 - 그것도 Linux도 아닌 Mac OSX에서 -해서 사기가 높아진 것도 좀 있고, 평소 Project에 대한 것들에 대해서 능력이 없어서 그렇지 관심도 제법 있는 편이고 해서 미숙한 실력에도 불구하고 문득 드는 생각들을 몇가지 두서 없이 적어봤습니다. 괜한 소리로 결례나 되지 않았으면 싶습니다.

Lee,Chan-gu

링크를 쫓아가서 살펴보고선 다시 하나 적습니다만...

얼마전 선배와 얘기하던 것이 Java의 멍청한 점 중 하나가 OS의 GUI까지 통합하려한 시도였다는 것이었습니다. 그러다보니, AWT 같이 멋 대가리 없는 Toolkit이 나오게 되었고, Swing과 같이 퍼포먼스 극악의 Toolkit이 나오게되었다는 얘기를 한 적이 있었습니다만...

SWT의 첫 메인 페이지을 보고나니 예전에 선배와 했던 그 얘기가 생각나는군요.
그 때 선배와 했었던 대화의 답변이 아닌가 하는 생각이 드는군요.

여담으로... Osxdev.org의 아쉬운 점 한가지는 objC와 cocoa 말고는 이런 얘기를 나눌만한 마땅한 공간이 없다는 것이네요.

narusas

뭐 언어적 차이라기 보다는 SWT개발자가 obj c와 컴파일러에 대해 잘 몰랐던거가 아닌가 싶네요.
SWT 자체가 대부분의 코드가 자바 코드이고(않그러면 소수의 인력으로 그렇게 많을 플랫폼을 지원할수가 없다고 하죠) 결국 얼마 되지 않는 JNI Binding 부분을 carbon에서 cocoa로 , C에서 obj c로 바꾸는 일인거죠.
실제로 자바 코드는 거의 고치지 않았을 겁니다. JNI가 나름 잘 만들어져 있기 때문이죠.
그러니까 2주만에 이클립스를 돌리는 작업이 가능한거죠.

kizoo

Java 등은, 산업의 기술 관성 때문에 자칫 섣불러 위험할 수도 있고 거부감을 불러 일으킬 수 있는 기술을 때맞춰 상품으로 잘 포장해냈고, C/C++로부터 자연스럽게 옮겨올 수 징검다리를 만들어 주었다는 점에서는 큰 역할을 해냈습니다.

허나, 모두 잘 아시다시피, 기술 가치로만 보자면 VM 방식의 프로그래밍 환경은 아~주 케케묵은 (프로그래밍 언어란게 처음 생길 때부터 시작되었던) 정말 새로울 것이 하나 없으며, 순수하게 언어면에서만 보아도 Java 등의 언어는 새롭다기보다는 상업적으로나 정치적으로 안전한 선택이었다고 볼 수 있습니다.

한데, 지금에 이르러서는 갖가지 분야에서 힘을 키워가고 있는 다른 언어나 프로그래밍 방식에 견주어, 기술적인 면에서 도드라진 장점으로 내세울 만한 게 점차 사라지고 있습니다. 다시 말해, 몇 가지 영역을 제외하면, 이제 Java 같은 기술의 대안이 점점 많아지고 있기때문에, 여러 모로 예전처럼 굳이 Java 기술 (또는 Sun의 제품에) 목을 맬 까닭이 없는 거죠.

애플 처지에서보면:

- Mac OS X의 토박이 프로그래밍 기술이 Objective-C에 바탕을 두고 있기때문에, C/C++에 바탕을 둔 방식에서 오는 문제점으로 고민할 까닭이 적고
- Java 방식이 계산 자원의 관리 면에서 좀 더 엄격하기는 하지만, Objective-C를 내다 버려야 할 만큼 잇점이 많지도 않고
- 굳이 VM 방식을 써야 할 곳이 있다면, 벌써 응용 영역별로 더 좋은 대안들이 수두룩이 널려 있기때문에, 괜히 고생스런 일에 돈들이고 힘들일 까닭이 없다고 판단했을 겁니다.

제 경험에 비추자면, VM을 잘 다듬어 옮겨 심는 일은 물론이고, 그 위에서 돌아가는 GUI Framework을 옮겨 담는 일은, 처음 몇 단계만 지나면 거의 막노동에 가깝습니다.

애플의 선택, 두고 봐야 알겠습니다만, 잘한 일이라고 봅니다.

__________________
한국 Microsoft에서 일하는 Mac User
셈말과 셈틀

cmdrkeen

약간 다른 얘기입니다만,

Platform과 language라는 것은 프로젝트와 상황에 맞추어 쓰는 것이지 개발자 능력에 맞추어 쓰는 것이 아님은 다들 알고 계실 것입니다.

버전 1.1때부터 꽤 오래 Java를 사용해왔습니다만, 주위에서 보아온 바 로는 JNI를 이용한 경우 만족할 만한 결과를 얻은 적이 거의 없었고, SWT나 Cocoa binding같은 OS dependent한 UI를 사용하여 independence를 깰 바에는 차라리 프로젝트와 상황에 맞는 OS dependent한 platform과 language를 사용하는 것이 맞다고 생각합니다. JNI나 SWT등을 고집하는 개발자의 경우 많은 이유를 대지만, Java가 그 프로젝트에 맞는 platform과 language 이기 때문이라기 보다는 Java외의 다른 platform과 language에 대해 잘 모르거나 두려움을 가지고 있는 경우가 대부분이었습니다. GUI 툴을 만들긴 해야겠는데 Java 말고는 모르겠고, native 컴포넌트를 써야 하는데 Java 말고는 모르기 때문에 JNI를 고집해가면서까지 Java를 고집하는 경우입니다. (물론 깨달음을 얻은 개발자들이 꼭 필요해서 사용하는 경우도 있습니다.)

JNI가 없어서는 안될 경우라면 이미 만들어진 Java 컴포넌트와 native 컴포넌트 사이에서 adopter 역할을 하는 컴포넌트나 middle man을 구현할 경우라던가 정치/경제적 상황에 의해 반드시 Java만을 사용해야 하는데 그 프로젝트가 필요로 하는 컴포넌트가 native인 경우 정도입니다. 이러한 경우를 제외하고 그 자체만으로 충분히 주어진 역할을 수행할 수 있는 어플리케이션을 만들어야 한다면 native platform과 language가 맞는 답이 될 것 같습니다.

Cocoa Binding의 개발이 부러진 이유도 Apple에서 제공하는 JRE에서 이미 애플의 Cocoa나 Carbon같은 L&F를 제공하고 있음에도 Cocoa Binding이 중복되는 역할을 하기 때문이 아닐까 싶습니다. Cocoa Binding이 Java Swing에 비해 얻을 수 있는 잇점이라고는 미약한 속도 향상과 NIB 파일의 재활용 정도인데, (Binding 자체가 가진 장점은 제외합니다.) Apple에서 이를 위해서 개발 리소스를 투자하는 것에 의미를 못 찾은것이 아닐까 생각합니다. 참고로 이제는 컴퓨팅 파워가 너무 좋아져서 Swing으로 개발된 복잡한 GUI도 그다지 답답하다는 생각은 안 들더군요.

Java를 가장 잘 활용한 예는 Apache Tomcat이나 Caucho Resin등의 서버 류의 프로그램이라고 생각합니다. VM을 써야 하는 이유가 명확하고 그로 인해 얻는 잇점도 명확하기 때문이지요.

__________________

"In the information age, the barriers just aren't there. The barriers are self imposed. If you want to set off and go develop some grand new thing, you don't need millions of dollars of capitalization. You need enough pizza and Diet Coke to stick in your refrigerator, a cheap PC to work on, and the dedication to go through with it. We slept on floors. We waded across rivers."

nobocop

많은 부분들이 곡해 되는 듯한다는 인상에 우매한 저지만 몇자 더 적어 보려고 합니다.

우선 VM 을 사용한다는 부분은 케케묵은 기술이지만 그것이 가져오는 어마어마한 장점이 무시되어서는 안됩니다. java 진영은 모든것을 java 로 옮겨오라고 주장하지도 그럴 생각도 없습니다. 그저 단 한자의 수정도 없는 소스코드로 수만은 paltform 에서 돌아가는 그 우아함을 사랑 할 뿐이죠. objective-c 든.. c 든 POSIX를 지키던 아니 지키던... os 별로 같은 os 라 할지라도 32 bit 64bit 에 다라 따로 컴파일해야 하고 ...
multi platform 을 지원 해보신분은 그 고통을 아실 듯 합니다. autoconf/automake 의 뒤에 숨겨진 수만명의 눈물을 ㅡ.ㅡ;;

SWT또한 마찬가지입니다. JNI 의 남발은 분명 java 의 장점을 갉아 먹습니다만 SWT는 이야기가 다릅니다.
SWT를 사용하는 어플리케이션은 JNI를 사용하지 않습니다. SWT라이브러리가 JNI를 사용합니다. SWT를 모든 플랫폼에 포팅하고 SWT를 사용하는 코드는 100% platform independent 가 유지 됩니다. 이는 awt/swing 을 이용한 코드가 플랫폼 중립적인 것과 다르지 않습니다. awt/swing 도 결국 motif/gtk/win32 등을 native call 하게 되죠. awt 의 역할을 swt 가 대체할 뿐입니다. 100배 더 우아한 방법으로...

java 가 client 보다 server 단에서 자리를 확고이한 점은 충분히 바른 지적입니다. 하지만 ui 를 가지는 영역도 swt/rcp 의 도움으로 많이 변할 것이라고 생각 합니다. IDE만 놓고 본다면 Emacs 에서 Eclipse 로 개종한지 한참 됩니다.. ;;;


java 는 또 단순히 Servlet container 구현물을 넘어서게 되는 데요... 여기서 종교전쟁을 하려는 것은 아닙니다. Spring Framework , Hibernate , JTS .... 수많은 자바의 친구들이 자바의 경쟁력이되어주고 있습니다.

다시 논거로 돌아가면 Cocoa 의 매혹을 제대로 살린 Eclipse 가 다가옴을 경배 합시다!!! 만세!!

kizoo

어서 빨리 달콤한 코코아로 이뻐진 SWT/Eclipse가 나와서 nobocop 님의 즐거움이 한 층 더해지길 바랍니다. 저도 만세!!
(남이야 뭐라건 자기가 좋으면 되는 겁니다. 싫증이 나면 또 딴 걸로 바꾸면 그 뿐이구, 어차피 모두 사람이 가지고 놀려고 만든 장난감인데요, 뭐.)

__________________
한국 Microsoft에서 일하는 Mac User
셈말과 셈틀

cmdrkeen

크 이 글타래 재밌네요.
거의 이런 개발 관련 글은 안 올라오는지라...

하여간 저도 Java 정말 좋아합니다.
사회생활 하면서 처음 썼던 language라 애착도 많고요
만세!!!

__________________

"In the information age, the barriers just aren't there. The barriers are self imposed. If you want to set off and go develop some grand new thing, you don't need millions of dollars of capitalization. You need enough pizza and Diet Coke to stick in your refrigerator, a cheap PC to work on, and the dedication to go through with it. We slept on floors. We waded across rivers."

pragmatic

정말 최근에 듣던 소식중에 가장 신나는 소식입니다. 3.4부터는 Cocoa 버전을 만날 수 있을까 하는 욕심이지만 힘들겠지요 ^^;

Firefox 3도 코코아 지원한다고 하고 이제 카본은 팽당하는 분위기인데요. 이제 Cocoa Suite의 시대가 도래하고 있군요 -ㅁ-

__________________
http://www.pragmatic.kr

flama

안녕하세요? 이지환입니다.

지금 EclipseCon 2009의 "The Treacherous Path from Carbon to Cocoa for SW" 세션에 들어와 있습니다.
아직 시작 전이고... 화면 앞에 Steve Northover씨가 왔다갔다하면서 준비하고 있군요.

최근에 올라온 3.5 마일스톤 5를 (그냥 돌려보고 프로젝트나 소스 몇개 편집해 보면) 거의 출시버전이라고 볼 수 있는 정도의 상당한 완성도를 보여주던데요...
기대됩니다.

__________________
非常喜歡冬天,不喜歡夏天

theifcat

앞으로 저희 회사에서 이클립스 RCP 로 프로그램을 만들려고 하는데
똥꼬집 부려가며 제 맥북프로로 개발해왔었는데.. cocoa 로 SWT가 된다는 소식이 정말 기쁘네요
carborn을 쓰면 UI는 갖더라도 약간 느린감이 있어왔는데 cocoa를 지원하는 기능추가도 기대되지만
어느정도 퍼포먼스 향상이 있을거라 생각하니 기분좋네요 *^^*
앞으로 이 글타래가 쭉 유지되어 활발해 졌으면 좋겠네요

+ps : 그런데 설마 애플의 java 처럼 코어2 이상만 지원하는 걸로 나오지는 않겠죠.. 초기형 맥북프로로 절망한 첫번째 캐이스가 그거였는데 ㅠㅠ