awt와 swing의 차이점

awt와 swing의 차이점

나만의 작업 2007/06/19 21:26

java로 응용프로그램을 만들어본게 손에 꼽을 정도라서 awt와 swing의 확실한 차이점을 몰랐습니다. 오늘 배운내용을 이번기회에 확실히 알고 넘어가기 위해서,,

AWT는 Abstract Windows Toolkit의 약자로 '추상 윈도우 개발 도구'라는 뜻으로
운영체제의 자원을 이용하여 control의 외형을 형성합니다.

즉 MS의 윈도우와 유닉스계열에서 GUI가 비슷하게는 나타나지만 같게 보이지는 않습니다.
그래서 'abstract'인거지요.
예로 button component를 생성하면 운영체제마다 그 버튼의 모양과 크기는 조금씩 다르게 나타납니다. 이것이 peer를 통한 component의 생성으로 나타나는 문제입니다.
(현재 운영제체의 각 component를 peer component라고 합니다.AWT는 기반운영시스템에서 Native code를 빌려서 GUI를 생성시킨 Peer 구조를 가집니다.)

운영체제에서 표현하고자 하는것을 중립적으로 표현하기에는 좋지만
다양하게 표현하기엔 힘들다는것이 단점입니다. 그래서 예쁘게 나오기도 힘들구요
제한된 GUI 컴포넌트, 레이아웃 매니저, 이벤트를 가진 매우 단순한 툴킷입니다.

더 자세한 설명

AWT 컴포넌트 모델<?XML:NAMESPACE PREFIX = O />

<!--[if !supportEmptyParas]--> <!--[endif]-->

AWT는 플랫폼에 독립적인 API를 제공하는 것에서 시작해서 설계되었고 아직까지는 각 플랫폼에서의 룩앤필(look and feel)을 따르고 있습니다. 예를 들어, AWT는 Button 클래스에 의해 제공되는 버튼을 위한 단지 하나의 API를 가지지만, 윈도우 95 상에서와 매킨토시에서 보이는 버튼을 서로 플랫폼에 맞게 차이가 있습니다. AWT는 플랫폼 독립적 이지만 각 플랫폼에서 특별하게 제공해 주는 구현(peer)을 사용하는 API를 제공하는 클래스(컴포넌트)들을 제공함으로써 플랫폼에 따라 서로 다르게 나타납니다. 특히, 모든 AWT 컴포넌트 클래스(Component, MenuComponent, 그리고 하위클래스)는 동등한 peer 클래스를 갖고, 모든 컴포넌트 객체는 객체의 보고 느끼는 모양 (look and feel)을 제어하는 peer 객체를 갖습니다.

Peer 객체는 해당 컴포넌트 객체가 처음으로 그려지기 전에 바로 로딩되는 느린 로딩(lazy loading)이 적용됩니다. 이러한 경우에 발생하는 주목할만한 하나의 측면 효과(side effect는 컴포넌트가 처음으로 그려지기 전까지는 그 컴포넌트의 크기가 유효하지 못하다는 것입니다.

따라서, 컨테이너는 어떤 peer도 가지지 않는데 어떤 컴포넌트를 보이지 않는(non-visible) 컨테이너에 추가하고 그 컨테이너가 처음으로 보여지기 전에, 그 컨테이너가 포함하고 있는 모든 컴포넌트들의 peer 가 생성됩니다. 그러나, 만약 보이는(visible) 컨테이너에 컴포넌트를 삽입한다면, AWT가 그 컴포넌트를 위한 peer를 생성할 수 있도록 정확하게 알려주어야 합니다. 이러한 작업은 validate 메소드를 호출함으로써 하게 됩니다. 비록 현재 추가된 컴포넌트의 validate 메소드르 직접 호출할 수 있다고 하더라도, 일반적으로 컨테이너의 validate 메소드가 대신 수행됩니다. 그 이유는 컨테이너의 validate 메소드를 수행하는 것이 연쇄 작용(chain reaction)을 유발하여 컨테이너에 포함된 모든 컴포넌트들이 유효화되기(validated) 때문입니다. 예를 들어, 컴포넌트들을 Applet 객체에 추가한 후, Applet 내에 있는 모든 컴포넌트들을 위한 peer들을 생성하는 Applet의 validate 메소드를 호출합니다.

peer는 사용자의 입력 이벤트에 반응함으로써 UI 컴포넌트의 feel(간접적으로 look을)을 구현합니다. 예를 들어, 사용자가 버튼을 클릭할 때, peer는 버튼의 모양을 변하게 하고 Button 객체에 action 이벤트를 전달함으로써 마우스 다운(mouse down)과 마우스 업(mouse up) 이벤트에 반응(reacting)하게 됩니다. 이론적으로, peer들은 이벤트 연결(event chain)의 끝에 위치하고 있습니다. 키가 눌리는 것과 같은 실제 이벤트(raw event)가 발생할 때, 이벤트가 발생한 컴포넌트는 먼저 이벤트를 처리하고, 그리고 나서 만약 컴포넌트의 이벤트 처리기(event handler)가 false를 리턴하였다면 컴포넌트의 컨테이너가 그 이벤트를 발견하고 처리하게 됩니다. 컴포넌트 구조(hierarchy) 내에 있는 모든 컴포넌트들이 그 이벤트를 처리할 기회를 가졌고 모든 이벤트 처리기가 false를 리턴하였다면, peer가 그 이벤트를 보고 이벤트에 대한 작용을 하게 됩니다.

현재 구현상에서, 위의 시나리오는 키가 눌리는 이벤트에 대해서는 올바르게 작용하지만, 마우스 이벤트에 대해서는 그렇지 않습니다. 마우스 이벤트의 경우에는, peer가 먼저 그 이벤트를 보고, 그 컴포넌트에 모든 이벤트를 보낼 필요는 없습니다. 그러나 향후 릴리즈에서는 마우스 이벤트를 키보트 이벤트와 같은 방식으로 처리할 것입니다.

peer는 가끔 키가 눌리고 마우스 클릭이 발생하는 것과 같은 실제 이벤트(raw event)로부터 고수준 이벤트 동작, 포커스 이동, 윈도우 아이콘화 등을 발생시킵니다. 이러한 보다 고수준 이벤트들은 이벤트 처리와 관련된 컴포넌트에 전달됩니다.

less..

Swing(Part of Java Foundation Classes)은 운영체제에 구애받지 않고 구현할 수 있다.
기존의 awt는 해당 운영체제의 GUI를 빌려쓰는 형식이지만 Swing은 pure java로만
구성되어 있기때문에 리눅스든 윈도우든 솔라리스든간에 인터페이스가 동일하다

다만 단점은 AWT보다 느리다는 것.

AWT component is also known as heavyweight component because all AWT components have its peer, the native GUI components. For example, Button, TextArea, and Label are heavyweight components. They have peer in C code on the native platform.

Swing was developed to enhance the AWT toolkit by allowing user to create lightweight components which do not have the native GUI component. For example, JTabbedPane is a lightweight component of Swing. It has no peer in C code on the native platform.

참고로 eclipse는 swt(Standard Windows Toolkit)로 GUI가 개발되었습니다.

java에서 GUI를 지원하기 위한 도구로 sun에서 개발한 Swing이 널리 사용되고 있었는데, IBM에서 통합개발 플랫폼인 Eclipse를 개발하면서 Swing 대신 자체적으로 개발한 GUI라이브러리를 제작합니다.

swing과 swt의 비교
Swing : J2SE를 위한 GUI 툴킷
SWT : IBM의 공개 프로젝트인 Eclipse 플랫폼의 제작을 위해 별도로 개발된 라이브러리

SWT는 Standard Widget Toolkit의 줄임말로 각 운영체제자체에서 제공되는 위젯 툴킷을 통합한 그래픽 라이브러리다. 이는 각 타겟 플렛폼에 꽤나 의존적이 될 수도 있음을 의미하지만, OS독립적인 API를 제공함으로써 이 문제를 해결하고 있다. 이들 API는 목표가 되는 운영체제 시스템의 GUI코드를 wrapper함으로써 개발자 입장에서는 운영체제에 신경쓰지 않고 동일한 코드를 유지할 수 있게 된다.

덧붙여 설명하자면, Swing은 모든 위젯이 운영체제와 별개를 사용하는데(자바의 모토가 One make All use 아니던가) 그렇기때문에 Swing의 GUI는 웬지 눈에 낯설고 어색해 보이는 면이 있어왔다. 그러나 SWT는 가능한한 사용할 수있는 모든 Native Widget은 사용하고, 그러하지 않는 부분만 자바의 자체 위젯을 사용한다. 때문에 최대한 그 OS의 Native GUI와 비슷한 모습을 보여주는것이다.(Native에서 제공하지 않는 자체 위젯까지 포함하므로 때론 더 이쁠수도 있겠다. 물론 반대인 경우도 있겠지만).

그럼 자바가 시스템에 독립적이지 않은게 아닌가? 하고 반문할지 모르지만 위에 설명된 바와같이 공통적인 API를 사용하므로서 (Abstract Layer라고 볼 수 도 있겠다) OS가 다르다고 해서 소스코드의 변경을 필요로 하지 않는것이다. (VM차원에서 Native Widget를 해당 API로 랩핑해주므로)

출처

참고한 URL

http://www.javastudy.co.kr/docs/yopark/chap08/chap08.html#_Toc466766198
http://abangwithjava.blogspot.com/2006/09/java-gui-awt-swing-and-swt.html
http://blog.naver.com/zzanggoosoft?Redirect=Log&logNo=30009621746
http://www.ibm.com/developerworks/java/library/os-swingswt/index.html