=================================
=================================
=================================
http://kin.naver.com/qna/detail.nhn?d1id=1&dirId=1040201&docId=121533555&qb=7J6Q67CUIHN3aW5nIHN3dA==&enc=utf8§ion=kin&rank=1&search_sort=0&spq=0&pid=gCghN35Y7twsss%2BEUHossc--040964&sid=TkTYc3LuQ04AAA@mK1E
질문:
최근에 자바를 공부하고 있습니다.
툴은 이클립스를 선택하였는데
질문은
1. 데스크탑 프로그램에서 현업분들은 SWING SWT중에 어떤 걸 쓰시나요? 입니다.
2. SWT 를 검색해보니 OS에 따라 별도로 컴파일해서 배포해야 된다 라고 이해했는데..
맞나요? 이게 맞으면 굳이 자바로 할필요가 있을까? 라는 의문이....
( 리눅스에 배포할때는 이클립스를 리눅스 버젼으로 깔아서 배포한다...윈도는 따로 윈도버젼에서
이클립스로 배포한다...머이런식..)
답변:
SWT의 경우, 플랫폼별로 배포용 팩키지(jar)가 나뉘어져 있습니다.
예를 들어, 윈도우용 SWT, Solaris용 SWT, Linux용 SWT 등등...
자바실행환경이 깔려 있다는 전제로, 배포할 때는,
SWT의 경우는 동작환경의 플랫폼용의 SWT와, SWT를 사용해서 만든 어플리케이션을 배포하면 됩니다.
SWT를 호출하는 자바 어플리케이션은 플랫폼에 의존하지 않으니까 리컴파일을 할 필요는 없습니다.
Swing의 경우는 어플리케이션만 배포하면 되지요.
Swing와 SWT 어느쪽을 사용하는 가는,
OS특유의 유저인터페이스나 디자인을 추구한다면 SWT,
환경별로 다르지 않은 통일된 디자인을 추구한다면 Swing,
완전한 멀티플랫폼을 필요로 한다면 Swing(SWT는 지원하지 않는 플랫폼이 존재)
등이 가장 큰 구분요인이 되리라 생각합니다.
그 외에도
표준 GUI툴킷으로서 Swing의 정보량이 풍부해서 프로그램 개발이 용이하다는점,
SWT를 사용함으로서 동일 플랫폼의 유저인터페이스에 위화감을 줄일 수 있다는 점,
SWT는 고속, 경량으로 성능면에서 우위를 보이는 점(업계에서도 반론은 있지만)
SWT는 순수자바만으로는 가동할 수 없는 점,
Swing의 모든 기능을 SWT로 대체할 수 없는 점,
Swing에는 존재하지 않는 기능이 SWT에는 존재하는 점,
Swing+JFC의 조합으로 Swing의 응용범위가 넓어진 점,
등등을 감안하면서
만들려고 하는 어플리케이션의 환경, 특성에 맞게 선택하면 되리라 생각합니다.
참고로,
제가 참여하고 있는 프로젝트는 Swing만을 사용합니다만, 이유는,
플랫폼에 제한이 있으면 그만큼 영업폭이 줄어 들고,
배포할 때 설치하는 것이 많아지면 고객이 싫어하는 경우가 많고,
SWT는 플랫폼의 라이브러리가 가지고 있는 버그가 그대로 반영되기 때문에 유지보수가 힘들고,
플랫폼 별로, 제품서포트를 하면 경비가 그만큼 소요되는 점 등이 있기 때문이지요.
=================================
=================================
=================================
출처: http://blog.naver.com/genesung/130052465783
Eclipse의 기능을 살펴보면서 이들은 왜 AWT/Swing을 쓰지 않고 SWT/JFace를 사용했는지 궁금했는데 이를 잘 설명해주는 문서가 있더군요.
1. AWT/Swing과 SWT/JFace 기능 비교
SWT, Swing or AWT: Which is right for you?
영문: http://www.ibm.com/developerworks/grid/library/os-swingswt/
한글: http://www.ibm.com/developerworks/kr/library/os-swingswt/index.html
1.1 AWT
- Abstract Windows Toolkit (AWT)는 오리지널 자바의 GUI툴킷
- 자바의 런타임의 일부로 안정되고, 추가 설치가 필요 없음
- 대개의 경우 리소스관리를 프레임워크에서 처리
- UI 쓰레드를 신경쓰지 않아도 됨 (그러나 성능의 문제가 됨)
- 콘테이너 없이 콤포넌트 생성 및 콘테이너 변경 가능
- 풍부한 그래픽 환경 제공
- 각 OS별 최소한의 공통 기능의 wrapper를 구현함으로써 제한적 기능을 제공
- 일반적으로 사용되는 테이블, 트리, 진행 바 같은 것은 애플리케이션 레이어에서 구현해야 함
- "한번 작성하여, 어디에서나 실행되는(WORE)"라기보다 "한번 작성하여, 어디에서나 테스트 하는(WOTE)" 환경이 됨
1.2. Swing
- 각 OS의 콤포넌트에 대한 의존성을 최소화 (AWT의 단점을 보완)
- 대부분의 콤포넌트는 자바로 구현해 모든 OS에 같은 look & feel로 실행 가능함 (WORE)
- 자바로 구현한 콤포넌트는 각 OS의 원래 콤포넌트보다 느려질 수 있음
- 모델, 뷰, 컨트롤의 분리
- Look & Feel을 컨트롤 할 수 있음
- AWT와 마찬가지로 프레임워크에서 리소스가 관리되며 컨테이너의 전제조건이 없음
- UI 쓰레드가 있으므로, UI 변경은 이 쓰레드에서 이뤄져야 함
- 자바의 일부로 별도의 설치가 필요 없음
1.3 SWT/JFace
- Standard Widget Toolkit (SWT)는 AWT에 비교되는 콤포넌트 라이브러리
- JFace는 SWT를 기반으로 하는 상위레이어 UI 라이브러리
- SWT는 각 OS의 콤포넌트에 기반하고, 좀더 많은 콤포넌트를 수용함 (OS에서 콤포넌트가 지원되지 않는 경우 자바로 구현함)
- OS에 따른 콤포넌트의 기능, look & feel과 성능을 지원함 (WOTE)
- ContentProvider 등을 통한 MVC 지원
- 애플리케이션이 리소스 관리해야 함 (disposal)
- 콤포넌트는 부모 컨테이너를 지정해 생성해야 하고 변경할 수 없음
- UI는 UI 쓰레드에서 변경되어야 함
- 그래픽 기능이 자바에 비해 약함
- 자바이외에 별도의 라이브러리 설치 및 환경설정 (classpath 및 jni library path)이 필요
2. AWT/Swing과 SWT/JFace 성능 비교
SWT Vs. Swing Performance Comparison
http://cosylib.cosylab.com/pub/CSS/DOC-SWT_Vs._Swing_Performance_Comparison.pdf
| Test | Java 1.5, Linux |
Java 1.4, Linux |
Java 1.4, Windows |
Java 1.4, Windows, II |
VMware |
| Drawing primitive tests (times in microseconds) | |||||
| SWT Rect | 9.9±0.02 | 11.0±0.07 | 11.3±0.07 | 9.0±0.18 | 89.4±1.27 |
| Swing Rect | 8.4±0.1 | 8.4±0.4 | 11.9±0.4 | 8.9±0.6 | 67.8±0.4 |
| SWT Rect Fill | 57.8±0.5 | 60.6±0.8 | 35.3±14.5 | 103.0±3.6 | 71.5±14.2 |
| Swing Rect Fill | 49.6±0.1 | 55.2±5.3 | 43.4±0.8 | 103.0±10.0 | 36.2±8.8 |
| SWT Poly | 13.8±0.03 | 15.1±0.03 | 251.0±66.97 | 20.0±0.1 | 133.8±54 |
| Swing Poly | 13.4±0.03 | 13.5±0.03 | 6.6±0.34 | 19.9±0.1 | 141.1±37 |
| SWT Poly Fill | 102.6±1.0 | 104.8±0.3 | 98.3±0.2 | 82.5±3.3 | 1071.2±350 |
| Swing Poly Fill | 95.7±0.2 | 94.6±1.1 | 45.8±3.1 | 82.1±7.9 | 887.0±445 |
| SWT Circle | 53.2±0.1 | 54.7±0.7 | 160.7±0.1 | 49.0±3.6 | 148.5±1.8 |
| Swing Circle | 51.3±0.3 | 51.6±0.4 | 56.1±4.8 | 45.8±5.0 | 130.6±0.5 |
| SWT Circle Fill | 58.7±0.1 | 61.4±0.1 | 158.0±0.3 | 101.0±2.3 | 953.1±6.6 |
| Swing Circle Fill | 49.9±0.4 | 50.6±0.3 | 128.4±0.3 | 100.0±0.8 | 931.7±7.6 |
| SWT Line | 5.9±0.03 | 6.5±0.02 | 34.9±0.13 | 5.5±0.3 | 657.9±320 |
| Swing Line | 5.1±0.05 | 5.7±0.01 | 10.2±0.03 | 6.8±0.03 | 808.7±7.3 |
| Widget tests (times in milliseconds) | |||||
| SWT Table (20,40) | 578±5.6 | 584±60.9 | 98±0.4 | 30±1.0 | 576±4.9 |
| Swing Table (20,40) | 30±8 | 141±43 | 9.4±0.9 | 6±1.0 | 29±4.2 |
| Swing Table - synch (20,40) | 127.1±2.0 | 100.8±0.6 | 101.3±0.5 | 56.0±3.0 | 88.9±8.0 |
| SWT Table Scroll (20,100) | 12.2±0.2 | 12.1±0.05 | 10.0±0.04 | 2.0±0.0 | 15.5±0.6 |
| Swing Table Scroll (20,100) | 4.3±0.1 | 33.1±0.1 | 31.6±2.4 | 75.0±6.0 | 9.2±0.3 |
| SWT Text Fields (20,20) | 276±0.6 | 319±44.7 | 68±0.1 | 33±3.0 | 341±1.8 |
| Swing Text Fields (20,20) | 84.2±4.7 | 78.0±53.0 | 37.8±1.6 | 35.0±21.0 | 131.0±18.0 |
| Swing Text Fields - synch(20,20) | 133±0.5 | 166±3.6 | 120±0.6 | 66±1.0 | 302±6.7 |
Swing이 각 OS에서 제공하는 콤포넌트의 기능을 사용하지 않음으로 해서 성능이 저하된다는 단점을 극복하고자 출발한 SWT이기 때문에 SWT가 성능이 좋을 것이라는 예상이 있었지만, 실험결과는 의외로 Swing이 좀 빠른 것으로 나타났습니다. 여기에는 여러가지 논란이 있지만 SWT가 JNI에 의존하는 함수가 많아서 그렇지 않은가 하는 의견이 많은 것 같습니다. 즉, JNI 함수의 call/return의 오버헤드가 OS 컴포넌트의 성능 우의를 까먹었다는 분석입니다.
(참고) JNI 성능 분석: http://janet-project.sourceforge.net/papers/jnibench.pdf
이 테스트는 java 1.3을 대상으로 한 것이긴 하지만, JNI의 성능에 대한 중요한 근거를 제공하고 있다고 봅니다. 물론 java 1.5에서는 이보다 성능이 좋아졌다고들 하는데 이 같은 벤치마크 자료는 찾기 쉽지 않네요.
<< Java vs Native Method Invocations - times in [ns] >>
| Test | Solaris | Linux | Windows | |||||
| scli | ssrv | lsrv | lcli | lcls | libm | wcli | wibm | |
| Java, non-virtual, no args | 40 | 0 | 20 | 0 | 260 | 25 | 0 | 36 |
| Java, non-virtual, 8 args | 70 | 0 | 35 | 0 | 390 | 50 | 0 | 50 |
| Java, virtual, no args | 90 | 90 | 22 | 275 | 340 | 30 | 26 | 38 |
| Java, virtual, 8 args | 90 | 220 | 50 | 285 | 420 | 55 | 45 | 56 |
| native, non-virtual, no args | 110 | 150 | 105 | 120 | 500 | 130 | 140 | 120 |
| native, non-virtual, 8 args | 340 | 290 | 210 | 310 | 940 | 225 | 710 | 250 |
| native, virtual, no args | 120 | 170 | 110 | 100 | 460 | 130 | 160 | 125 |
| native, virtual, 8 args | 400 | 310 | 205 | 300 | 970 | 240 | 720 | 255 |
3. 결론
결론을 내리기에는 뭔가 더 고려해야 할 사항들이 더 있지 않나 생각됩니다. 개발의 편리성이라던지, 친숙함이라던지, 유지보수의 편의성, 또는 툴들의 지속성, 업그레이드, 지원의 편리성 또는 개발 커뮤너티의 활성도 등 여러가지 두루 검토하는 것이 좋을 것 같습니다.
개인적으로는 기본적인 면에서 많은 부분에서 AWT/Swing이 유리하지 않나 생각됩니다만 (성능에 대해서는 SWT/JFace에 기반한 Eclipse가 느려서 불편할 정도는 아닌 것 같습니다), Eclipse라는 환경을 생각한다면 SWT가 유리한 부분도 있지 않나 생각됩니다. Eclipse를 접하기 전에는 Eclipse를 IDE (integrated development environment)로 단순히 생각했었지만, 자료를 좀 보니 IBM이 큰 그림을 바탕으로 개발한 framework이더군요. Eclipse를 RCP (rich client platform)로 생각한다면 SWT도 상당한 장점이 있는 것 같습니다.
Eclipse를 RCP로 사용한 제품:
=================================
=================================
=================================
출처:
http://blog.naver.com/2skfro/80033938360
1. SWING
- 운영체제와 무관하게 일관도니 외양릉 띠고 동작
- 사용자 인터페이스를 그리는 과정에 전적으로 개입
- JVM 은 컴포넌트의 각 픽셀을 명시하고 컴포넌트의 행위를 제어함
- JVM 이 기반 플랫폼과 상호 소통 하더라도, 은영체제에 있는 객체는 활용하지 않고 새로작성
- LightWeight Component
- 모든 것에 직접 관여를 하기 때문에 느리게 작동
- Automatic garbage collection 기반(개발자가 설계에 집중할 수 있으나, 이상동작예상)
- 설계 구조 :
- MVC 기반하여, MODEL, 그리고 MODEL-Delegate(뷰,컨트롤러) 아키텍쳐
- 좀더 유연하고 재사용 가능한 코드를 산출함
- gui는 복잡,부가적인 할당/철리로 프로세스에 부하가 걸림
2. SWT/JFace
- 운영체제이 직접 접근 가능
- heavyweight components
- 운영체제와의 소통은 JNI(Java Native Interface) 사용
- 가비지 컬렉션에 의존하지 않음
- 설계 개발의 간소화 ( 컴포넌트 설계 아키텍쳐에 대해 특별한 규정을 만들지 않음)
- EPL(Eclipse Public License)하에 오픈 소스 라이브러리
- 지원 platform : 윈도우 웬만한것, 리눅스 웬만한 것 ( 단 kde 안됨, motif,gtk 2.0)
[출처] 스윙 & SWT/JFACE|작성자 2skfro
Learn the way of thinking : Algorithm & Coding : 네이버 블로그
#Algorithm #Coding #Critical Thinking #정보올림피아드 #Machine Learning #Computer Science
blog.naver.com
=================================
=================================
=================================
출처: http://www.ibm.com/developerworks/kr/library/os-swingswt/
SWT, Swing or AWT: 나에게 맞는 것 찾기 (한글)
여러 developerWorks 필자들은 Swing과 SWT간 마이그레이션 방법을 설명해왔다.(참고자료) 이 글에서는 프로젝트를 시작하기 전에 알맞은 GUI 툴킷을 고르는 법을 설명하고자 한다.
Java™ GUI 툴킷이 왜 그렇게 많은 것일까? 모든 것에 다 맞는 한가지가 존재하지 않을 뿐더러, 모든 것에 맞는 하나의 GUI 툴킷은 당분간은 개발될 것 같지도 않다. 각 툴킷은 장단점이 있기 때문에 자신의 필요에 따라 적절한 것을 선택해야 한다.
이제 각 툴킷에 대해 배워보자.
Abstract Windows Toolkit(AWT)은 오리지널 자바 GUI 툴킷이다. AWT의 대표적인 장점은 오래된 웹 브라우저에 있는 자바 구현을 비롯하여 모든 자바 버전에서 제공하는 표준이다. 따라서 매우 안정적이다. 설치할 필요도 없고 자바 런타임 환경이 있는 곳 어디에서나 사용할 수 있고 기대하는 기능도 갖추고 있다.
AWT는 제한된 GUI 컴포넌트, 레이아웃 매니저, 이벤트(Listing 1, Listing 2, Listing 3) 를 가진 매우 단순한 툴킷이다. Sun Microsystems가 AWT에 대해 “최소 공통 분모(lowest-common denominator-LCD)” 접근 방식을 사용했기 때문이다. 자바 호스트 환경을 위해 정의된 GUI 컴포넌트만이 사용될 수 있다. 따라서 테이블, 트리, 진행 바 같은 일반적으로 사용되는 컴포넌트가 지원되지 않는다. 더 많은 컴포넌트 유형을 필요로 하는 애플리케이션의 경우 처음부터 구현해야 한다. 이것이 큰 문제이다.
Listing 1. 기본적인 AWT 클래스 트리 (모두 java.awt 패키지에 있다. "*"는 앱스트랙트이다.)
| Object CheckboxGroup *Component Button Canvas CheckBox Choice Container Panel Applet ScrollPane Window Dialog Frame Label List TextComponent TextArea TextField MenuComponent MenuItem CheckboxMenuItem Menu PopupMenu |
주: 다른 패키지에는 이 외에 다른 AWT 컴포넌트들이 있지만 이것이 기본적인 세트라고 할 수 있다.
Listing 2. AWT의 레이아웃 매니저(모두 java.awt 패키지에 있다. "*"는 인터페이스를 나타낸다.)
| *LayoutManager FlowLayout GridLayout *LayoutManager2 BorderLayout CardLayout GridBagLayout |
주: 이 외에 다른 AWT 레이아웃 매니저가 있고 컨테이너에 따라 다양하지만 이것이 기본적인 세트이다.
Listing 3. AWT의 이벤트 (대부분이 java.awt.events 패키지에 있다.)
| Object EventObject AWTEvent ActionEvent AdjustmentEvent ComponentEvent ContainerEvent FocusEvent InputEvent KeyEvent MouseEvent MouseWheelEvent PaintEvent WindowEvent HierarchyEvent InputMethodEvent InvocationEvent ItemEvent TextEvent |
주: 다른 AWT 이벤트들도 있지만 이것이 기본적인 세트라고 할 수 있다. 이것은 보다 일반적인 이벤트에서 생성된 특정 이벤트이다.
일반적으로 AWT(그리고 Swing과 SWT)의 경우, 각각의 이벤트 유형은 관련 XxxListener 인터페이스를 갖고 있고 때로는 XxxAdapter null 구현도 있다. 여기에서 Xxx는 Event 접미사가 없는 이벤트이다. (예를 들어, KeyEvent는 KeyListener이다.) 이는 이벤트를 핸들러로 보내는데 사용된다. 이벤트용 이벤트 소스(GUI 컴포넌트나 위젯)을 가진 애플리케이션 레지스터는 프로세싱과 관련되어 있다. 몇몇 리스너들은 다중 이벤트를 핸들한다.
AWT의 장점 중 하나는 GUI 컴포넌트의 자동 정리를 지원한다는 점이다. 여러분이 직접 컴포넌트를 정리할 필요가 없다. Dialogs와 Frames 같은 고급 컴포넌트는 예외이다. 상당한 호스트 리소스를 소비하는 리소스를 만든다면 이들을 직접 정리할 수 있다.
AWT 컴포넌트는 "쓰레드 보안"이 되어있다. 따라서 애플리케이션에서 어떤 쓰레드가 GUI를 업데이트 하는지 신경 쓰지 않아도 된다. 이로서 GUI 업데이트 문제가 없어진다. 하지만 AWT GUI는 느리게 실행된다.
AWT에서는 GUI를 탑다운(top-down) 또는 바톰업(bottom-up)구현하거나, 이 방식들을 조합하여 구현할 수 있다. 탑다운 방식은 자식 이전에 컨테이너 컴포넌트를 먼저 만든다. 바톰업 방식에서는 컨테이너(부모) 컴포넌트를 만들기 전에 자식을 만든다. 따라서 컴포넌트는 부모 컨테이너 없이 존재할 수 있고 부모는 시간이 지나면서 변한다.
일반적으로, AWT GUI는 접근이 불가능 하다. AWT 프로그래머가 접근성 정보를 지정할 수 있는 API가 없다. 접근성은 장애를 가진 사람들이 애플리케이션을 얼마나 잘 사용할 수 있는지에 대한 문제이다. 장애인들도 적절한 보완 기술(사용자 인터페이스 대안을 제공하는 툴)로 애플리케이션을 사용할 수 있도록 해야 한다. 많은 정보와 기업들은 애플리케이션의 접근성에 대한 표준을 갖고 있다.
Sun은 자바 언어가 "한번 작성하여, 어디에서나 실행되는(WORE) " 환경이 되어야 한다고 생각했다. 다시 말해서, 자바 코드는 하나의 호스트(예를 들어, Windows®)에서 개발 및 테스트 되어, 다른 자바 호스트 상에서도 테스트 없이 실행될 수 있도록 하는 것이다. 대부분 자바 기술은 이를 계승했으나 AWT는 달랐다. AWT는 호스트 GUI "피어 " 제어에 의존하여 GUI를 구현했기 때문에 GUI는 다른 호스트 상에서는 다르게 작동한다. 따라서 "한번 작성하여, 어디에서나 테스트 하는(WOTE)” " 상황이라는 약간 만족스럽지 못한 상황이 되었다. Sun은 자바 언어가 "한번 작성하여, 어디에서나 실행되는(WORE) " 환경이 되어야 한다고 생각했다. 다시 말해서, 자바 코드는 하나의 호스트(예를 들어, Windows®)에서 개발 및 테스트 되어, 다른 자바 호스트 상에서도 테스트 없이 실행될 수 있도록 하는 것이다. 대부분 자바 기술은 이를 계승했으나 AWT는 달랐다. AWT는 호스트 GUI "피어 " 제어에 의존하여 GUI를 구현했기 때문에 GUI는 다른 호스트 상에서는 다르게 작동한다. 따라서 "한번 작성하여, 어디에서나 테스트 하는(WOTE)” " 상황이라는 약간 만족스럽지 못한 상황이 되었다.
AWT는 Java V1.2 부터 풍부한 그래픽 환경을 제공한다. Through the Graphics2D 객체부터 Java2D와 Java3D 서비스, 그리기, 차트 만들기 같은 그래픽 애플리케이션 JavaSound와의 결합, 인터랙티브 게임 등을 구현할 수 있다.
Java Foundation Classes(JFC)로도 알려진 자바 Swing은 AWT의 단점을 해결하기 위한 시도로 만들어졌다. Sun은 Swing이라는 매우 유연하고 강력한 GUI 툴킷을 만들었다. 불행히도 Swing은 배우는데 시간이 오래 걸리고 너무 복잡하다.
Swing은 AWT를 기반으로 구현된다. 모든 Swing의 부분들은 AWT의 일부이기도 하다. Swing은 AWT 이벤트 모델을 사용하고 Colors, Images, Graphics 같은 클래스를 지원한다. Swing 컴포넌트, 레이아웃 매니저, 이벤트들을 아래 정리해 보았다. (Listing 4, Listing 5, Listing 6)보면 알겠지만 AWT 보다 진보했다.
Listing 4. 기본적인 Swing 클래스 트리 (모두 javax.swing 패키지 또는 하위패키지에 있다. "*"는 추상 클래스이다.)
| Object *Component Container *JComponent *AbstractButton JButton JMenuItem JCheckBonMenuItem JMenu JRadioButonMenuItem *JToggleButton JCheckBox JRadioButton Box Filler JColorChooser JComboBox JDesktopIcon JFileChooser JInternalFrame JLabel JLayeredPane JDesktopPane JList JMenuBar JOptionPane JPanel JPopupMenu JProgressBar JRootPane JScrollBar JScrollPane JSeparator JSlider JSplitPane JTabbedPane JTable JTableHeader *JTextComponent JEditorPane FrameEditorPane JTextPane JTextArea JtextField JPasswordField JToolBar JToolTip JTree JViewport ScrollableTabViewport Panel Applet JApplet Window Dialog JDialog Frame JFrame JWindow |
주: 이 외에도 다른 Swing 컴포넌트들이 있지만 이것이 기본적인 세트이다.
Listing 5. Swing의 LayoutManagers (모두 javax.swing 패키지 또는 하위패키지에 있다. "*"는 인터페이스이다.)
| *LayoutManager CenterLayout *LayoutManager2 BoxLayout OverlayLayout SpringLayout |
주: 이 외에도 다른 Swing 레이아웃 매니저가 있지만 이것이 기본 세트이다.
Listing 6. Swing의 추가 이벤트들 (대부분이 javax.swing.events 패키지 또는 하위 패키지에 있다.
| Object EventObject AWTEvent AncestorEvent ComponentEvent InputEvent KeyEvent MenuKeyEvent MouseEvent MenuDragMouseEvent InternalFrameEvent |
주: 기타 AWT 이벤트도 있지만 이것이 기본 세트이다. 이것은 보다 일반적인 이벤트에서 만들어진 "고급" 이벤트이다.
다른 호스트들간 작동상의 차이를 극복하기 위해 Swing은 호스트 제어에 대한 의존성을 최소화 했다. 사실, Swing은 창과 프레임 같은 상위 레벨 컴포넌트만을 위한 피어를 사용한다. 대부분의 컴포넌트들(Jcomponent와 이것의 하위 클래스)은 순수 자바 코드에서 에뮬레이트 된다. Swing은 기본적으로 호스트 들간 이식성이 있다. 따라서 Swing은 원시 애플리케이션 같이 보이지 않는다. 사실 여러 가지 모습이 있다.
Swing은 피어 기반의 컴포넌트에 중량(heavyweight)이라는 용어를 사용하고, 에뮬레이트 된 컴포넌트에 경량(lightweight) 이라는 표현을 쓴다. 사실, Swing은 하나의 GUI에 혼합된 중량 컴포넌트와 경량 컴포넌트를 지원한다. 같은 Jcontainer에 AWT와 Swing 제어를 혼합하지만 컴포넌트가 각자를 오버레이 한다면 그리는 순서를 주의해야 한다.
Swing은 하드웨어 GUI 가속장치와 특별한 호스트 GUI 연산을 활용하지 못할 수도 있다. 따라서 Swing 애플리케이션은 원시 GUI 보다 느리다. Sun은 최신 버전 Swing(Java V1.4과 1.5)의 퍼포먼스에 주력하였고, 이러한 단점도 많이 호전되었다. Swing의 디자인은 튼튼하지 않기 때문에 코드 베이스가 더 크다. AWT나 SWT 보다 육중한 느낌이다.
컴포넌트, 레이아웃 매니저, 이벤트 외에도 Swing은 AWT와 구별되는 보다 강력한 기능을 갖추고 있다. :
- 모델에서 뷰와 컨트롤러를 분리함
- 모델(버튼, 리스트, 테이블, 트리, 리치 텍스트)를 가진 모든 컴포넌트의 경우, 모델은 컴포넌트에서 분리된다. 이로서 모델은 애플리케이션의 필요에 맞출 수 있고 다중 뷰들과 공유된다. 컴포넌트 유형 마다 디폴트 모델이 제공된다.
- 프로그래밍이 가능한 룩앤필
- 각 컴포넌트의 룩앤필은 개별적이고 동적으로 대체 가능한 구현에 의해 제어된다. 따라서 Swing 기반의 모든 GUI의 룩앤필은 변경이 가능하다.
- 렌더러와 에디터
- 리스트, 테이블, 트리 같은 모델 콘텐트를 보여주는 대부분의 컴포넌트들은 거의 모든 유형의 모델 엘리먼트를 처리할 수 있다. 각 컴포넌트 유형과 모델 유형에 대한 렌더러나 에디터를 매핑함으로서 수행된다. 예를 들어,
java.util.Date값을 포함하고 있는 칼럼을 가진 테이블은 데이터 값을 나타내고 데이터 값을 편집할 특별한 코드를 갖는다. 각 칼럼은 다른 유형들을 갖는다.
- 접근성
- 장애인도 접근할 수 있는 GUI를 만드는 것이 중요하다. Swing은 확장성 있는 인프라와 API를 제공한다. 이 지원은 호스트 접근성과는 독립된 것이다.
AWT와 마찬가지로, Swing은 GUI 컴포넌트의 자동 정리를 지원한다. Swing은 AWT 바톰업과 탑다운 구현 방식을 지원한다.
AWT와는 달리 Swing 컴포넌트는 쓰레드 보안이 되지 않는다. 어떤 쓰레드가 GUI를 업데이트 하는지를 신경 써야 한다. 쓰레드 사용을 잘못 할 경우 사용자 인터페이스 고장 같은 예기치 못한 작동이 발생한다.
AWT와 마찬가지로 Swing의 대표적인 장점들 중 하나는 자바의 표준이라는 점이다. 설치할 필요가 없다. 하지만 Swing은 약간 더 진보하여 최신 자바 버전의 기능들에 의존하고 있다. 사용자들은 자바 런타임을 업그레이드 해야 한다.
SWT는 저수준 GUI 툴킷으로서 AWT의 개념과 비교된다. JFace라는 향상된 컴포넌트와 유틸리티 서비스 세트로 SWT 구현이 더욱 쉬워졌다. SWT의 구현자들은 AWT와 Swing 구현에서 영감을 얻어 이 두 개의 단점을 배제한 장점만을 가진 시스템을 구현하려고 했었다. 어쨌든 성공했다.
SWT는 피어 구현에 기반한다는 점에서 AWT와 비슷하다. AWT의 LCD 문제를 극복했다. 대부분의 오피스 애플리케이션이나 개발자 툴을 만들기에 적합한 제어 세트를 정의하고 호스트 기반으로 특정 호스트에서 제공되지 않는 것에는 에뮬레이트 된 제어를 구현한 것이다. 대부분의 현대적인 호스트의 경우 거의 모든 제어가 원시 피어에 기반하고 있다. 따라서 SWT 기반 GUI는 호스트 룩앤필과 호스트 퍼포먼스를 갖는다. 특정 호스트는 저수준 제어를 갖고 있어서 SWT는 확장되고 자주 에뮬레이트 되는 버전들을 제공하기 때문에 우리가 기대하는 작동에 더 가깝게 수행한다. (" C "는 이름의 첫 글자를 따온것이다.)
SWT는 피어가 작동하는 방식에 있어서 AWT와는 다르다. SWT에서 피어들은 호스트 제어에 대한 래퍼일 뿐이다. AWT에서 피어들은 호스트들 간 차이를 최소화 하는 서비스를 제공한다. (바로 이것이 AWT가 많은 작동상의 문제를 겪는 이유이다.) SWT 애플리케이션은 진정한 호스트 애플리케이션이다. SWT는 WORE 목적을 완전히 달성하지 못했다. WOTE 솔루션에 가깝다. SWT는 Swing 만큼은 아니더라도 이식성 있는 솔루션을 구현했다는 점이 주목할만하다.
SWT 위젯, 레이아웃, 이벤트는 다음과 같다. (Listing 7, Listing 8, Listing 9) ) AWT에서 제공하는 것 보다 훨씬 더 많고 Swing 세트와도 비교된다.
Listing 7. SWT 기본 클래스 트리 (대부분 org.ecipse.swt.widgets나 org.eclipse.swt.custom 패키지 또는 하위 클래스에 있다. "*"는 추상 클래스이고, "!"는 커스텀 패키지, "~"는 기타 패키지이다.)
| Object *Dialog ColorDialog DirectoryDialog FileDialog FontDialog MessageDialog PrintDialog *Widget Menu *Item CoolItem !CTabItem MenuItem TabItem TableColumn TableItem TableTreeItem ToolItem TrayItem TreeColumn TreeItem *Control Button Label ProgressBar Sash Scale Scrollable Composite ~Browser Canvas *~AbstractHyperlink ~Hyperlink ~ImageHyperlink *~ToggleHyperline ~TreeNode ~Twistie AnimatedProgress !CLabel Decorations Shell FormText StyledText TableCursor !CBanner !CCombo Combo CoolBar !CTabFolder ~ExpandableComposite ~Section ~FilteredList ~FilteredTree ~Form Group ~PageBook ProgressIndicator !SashForm !ScrolledComposite TabFolder Table TableTree ToolBar Tray Tree ViewForm List Text Slider |
주: 다른 것도 있지만 이것이 기본적인 것들이다.
AWT와 Swing 레이아웃 매니저와 마찬가지로 SWT는 포괄적인 레이아웃 세트를 제공한다. 중첩 컨테이너와 두 개의 레이아웃 시스템들은 거의 모든 레이아웃 알고리즘을 만들 수 있다. 이 세 개의 GUI 라이브러리는 완벽한 제어 포지셔닝도 지원한다. BorderLayout가 부족한 것이 아쉽다. FormLayout은 폼 기반 인풋을 만드는데 아주 좋다. SWT 레이아웃 스킴은 AWT/Swing 보다 배우기가 더 어렵다.
Listing 8. SWT 레이아웃 매니저 (대부분 org.eclipse.swt.layout org.eclipse.swt.custom 패키지나 하위 패키지에 있다. "*"는 인터페이스이고, "!"는 커스텀 패키지이다.)
| *Layout FillLayout FormLayout GridLayout RowLayout !StackLayout |
주: 이 외에 다른 레이아웃 매니저가 있지만 이것이 기본 세트이다.
AWT와 Swing 이벤트 시스템과 마찬가지로 SWT는 포괄적인 이벤트 세트를 제공한다. 이벤트는 AWT/Swing과 일대일 관계는 아니지만(AWT와 Swing 버튼은 ActionEvent를 실행하고 SWT 버튼은 SelectionEvent를 실행한다.) 대게는 동급이다.
Listing 9. SWT의 이벤트 (대부분 org.eclipse.swt.events 패키지나 org.eclipse.swt.custom 패키지에 있다. "*"는 앱스트랙트이고 "!"는 커스텀 패키지이다.)
| Object EventObject SWTEventObject TypedEvent AimEvent !BidiSegmentEvent ControlEvent !CTabFlolderEvent DisposeEvent DragSourceEvent DragTargetEvent !ExtendedModifyEvent focusEvent HelpEvent KeyEvent TraverseEvent VerifyEvent !LineBackgroundEvent !LineStyleEvent MenuEvent ModifyEvent MouseEvent PaintEvent SelectionEvent TreeEvent ShellEvent !TextChangedEvent !TextChangingEvent |
주: 기타 SWT 이벤트도 있지만 이것이 기본 세트이다. 이것은 보다 일반적인 이벤트에서 생성된 이벤트이다.
JTable 같은 많은 Swing 컴포넌트들은 모델을 갖고 있다. SWT 제어(Table)는 그렇지 않다. 대신 아이템들이 있다. 아이템들은 텍스트나 작은 이미지(아이콘)만을 보여준다. Swing과 같은 모델 구조를 제공하기 위해 JFace ContentProviders가 사용된다. 이 프로바이더는 애플리케이션에서 제공하는 모델(java.util.Array)과 뷰로서 작동하는 컨트롤 간 다리 역할을 한다. 임의의 모델 객체들을 아이템으로 포맷팅 할 때 SWT는 JFace LabelProviders를 사용한다. 이것은 어 떤 모델 객체에도 텍스트나 아이콘 형태를 생성한다. 복잡한 모델 객체의 디스플레이의 경우 복잡성을 제한할 수 있다. 이 외에도 ColorProviders와 LabelDecorators같은 프로바이더는 아이템의 디스플레이를 향상시킨다. Table이라는 특별한 경우에 SWT는 임의의 SWT 제어를 Table 셀로 임시 연결하는 CellEditor를 제공한다.
SWT는 GUI의 자동 정리를 지원하지 않는다. 색상과 폰트 같은 제어나 리소스를 직접 정리해야 한다. 컨테이너 제어가 자식 제어들을 자동으로 정리하기 때문에 그나마 수월하다.
SWT는 GUI를 탑다운 방식으로만 구현한다. 따라서 부모 컨테이너 없이 제어는 존재할 수 없고, 부모는 변할 수 없다. 이러한 방식은 AWT/Swing 보다 덜 유연하다. 제어는 생성 및 제거 시 부모 컨테이너에 추가된다. 또한 구현할 때에만 style 비트를 사용하기 때문에 GUI 제어의 유연성에도 한계가 있다. 많은 스타일들이 유일한 힌트이고 모든 플랫폼에 동일하게 작동하지 않는다.
Swing과 마찬가지로 SWT 컴포넌트는 쓰레드 보안이 되지 않는다. 어떤 쓰레드가 GUI를 업데이트 하는지를 신경 써야 한다. 쓰레드 사용을 잘 못하면 예외가 던져질 것이다. 개인적으로는 이것이 Swing 방식보다 낫다고 생각한다. 특별한 유틸리티 루틴은 쓰레딩 문제를 관리하는데 도움이 된다.
지원 호스트가 접근성 서비스를 제공한다면 SWT GUI도 일반적으로 접근성이 있다. SWT는 프로그래머를 위한 기본 프로세스 API를 제공하여 디폴트 정보가 불충분 할 때 접근성 정보를 지정할 수 있도록 한다.
SWT는 제한된 그래픽 환경을 제공한다. Java2D와 Java3D의 지원과는 잘 비교되지 않는다. Eclipse는 Graphical Editing Framework(GEF) 에 UML 모델링 툴 같은 그리기 애플리케이션을 만드는데 사용되는 Draw2D 라는 컴포넌트를 제공한다. 하지만 GEF는 독립적으로 사용하기 힘들다. (Eclipse 환경 밖을 의미한다.)
AWT와 Swing과는 달리 SWT와 JFace는 자바 표준이 아니다. Eclipse의 일부 또는 개별 라이브러리로서 설치되어야 한다. Eclipse 팀은 설치가 쉽도록 만들었고 Eclipse와 독립적으로 SWT를 실행하도록 만들었다. 필요한 자바 아카이브(JAR)과 동적 링크 라이브러리(DLL), 유닉스와 매킨토시용 유사 라이브러리 등을 Eclipse 웹 사이트에서 개별적으로 다운로드 할 수 있다. JFace 라이브러리의 경우 모든 Eclipse를 다운로드 하고 필요한 JAR를 복사해야 한다. 다운로딩 되면 JAR는 Java CLASSPATH에 DLL은 system PATH에 있어야 한다.
아래 표에서는 AWT, SWT, Swing 라이브러리의 다양한 특징들을 비교했다.
| 기능/역할/양상 | AWT | Swing | SWT (style) |
|---|---|---|---|
| 정적 텍스트 디스플레이 | Label | JLabel | Label, CLabel |
| 멀티 라인 정적 텍스트 디스플레이 | Multiple Labels | Multiple JLabels 또는 JLabel과 HTML content | Multiple Labels 또는 Label과 newlines |
| 멀티 라인 포맷의 정적 텍스트의 디스플레이 | Multiple Labels와 다양한 폰트 | JLabel과 HTML content | Multiple Labels와 다양한 폰트 |
| 싱글 라인 텍스트 엔트리 | TextField | JTextField | Text(SWT.SINGLE) |
| 멀티 라인 텍스트 엔트리 | TextArea | JTextArea | Text(SWT.MULTI) |
| 이미지 디스플레이 | N/A | JLabel | Label |
| 텍스트와 이미지 디스플레이 | N/A | JLabel | CLabel |
| ToolTip 팝업 도움말 | N/A | setToolTip on component, subclass JToolTip | setToolTip on control |
| 텍스트 엔트리 스타일링 | N/A | JEditorPane | StyledText |
| 아이템 리스트 선택하기 | List | JList | List |
| 푸쉬 버튼과 텍스트 | Button | JButton | Button(SWT.PUSH) |
| 푸쉬 버튼, 텍스트/이미지 | N/A | JButton | Button(SWT.PUSH) |
| 그리기 영역 | Canvas | JPanel | Canvas |
| On/off 체크박스 | CheckBox | JCheckBox | Button(SWT.CHECK) |
| 라디오 선택 | CheckBoxGroup | ButtonGroup과 메뉴 | Group과 메뉴 |
| 드롭다운 리스트 선택 | Choice | JComboBox | Combo, CCombo |
| 텍스트 입력하기 또는 드롭다운 리스트에서 선택하기 | N/A | JComboBox | Combo, CCombo |
| 스크롤 영역 | ScrollPane | JScrollPane | Create Scrollable subclass |
| 탑 레벨 윈도우 | Dialog, Frame, Window | JDialog, JFrame, JWindow | Shell과 different styles |
| 기본 윈도우 | Window | JWindow | Shell |
| 프레임 윈도우 | Frame | JFrame | Shell(SWT.SHELL_TRIM) |
| 다이얼로그 윈도우 | Dialog | JDialog | Shell(SWT.DIALOG_TRIM) |
| 메뉴 | Menu | JMenu | Menu |
| MenuItem | MenuItem | JMenuItem | MenuItem |
| 메뉴 단축 | 키 스트로크 | AWT와 동일 | host dependent mnemonics과 accelerators |
| 팝업 메뉴 | PopupMenu | JPopupMenu | Menu(SWT.POPUP) |
| 메뉴 바 | MenuBar | JMenuBar | Menu(SWT.BAR) |
| 삽입 기호 디스플레이 | N/A | Caret | Caret |
| 웹 브라우저 | N/A | JTextPane (HTML 3.2) | Browser (임베디드 브라우저) |
| 웹 페이지에 컨트롤 삽입하기 | Applet | JApplet | Host control (ex. OLE) |
| 기타 컨트롤의 컨테이너 | Panel | JPanel | Composite |
| 기타 컨트롤과 보더의 컨테이너 | Panel (직접 그릴 경우) | JPanel과 Border | Composite(SWT.BORDER) |
| 기타 컨트롤과 보더와 타이틀의 컨테이너 | N/A | JPanel과 TitledBorder | Group |
| 라디오 버튼 | Checkbox | JRadioButton | Button(SWT.RADIO) |
| 라디오 버튼의 확장 제어 | CheckboxGroup | RadioButtonGroup | Group |
| 화살표 버튼 | N/A | JButton과 image | Button(SWT.ARROW) |
| 국제 텍스트 지원 | via ComponentOrientation | AWT와 동일 | 많은 컴포넌트들이 지원하고 있음 |
| 포커스 트래버스 | Policy와 Manager objects | AWT와 동일 | Next on control |
| 커스텀 다이얼로그 | Dialog subclass | JDialog subclass | Dialog subclass |
| 시스템 이벤트로의 액세스 | EventQueue services | AWT와 동일 | Display services (AWT 보다 덜함) |
| 시스템 액세스 다이얼로그 | FileDialog | JColorChooser, JFileChooser | ColorDialog, DirectoryDialog, FileDialog, FontDialog, PrintDialog |
| 간단한 메시지 다이얼로그 디스플레이 | N/A (Dialog 분류 필수) | JOptionPane static methods | MessageBox와 다양한 스타일 |
| 프롬프트 다이얼로그 디스플레이 | N/A (Dialog 분류 필수) | JOptionPane static methods | N/A (JFace에는 존재하지 않음) |
| 레이아웃 매니저 | BorderLayout, CardLayout, FlowLayout, GridLayout, GridBagLayout | AWT plus BoxLayout, CenterLayout, SpringLayout | FillLayout, FormLayout, GridLayout, RowLayout, StackLayout |
| 기본 그리기 제어 | Canvas | JPanel | Canvas |
| 기본 그리기 | Graphics와 Graphics2D 객체 – 기본 모양과 텍스트, 임의의 Shapes와 Strokes, Bezier, 파일 등 | AWT와 동일 | GC object – 기본 모양과 텍스트 |
| 그리기 변형 | Affine, composites | AWT와 동일 | N/A |
| 오프 스크린 그리기 | BufferedImage, drawImage | AWT와 동일 | Image, drawImage |
| 더블 버퍼링 | 수동 | 자동/수동 | 호스트 컨트롤이 없을 경우 수동 |
| 프린팅 | PrintJob과 PrintGraphics | AWT와 동일 | Printer 장치 |
| 커스텀 컬러 | Color | AWT와 동일 | Color |
| 커스텀 폰트 | Font, FontMetrics | AWT와 동일 | Font |
| 커서 선택 | Cursor | AWT와 동일 | Cursor |
| 이미지 기능 | load from file, create dynamically, extensive edits | AWT와 동일 | load from file, create dynamically, basic edits |
| 인풋 자동화 | Robot | AWT와 동일 | N/A |
| 툴바 디스플레이 | N/A | JToolBar | ToolBar, CoolBar |
| 프로그레스 바 디스플레이 | N/A | JProgressBar | ProgressBar |
| 영역 간 공간 분리 | N/A | JSplitPane | Sash 또는 SashForm |
| 탭 영역 디스플레이 | N/A | JTabbedPane | TabFolder, CTabFolder |
| 테이블 형태 정보 디스플레이 | N/A | JTable | Table |
| 테이블 칼럼 포맷 | N/A | TableColumn | TableColumn |
| 계층적 정보 디스플레이 | N/A | JTree | Tree |
| 값 범위에서 선택하기 | N/A | JSlider | Slider |
| 분리된 값의 범위에서 선택하기 | N/A | JSpinner | Scale |
| 베이스 디스플레이로 액세스 하기 | Toolkit, GraphicsConfiguration, GraphicsDevice | AWT와 동일 | Display |
| 시스템 트레이에 아이템 추가하기 | N/A | N/A | Tray |
| 주: N/A - 해당사항 없음. 현재 구현되고 있는 경우가 대부분이고, 커스텀 컨트롤이나 컨트롤의 컨테이너를 구현하거나 또는 다른 커스텀 프로그래밍으로 인해 난이도는 차이가 난다. | |||
SWT Swing AWT 툴킷을 비교해 보았다. 이 글이 자신에게 맞는 GUI 툴을 선택하는데 도움이 되었기 바란다.
대부분의 경우 Swing과 JFace와 결합한 SWT를 선택한다. 일반적으로 이들 툴킷들은 완벽한 기능을 갖춘 GUI를 구현하기에 충분하다. 하지만 Swing은 SWT 단독(JFace 없음)보다 우수하다. Swing은 자바에 구현된다는 장점이 있다. 완벽히 이식 가능하고 아키텍처도 뛰어나다. Swing은 또한 고급 그래픽 애플리케이션도 갖추고 있다. SWT는 SWT 기반 GUI의 퍼포먼스와 원시 호환성을 높이는 애플리케이션으로서 구현된다는 장점이 있다.
한 개의 플랫폼만을 위해 개발하고 있다면 호스트 호환성 측면에서는 SWT가 낫다. ActiveX 컨트롤 같은 호스트 기능과도 통합된다.
교육
- "Migrate your Swing application to SWT."
- "Eclipse Workbench 밖에서 Eclipse GUI 사용하기, Part 1."
- AWT package summary documentation.
- Swing package summary documentation, The Swing Connection, Creating a GUI with JFC/Swing, Java Foundation Classes in a Nutshell.
- "SWT and JFace: A gentle introduction"
- developerWorks' Eclipse project resources
- developerWorks technical events and webcasts.
- developerWorks Open source zone
제품 및 기술 얻기
토론
.
=================================
=================================
=================================
'JAVA > JAVA UI' 카테고리의 다른 글
| java - JTable 메소드 (0) | 2011.09.06 |
|---|---|
| 자바 - swing JTable, JList 관련 (0) | 2011.09.06 |
| 자바 GUI 툴/플러그인 개발 관련 (0) | 2011.08.12 |
| JAVA - jlist에 이미지 넣기 (0) | 2011.05.04 |
| 이클립스용 GUI 빌더, Jigloo - 참고자료 등 (0) | 2011.04.28 |
댓글 영역