맨위로가기

표준 위젯 툴킷

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

표준 위젯 툴킷(SWT)은 자바 GUI 애플리케이션 개발을 위한 툴킷으로, 자바 네이티브 인터페이스(JNI)를 통해 운영체제 고유의 그래픽 구성 요소를 직접 사용하여 네이티브 성능과 룩앤필을 제공한다. AWT, Swing과 같은 다른 자바 GUI 툴킷과 비교되며, 특히 이클립스 IDE의 핵심 UI 구성 요소로 널리 사용된다. SWT는 플랫폼 종속적인 특성을 가지며, JFace 라이브러리와 함께 사용되어 MVC 패턴을 지원하기도 한다.

더 읽어볼만한 페이지

  • Eclipse (소프트웨어) - AspectJ
    AspectJ는 자바 언어의 관점 지향 프로그래밍 확장이자, 확장 메서드, 포인트컷, 어드바이스 등의 기능을 통해 기존 코드 변경 없이 새로운 기능을 추가할 수 있도록 설계되었다.
  • Eclipse (소프트웨어) - 그래피컬 에디팅 프레임워크
    그래피컬 에디팅 프레임워크(GEF)는 이클립스 RCP 애플리케이션 내에서 그래픽 편집기와 뷰를 구현하기 위한 프레임워크이며, Draw2d, GEF(MVC), Zest를 주요 구성 요소로 사용하고 모델-뷰-컨트롤러(MVC) 패턴과 다양한 디자인 패턴을 활용한다.
  • 자바 API - 자바 암호화 확장
  • 자바 API - 자바 OpenGL
    자바 OpenGL(JOGL)은 자바에서 OpenGL API를 사용하기 위한 래퍼 라이브러리로, JNI 호출을 통해 OpenGL C API 및 윈도우 API에 대한 접근을 제공하며 OpenGL 4.5 사양과 Java2D와의 상호 운용성을 지원한다.
  • 이클립스 라이선스 소프트웨어 - JUnit
    JUnit은 자바 환경에서 단위 테스트를 위한 프레임워크로, 반복적인 테스트 실행을 통해 버그 수정에 용이하며, 어노테이션 기반의 간편한 테스트 코드 작성과 IDE 통합을 지원하여 개발 효율성을 높인다.
  • 이클립스 라이선스 소프트웨어 - Eclipse (소프트웨어)
    이클립스는 IBM에서 개발한 자바 기반의 통합 개발 환경으로, OSGi 서비스 플랫폼을 런타임 아키텍처로 사용하며, 플러그인을 통해 기능을 확장할 수 있고, 이클립스 퍼블릭 라이선스를 따르며, 한국어를 지원한다.
표준 위젯 툴킷 - [IT 관련 정보]에 관한 문서
기본 정보
개발자이클립스 재단
최초 공개일2003년 4월
안정화 버전4.29
안정화 버전 출시일2023년 9월 3일
프로그래밍 언어자바
운영 체제크로스 플랫폼
플랫폼자바 플랫폼
지원 언어다국어
장르자바 플랫폼용 위젯 툴킷
라이선스이클립스 퍼블릭 라이선스
웹사이트SWT: The Standard Widget Toolkit
윈도우 10에서의 이클립스 SWT 데모 응용 프로그램
윈도우 10에서의 데모 응용 프로그램

2. 자바 GUI 툴킷의 역사

썬 마이크로시스템즈가 1995년 자바 개발 키트(JDK) 1.0과 함께 추상 윈도 툴킷(AWT)을 발표하면서 자바 GUI 툴킷의 역사가 시작되었다. 이후 사용자들의 요청에 따라 J2SE 1.2 버전에 스윙이 도입되었다. 스윙은 AWT와 달리 모든 그래픽 구성 요소를 100% 자바로 구성하고, Java2D를 이용하여 직접 그려 OS 그래픽 자원 사용 방식에서 벗어났다.

1990년 오브젝트 테크놀로지 인터내셔널(OTI)은 스몰토크를 위한 멀티플랫폼, 이식 가능한 위젯 인터페이스 개발을 시작했다. 이는 IBM의 비주얼 에이지(Visual Age) 개발 통합 개발 환경(IDE) 프로젝트의 일환이었으며, 마이크로소프트 비주얼 스튜디오와 경쟁하기 위한 오픈 소스 프로젝트, 즉 이클립스 개발로 이어졌다.

2. 1. AWT (Abstract Window Toolkit)

썬 마이크로시스템즈가 1995년 자바 개발 키트(JDK, Java Development Kit) 1.0과 함께 발표한 최초의 자바 GUI 툴킷이다. AWT는 운영체제(OS)의 메뉴나 버튼 등을 자바로 감싼(래핑) 형태의 간단한 그래픽 툴킷이었다. 해당 운영 체제의 윈도 시스템을 그대로 이용하므로 윈도 시스템별로 특징적인 형태를 그대로 구현할 수 있지만, 자바의 OS 비의존성을 지키기 위하여 각 윈도 시스템별로 공통적으로 지원하는 그래픽 구성 요소(메뉴, 버튼, 문자상자 등)만 이용할 수 있다는 제약 때문에 지원하는 구성 요소가 많지 않았다.[37]

AWT는 네이티브 위젯 래퍼로서 매우 얇아서, 플랫폼 고유의 코드가 개발자에게 드러나고, 버그나 OS 고유의 특성이 그대로 노출되었기 때문에, 서로 다른 플랫폼 간에 이식 가능한 애플리케이션을 작성하는 데 한계가 있었다.[2]

2. 2. Swing

썬 마이크로시스템즈가 J2SE 1.2 버전을 출시하면서 발표한 차세대 GUI 툴킷이다.[37] 스윙은 추상 윈도 툴킷(AWT)보다 다양한 GUI 구성 요소를 제공하며, 100% 자바로 작성되어 플랫폼 독립성을 확보했다.[2]

스윙은 Java2D를 사용하여 모든 구성 요소를 직접 그려, AWT의 한계를 극복하고 다양한 룩 앤드 필을 지원한다. 그러나 운영체제 자원을 직접 활용하지 않아 이질감과 성능 저하 문제가 발생하여 널리 사용되지 못했다.[37]

2. 3. SWT (Standard Widget Toolkit)

오브젝트 테크놀로지 인터내셔널(OTI, Object Technology International)이 1990년 스몰토크를 위한 멀티플랫폼, 휴대성을 갖춘 고유의 위젯 인터페이스를 만드는 작업에서 SWT의 뿌리를 찾을 수 있다.[37] IBM은 스몰토크 언어로 제작된 비주얼 에이지(Visual Age) 개발 통합 개발 환경(IDE)을 개발하고 있었는데, 마이크로소프트 비주얼 스튜디오와 같은 다른 IDE와 경쟁할 의도로 오픈 소스 프로젝트를 개발하기로 결정했고, 이는 이클립스의 개발로 이어졌다.[2]

SWT는 실행하는 윈도 시스템 고유의 룩 앤드 필(Look and feel)을 가짐과 동시에 고유의 성능을 발휘하도록 개발되었다.[37] IBM이 Visual Age를 이클립스로 바꾸면서 오픈 소스화 할 때 SWT도 같이 공개되었다. SWT는 네이티브 코드 객체의 래퍼이므로, SWT 위젯은 "무거운" 네이티브 객체에 가벼운 Java 래퍼를 씌운 것과 같다는 이미지로 인해 "무겁다"고 표현되기도 한다. SWT가 필요로 하는 기능을 네이티브 GUI 라이브러리가 가지고 있지 않은 경우에는, SWT는 Swing처럼 자체 GUI 코드를 Java로 구현한다.

3. SWT 디자인

SWT는 자바 네이티브 인터페이스(JNI)를 통해 윈도 시스템에서 제공하는 고유 그래픽 구성 요소를 직접 사용하며, 스윙에 비해 비교적 하위 수준의 간단한 구현을 가진다.

리눅스 데모 애플리케이션


SWT는 GTK, Motif 객체 등과 같은 네이티브 코드 객체를 감싸는 래퍼이다. 이 때문에 SWT 위젯은 종종 "무거운" 네이티브 객체 주위에 가벼운 Java 래퍼를 씌운 것과 같은 이미지로 "헤비급"으로 불린다.[3][4] 네이티브 플랫폼 GUI 라이브러리가 SWT에 필요한 기능을 지원하지 않는 경우, SWT는 Swing과 유사하게 자체 GUI 코드를 Java로 구현한다. 본질적으로 SWT는 AWT의 로우 레벨 성능 및 모양과 느낌과 Swing의 하이 레벨 사용 편의성 사이의 절충안이다.[3][4]

Eclipse 재단에 따르면 "SWT와 Swing은 서로 다른 목표를 가지고 만들어진 서로 다른 도구"이다. SWT의 주요 설계 목표는 고성능, 네이티브 모양 및 느낌, 그리고 깊은 플랫폼 통합이다.[5] 반면에 Swing은 모든 플랫폼에서 공통적으로 사용되는 고도로 사용자 정의 가능한 모양과 느낌을 허용하도록 설계되었다.[5]

SWT는 디자인 패턴으로 유명한 에리히 감마의 영향을 받아 깔끔한 디자인을 갖추고 있다고 알려져 있다.[6]

SWT는 Swing보다 간단한 툴킷으로, 일반 개발자에게 덜 (아마도) 불필요한 기능을 제공한다.[7] 이 때문에 일부 사람들은 SWT가 Swing에 비해 기능이 부족하다고 주장하기도 한다.[8]

Java 언어의 창시자인 제임스 고슬링은 SWT가 너무 단순하며, AWT가 한때 포팅 문제를 겪었던 것과 같은 이유로 새로운 플랫폼으로 포팅하기 어려운 툴킷이라고 주장했다. 즉, 너무 단순하고, 너무 로우 레벨이며, Win32 GUI API에 너무 얽매여 있어 SWT API를 Motif 및 OS X Carbon과 같은 다른 GUI 툴킷에 적용하는 데 문제가 발생한다고 보았다.[7]

3. 1. 네이티브 위젯 사용

SWT는 운영체제의 고유 그래픽 구성 요소를 자바 네이티브 인터페이스(JNI)를 통해 직접 사용한다. 이는 스윙에 비해 비교적 하위 수준의 간단한 구현을 가지며, 네이티브 성능과 룩앤필을 제공한다.[3][4] SWT 위젯은 종종 동일한 네이티브 위젯이기 때문에 네이티브 위젯과 동일한 룩앤필을 가지고 있다. 이는 모든 위젯이 네이티브 위젯을 에뮬레이션하는 스윙 툴킷과는 대조적이다.[9][31]

예를 들어, macOS 트리 위젯은 트리가 확장될 때 미묘한 애니메이션을 특징으로 하며 기본 버튼은 사용자의 주의를 끌기 위해 애니메이션으로 맥동하는 빛을 가지고 있다. 이러한 위젯의 기본 스윙 버전은 애니메이션을 제공하지 않는다.

SWT는 네이티브 GUI 코드를 단순하게 래핑한 것이기 때문에, 운영 체제 공급업체가 운영 체제가 업데이트될 때 API 클라이언트를 손상시키지 않도록 주의한다면, 네이티브 코드가 변경될 때 대량의 업데이트가 필요하지 않다.

SWT는 "깊은 플랫폼 통합"을 목표로 하며, 이는 네이티브 위젯을 사용하는 SWT에 대한 Eclipse의 언급이다. developer.com의 마우로 마리닐리아에 따르면 "네이티브 플랫폼과의 긴밀한 통합이 필요하다면, SWT는 좋은 선택이다".[9][31] 이러한 깊은 통합은 예를 들어 SWT가 마이크로소프트 윈도우에서 ActiveX 객체를 래핑할 수 있도록 하는 등 여러 가지 방식으로 유용할 수 있다.

3. 2. JFace

모델-뷰-컨트롤러(MVC, Model-View-Controller영어)와 같은 디자인 패턴을 SWT에서 직접 지원하지 않기 때문에, 좀 더 추상화된 고수준의 패턴 지원을 위해 JFace가 개발되었다. 많은 경우 SWT와 함께 사용되기 때문에 SWT/JFace와 같이 병기하여 사용하는 경우가 많다.[27]

JFace 라이브러리는 SWT 위에 플랫폼에 의존하지 않는 고도화된 Model View Controller를 구현하고 있다. 개발자는 트리, 테이블, 리스트와 같은 복잡한 SWT 컨트롤에 대해, JFace가 제공하는 유연한 추상 데이터 모델을 사용하거나, SWT의 컨트롤을 직접 사용할 수 있다.

3. 3. 플랫폼 종속성

SWT는 자바 네이티브 인터페이스(JNI)를 사용하여 각 운영 체제의 고유 그래픽 구성 요소를 직접 사용한다. 이 때문에 각 운영 체제별 고유 라이브러리 파일이 필요하며, 자바가 구동되는 모든 환경에서 SWT가 작동하는 것은 아니다.[8] 여러 운영체제에서 사용해야 하는 프로그램을 개발할 때는 SWT가 해당 운영체제/윈도 시스템을 지원하는지 미리 확인해야 한다.

SWT는 플랫폼마다 다른 네이티브 라이브러리를 사용하므로, 플랫폼별 버그가 나타날 수 있다.[8] 또한, 윈도우 이외의 플랫폼에서는 SWT의 성능이 상대적으로 낮을 수 있다는 지적도 있다.[8]

SWT 구현은 플랫폼마다 다르므로, 플랫폼별 SWT 라이브러리(JAR 파일)를 각 애플리케이션과 함께 배포해야 한다.

2018년 기준으로 SWT는 다음과 같은 플랫폼 및 GUI 라이브러리를 지원한다.[11]

운영 체제GUI 라이브러리
Windows[12]
유닉스 계열: 리눅스, FreeBSDGTK
macOSCocoa



2018년 3월 기준으로, 공식적으로 호환되는 운영 체제 및 그래픽 라이브러리는 다음과 같다.[13]


  • Microsoft Windows (x86 및 x86_64)
  • 리눅스 (GTK / PPC64 및 PPC64LE)
  • macOS (Cocoa / x86_64)

4. 스윙과의 관계

스윙과 SWT는 서로 비슷하면서도 다른 특징을 가지고 있어, 사용자들 사이에서 어떤 것이 더 좋은지에 대한 논쟁이 많이 있었다. 그러나 SWT는 스윙과 직접 경쟁하는 툴킷이라기보다는, 각자의 용도에 맞는 또 다른 선택지로 사용되고 있다.[38]

초창기 자바 GUI 툴킷은 추상 윈도우 툴킷(AWT)이었다. AWT는 운영 체제에서 제공하는 기본적인 위젯들을 간단하게 래퍼 라이브러리로 감싼 형태였다.

스윙은 자바 플랫폼, 스탠다드 에디션(J2SE) 1.2에서 도입된 차세대 GUI 툴킷이었다. 스윙은 순수 자바로 만들어졌으며, Java 2D를 사용하여 자체적으로 컴포넌트를 그렸다.

SWT는 Object Technology International(OTI)가 1990년대에 스몰토크를 위해 만든 다중 플랫폼, 이식 가능한 네이티브 위젯 인터페이스에서 시작되었다. IBM은 통합 개발 환경(IDE)인 VisualAge를 개발하고 있었는데, 이를 오픈소스로 공개하면서 Eclipse가 만들어졌다. Eclipse는 자바로 작성되었고, IBM 개발자들은 "네이티브 사용자 인터페이스"와 "네이티브 성능"을 갖춘 툴킷이 필요하다고 판단하여 스윙을 대체하는 SWT를 만들었다.[2]

SWT는 네이티브 코드 객체를 감싸는 래퍼이기 때문에, "무거운" 네이티브 객체 주위에 가벼운 Java 래퍼를 씌운 것 같다는 의미로 "헤비급"이라고 불리기도 한다. SWT는 AWT의 낮은 수준의 성능 및 모양과 느낌, 그리고 스윙의 높은 수준의 사용 편의성 사이에서 절충한 것이다.[3][4]

Eclipse 재단에 따르면, SWT와 스윙은 서로 다른 목표를 가지고 있다. SWT는 다양한 플랫폼에서 네이티브 위젯에 접근하기 위한 공통 API를 제공하는 것을 목표로 하며, 고성능, 네이티브 모양 및 느낌, 깊은 플랫폼 통합을 추구한다. 반면 스윙은 모든 플랫폼에서 공통적으로 사용되는 고도로 사용자 정의 가능한 모양과 느낌을 허용하도록 설계되었다.[5]

SWT는 스윙보다 단순한 툴킷으로, 일반 개발자에게는 불필요한 기능을 덜 제공한다.[7] 이 때문에 SWT가 스윙에 비해 기능이 부족하다는 주장도 있다.[8]

Java 언어 창시자인 제임스 고슬링은 SWT가 너무 단순하고, 너무 낮은 수준이며, Win32 GUI API에 너무 얽매여 있어서 다른 GUI 툴킷에 적용하기 어렵다고 주장했다.[7]

SWT는 모델-뷰-컨트롤러(MVC) 아키텍처를 구현하지 않지만, JFace 라이브러리를 통해 SWT 위에 교차 플랫폼 하이 레벨 MVC 추상화를 제공할 수 있다.

AWT, 스윙, SWT를 동시에 사용하는 방법도 존재한다.[39]

5. 성능

SWT는 Swing보다 빠르고, 더 반응성이 뛰어나며, 시스템 자원 사용량이 적은 ''고성능'' GUI 툴킷으로 설계되었다.[15]

SWT와 Swing에 대한 몇 가지 벤치마킹 시도가 있었으며, 이 결과 SWT가 Swing보다 더 효율적이라는 결론이 나왔다. 하지만, 이 벤치마킹에 사용된 응용 프로그램은 가능한 모든 SWT 또는 Swing 사용에 대해 확고한 결론을 내릴 만큼 복잡하지는 않았다.[16] 꽤 철저한 벤치마크 세트는 Swing과 SWT 모두 일반적인 경우 서로 성능이 뛰어나지 않다는 결론을 내렸다.[17]

6. 플랫폼 지원

2010년 1월 현재 이클립스 3.5.1 버전을 기준으로 SWT가 지원하는 플랫폼은 다음과 같다.[40]

운영 체제아키텍처윈도 시스템
Windowsx86 32bit, 64bit (XP, Vista, 7)Win32
Windows CEARM PocketPC J2SE/J2ME
리눅스x86/x86_64, PPCGTK2, Motif
Solaris 10SPARC, x86GTK2, Motif
HP-UXIA64_32Motif
QNXx86Photon
AIXPPCMotif
Mac OSXCarbon, Cocoa, Cocoa/x86_64



해당 운영 체제와 윈도 시스템에 맞는 버전을 다운받아야 하며 일부 최신 기능의 경우는 운영 체제마다 조금씩 다를 수 있으므로 개발 문서를 참고해야 한다.

SWT는 지원해야 하는 모든 새로운 GUI 라이브러리에 포팅되어야 한다. Swing 및 AWT와 달리 SWT는 Java 릴리스의 일부가 아니므로 모든 Java 지원 플랫폼에서 사용할 수 없다. 또한 Windows 이외의 플랫폼에서 SWT의 성능이 눈에 띄게 덜 효율적이라는 증거도 있다.[8] SWT는 각 플랫폼에 대해 서로 다른 네이티브 라이브러리를 사용하므로 SWT 프로그램은 플랫폼별 버그에 노출될 수 있다.

SWT는 Swing보다 프로그램에 더 많은 저수준 세부 정보를 노출한다. 이는 SWT가 기술적으로 네이티브 라이브러리가 제공하는 GUI 기능 위에 있는 계층일 뿐이기 때문이며, 프로그래머에게 네이티브 GUI 코드를 노출하는 것은 SWT의 설계 의도의 일부이다. "목표는 풍부한 사용자 인터페이스 디자인 프레임워크를 제공하는 것이 아니라, 풍부한 그래픽 사용자 인터페이스(GUI) 애플리케이션을 구축할 수 있는 충분한 기능을 제공하면서 가능한 가장 많은 플랫폼에서 균일하게 구현할 수 있는 가능한 가장 얇은 사용자 인터페이스 API를 제공하는 것입니다."[10]

SWT 구현은 각 플랫폼마다 다르므로 플랫폼별 SWT 라이브러리(JAR 파일)를 각 애플리케이션과 함께 배포해야 한다.

2018년 기준으로 SWT는 다음과 같은 플랫폼 및/또는 GUI 라이브러리를 지원한다.[11]


  • Cocoa


2018년 3월 기준으로 SWT 4.7.3a(및 4.8M6)는 다음 운영 체제(명시적으로 필요한 경우 그래픽 라이브러리 또는 유사한 것/프로세서)와 공식적으로 호환된다.[13]

  • Microsoft Windows (x86 및 x86_64)
  • 리눅스 (GTK / PPC64 및 PPC64LE)
  • macOS (Cocoa / x86_64)


윈도우 XP는 역사적으로 s390, Solaris 11 (SPARCv9), Solaris 10 (x86_64), HP-UX (ia64), AIX (PPC 및 PPC64)에서 리눅스와 마찬가지로 지원되었다.[14]

SWT는 플랫폼 고유의 GUI 라이브러리에 대한 래퍼이기 때문에, Java가 동작하는 모든 플랫폼에서 동작하는 것은 아니다. 즉, SWT는 GUI 라이브러리마다 이식이 필요하며, Java가 새로운 플랫폼으로 이식되더라도, 즉시 SWT가 이식된다고는 할 수 없다(Swing이나 AWT는 Java 자체의 일부이지만, SWT는 그렇지 않다). 또한, Windows상의 SWT 외에는 비교적 효율이 떨어진다고 한다.[28] SWT는 플랫폼마다 다른 네이티브 라이브러리를 사용하기 때문에, 플랫폼 고유의 버그도 SWT에서는 그대로 존재한다.

2006년 3월 현재, SWT가 지원하는 플랫폼/GUI 라이브러리는 다음과 같다.

  • Motif
  • GTK+
  • Mac OS: Carbon

  • Cocoa 대응은 개발 중(Mac OS X 10.5 64비트 버전이 Carbon을 지원하지 않기 때문)
  • QNX Photon
  • 포켓 PC
  • Swing (SWTSwing 경유)

7. 확장성 및 다른 자바 코드와의 비교

SWT는 GTK, Motif 등 네이티브 코드 객체를 감싸는 래퍼이기 때문에, SWT 위젯은 종종 "무거운" 네이티브 객체 주위에 가벼운 Java 래퍼를 씌운 이미지로 "헤비급"이라고 불린다.[3][4] 네이티브 플랫폼 GUI 라이브러리가 SWT에 필요한 기능을 지원하지 않는 경우, SWT는 Swing과 유사하게 자체 GUI 코드를 Java로 구현한다. 본질적으로 SWT는 AWT의 로우 레벨 성능 및 모양과 느낌과 Swing의 하이 레벨 사용 편의성 사이의 절충안이다.[3][4]

Eclipse 재단에 따르면 SWT와 Swing은 서로 다른 목표를 가진 도구이다. SWT의 목적은 다양한 플랫폼에서 네이티브 위젯에 접근하기 위한 공통 API를 제공하는 것이며, 주요 설계 목표는 고성능, 네이티브 모양 및 느낌, 그리고 깊은 플랫폼 통합이다. 반면에 Swing은 모든 플랫폼에서 공통적으로 사용되는 고도로 사용자 정의 가능한 모양과 느낌을 허용하도록 설계되었다.[5]

SWT는 Swing보다 간단한 툴킷으로, 일반 개발자에게 불필요한 기능을 적게 제공한다.[7] 이 때문에 일부 사람들은 SWT가 Swing에 비해 기능이 부족하다고 주장한다.[8]

Java 언어의 창시자인 제임스 고슬링은 SWT가 너무 단순하며, AWT가 한때 포팅 문제를 겪었던 것과 같은 이유로 새로운 플랫폼으로 포팅하기 어렵다고 주장했다. 즉, 너무 단순하고, 너무 로우 레벨이며, Win32 GUI API에 너무 얽매여 있어 SWT API를 Motif 및 OS X Carbon과 같은 다른 GUI 툴킷에 적용하는 데 문제가 발생한다.[7]

SWT는 Swing 및 기타 하이 레벨 GUI 툴킷에서 사용되는 모델-뷰-컨트롤러 (MVC) 아키텍처를 구현하지 않지만, 같은 Eclipse 프로젝트의 일부로 개발된 JFace 라이브러리는 SWT 위에 교차 플랫폼 하이 레벨 MVC 추상화를 제공한다.

SWT 클래스는 네이티브 코드를 사용하기 때문에 모든 위젯 클래스에 대해 쉽게 상속할 수 없으며, 일부 사용자는 이로 인해 확장성이 저해될 수 있다고 생각한다. 이는 기존 위젯을 사용자 정의하는 것을 Swing을 사용하는 것보다 SWT로 구현하는 것을 더 어렵게 만들 수 있다.[18] 두 툴킷 모두 Java 코드만 사용하여 새 위젯을 작성하는 것을 지원하지만, SWT에서는 새 위젯이 모든 플랫폼에서 작동하도록 하기 위해 추가 작업이 필요하다.[18]

SWT 위젯은 다른 거의 모든 Java 툴킷과 달리, 자동 가비지 컬렉션의 표준 Java 방식과는 대조적으로 수동 객체 할당 해제를 필요로 한다. SWT 객체는 C 언어의 `free`와 유사한 `dispose` 메서드를 사용하여 명시적으로 할당 해제해야 한다.[19] 이렇게 하지 않으면 메모리 누수 또는 기타 의도하지 않은 동작이 발생할 수 있다. 이에 대해 일부는 "자원을 명시적으로 할당 해제하는 것은 적어도 평균적인 Java 개발자에게는 개발 시간(및 비용)의 퇴보일 수 있다"고 언급했으며, "이는 복합적인 축복이다. 즉, Swing을 사용할 때 더 많은 자동화(및 속도 저하) 대신 SWT 개발자에게 더 많은 제어(및 더 많은 복잡성)를 의미한다"고 언급했다.[9] SWT를 사용할 때 수동 객체 할당 해제가 필요한 이유는 주로 SWT가 네이티브 객체를 사용하기 때문이다. 이러한 객체는 Java JVM에서 추적되지 않으므로 해당 객체가 사용 중인지 여부를 추적할 수 없으며, 따라서 적절한 시점에 가비지 컬렉션을 수행할 수 없다.

8. 개발 현황

Swing과 SWT를 결합하기 위한 개발 활동이 진행 중이다. 두 가지 다른 접근 방식이 시도되고 있다.


  • '''SwingWT'''는 Swing의 대체 구현을 제공하는 프로젝트이다. SWT 백엔드를 사용하여 위젯을 표시하므로, Swing과 동일한 프로그래밍 모델과 함께 SWT의 네이티브 모양과 성능 이점을 제공한다.[20]
  • '''SWTSwing'''은 SWT를 위한 Swing 백엔드를 제공하는 프로젝트이다. SWT는 GTK 또는 Windows 네이티브 객체 대신 ''Swing 네이티브 객체''를 사용하여 실행될 수 있다. 이를 통해 SWT는 Swing이 지원하는 모든 플랫폼에서 작동할 수 있다.[21]


2006년부터 D 프로그래밍 언어로 DWT라는 SWT-3.2 포트가 있었다.[22] 그 이후로, 이 프로젝트는 SWT-3.4에 대한 Windows 32비트 및 Linux GTK 32비트를 지원한다. DWT 프로젝트는 JFace 및 Eclipse Forms의 포트를 포함하는 애드온 패키지도 가지고 있다.[23]

JavaFX가 Java SE 플랫폼의 일부가 되면서, SWTSwing이 Swing에 의존하는 방식과 유사하게 JavaFX에 의존하는 SWT 백엔드를 개발하는 데 관심이 생겼다. 이를 달성하려는 주요 프로젝트는 ''JavaFX의 SWT''였으며, 2014년에 ''e(fx)clipse''의 일부가 되었다.[24]

9. SWT 활용 사례

Vuze, SWT를 사용하는 비트토렌트 클라이언트


윈도우 XP의 예시 애플리케이션


SWT를 사용하는 대표적인 애플리케이션은 다음과 같다.

  • 아파치 디렉토리 스튜디오: LDAP 브라우저-편집기이다.
  • 이클립스 및 해당 플러그인
  • 검트리 플랫폼: 과학 작업대이다.
  • 헤이스택: 정보 관리자이다.
  • IBM 래셔널 소프트웨어 제품: 래셔널 애플리케이션 개발자, 래셔널 소프트웨어 아키텍트, 래셔널 팀 콘서트 등
  • IBM 로터스 소프트웨어 제품: 노츠, 사메타임, 심포니, 익스페디터
  • Studio 3T: MongoDB 데이터베이스를 위한 GUI 클라이언트이다.
  • RSSOwl: 피드 애그리게이터이다.
  • SmartGit: Git, Mercurial, 및 아파치 서브버전 (SVN) 클라이언트이다.
  • 턱스기타: 오픈 소스 태블러처 편집기이다.
  • uDig: GIS 도구이다.
  • Vuze: 이전 이름은 Azureus이다.


이클립스 커뮤니티는 SWT (및 JFace)를 웹에 적합한 위젯 툴킷으로 만들기 위해 노력해왔다. 그 결과로 Eclipse 원격 애플리케이션 플랫폼 (RAP)이 탄생했는데, 이는 qooxdoo Ajax 라이브러리를 SWT API와 결합한 것이다. 다른 Java Ajax 프로젝트와 마찬가지로, SWT API를 사용하면 데스크톱 애플리케이션 개발 방식과 거의 동일하게 웹 애플리케이션을 빠르게 개발할 수 있다.

참조

[1] 웹사이트 Licenses By Name http://www.opensourc[...] 2007-03-24
[2] 웹사이트 FAQ: Why does Eclipse use SWT? http://wiki.eclipse.[...] 2007-03-24
[3] 웹사이트 SWT: Implementation Strategy for Java Natives http://www.eclipse.o[...] 2001-03-22
[4] 웹사이트 SWT: Managing Operating System Resources http://www.eclipse.o[...] 2001-11-27
[5] 웹사이트 FAQ: Is SWT better than Swing? http://wiki.eclipse.[...] 2008-02-16
[6] 웹사이트 An Introduction to SWT http://www.javalobby[...] 2007-03-24
[7] 웹사이트 James Gosling Q & A http://www.builderau[...] 2007-03-24
[8] 웹사이트 Performance Benchmarks of Nine Languages http://developers.sl[...] 2007-03-24
[9] 웹사이트 Swing and SWT: A Tale of Two Java GUI Libraries http://www.developer[...] 2006-11-07
[10] 웹사이트 FAQ What is SWT http://wiki.eclipse.[...] eclipse.org 2009-10-16
[11] 웹사이트 4.8M6 - Eclipse Project Downloads http://download.ecli[...] 2018-05-01
[12] 웹사이트 Platform UI/Testing - Eclipsepedia https://wiki.eclipse[...] 2018-05-01
[13] 웹사이트 4.7.3a - Eclipse Project Downloads http://download.ecli[...]
[14] 웹사이트 4.6.3 - Eclipse Project Downloads http://archive.eclip[...] 2018-05-01
[15] 웹사이트 Why I choose SWT against Swing http://weblogs.java.[...] 2004-11-19
[16] 웹사이트 Swing vs. SWT Performance – Have a Look at the Call Stacks http://www.javalobby[...] Javalobby.org 2009-10-16
[17] 웹사이트 SWT Vs. Swing Performance Comparison http://cosylib.cosyl[...] cosylab.com 2008-05-24
[18] 웹사이트 Creating Your Own Widgets using SWT http://www.eclipse.o[...] eclipse.org 2008-12-13
[19] 문서 The Java developers guide to Eclipse, 2nd ed., p359
[20] 웹사이트 SwingWT – The Swing/AWT API over SWT library http://swingwt.sourc[...] Swingwt.sourceforge.net 2009-10-16
[21] 웹사이트 The SWTSwing project http://swtswing.sour[...] Swtswing.sourceforge.net 2009-10-16
[22] 웹사이트 DWT – Port of SWT and friends to the D programming language http://www.dsource.o[...] Dsource.org 2009-10-16
[23] 웹사이트 Eclipse Forms http://www.eclipse.o[...] Eclipse.org 2009-10-16
[24] 웹사이트 SWT on JavaFX is now a part of e(fx)clipse http://tomsondev.bes[...] 2014-03-13
[25] 웹사이트 3T MongoChef is now Studio 3T https://studio3t.com[...] 2017-02-08
[26] 웹사이트 Licenses By Name http://www.opensourc[...] 2007-03-24
[27] 웹사이트 James Gosling Q & A http://www.builderau[...] 2007-03-24
[28] 웹사이트 Performance Benchmarks of Nine Languages http://developers.sl[...] 2007-03-24
[29] 웹사이트 Why I choose SWT against Swing http://weblogs.java.[...] 2006-11-07
[30] 뉴스 Swing vs. SWT Performance - Have a Look at the Call Stacks http://www.javalobby[...] Javalobby 2006-03-03
[31] 웹사이트 Swing and SWT: A Tale of Two Java GUI Libraries http://www.developer[...] 2006-11-07
[32] 문서 The Java developers guide to Eclipse, 2nd ed., p359
[33] 서적 SWT: The Standard Widget Toolkit Addison-Wesley
[34] 웹사이트 Rich Ajax Platform (RAP) http://www.eclipse.o[...]
[35] 웹사이트 SwingWT http://swingwt.sourc[...]
[36] 웹사이트 swtswing http://swtswing.sour[...]
[37] 웹사이트 FAQ 왜 이클립스에서 SWT를 쓰는가? http://wiki.eclipse.[...]
[38] 웹사이트 FAQ SWT가 Swing보다 더 나은가? http://wiki.eclipse.[...]
[39] 웹사이트 FAQ 어떻게 AWT와 Swing을 SWT와 같이 사용할 수 있는가? http://wiki.eclipse.[...]
[40] 웹인용 SWT 다운로드 페이지 https://web.archive.[...] 2010-01-14


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com