linuxism

The Spring Framework is an open source application framework and Inversion of Control container for theJava platform.^[1]

The first version was written by Rod Johnson, who released the framework with the publication of his bookExpert One-on-One J2EE Design and Development in October 2002. The framework was first released under the Apache 2.0 license in June 2003. The first milestone release, 1.0, was released in March 2004, with further milestone releases in September 2004 and March 2005. The Spring 1.2.6 framework won a Jolt productivity award and a JAX Innovation Award in 2006.^[2][3] Spring 2.0 was released in October 2006, Spring 2.5 in November 2007, Spring 3.0 in December 2009, and Spring 3.1 in December 2011. The current version is 3.1.0.^[4]

The core features of the Spring Framework can be used by any Java application, but there are extensions for building web applications on top of the Java EE platform. Although the Spring Framework does not impose any specific programming model, it has become popular in the Java community as an alternative to, replacement for, or even addition to the Enterprise JavaBean (EJB) model.

[edit]Modules

The Spring Framework comprises several modules that provide a range of services:

• Inversion of Control container: configuration of application components and lifecycle management of Java objects, done mainly via Dependency Injection
• Aspect-oriented programming: enables implementation of cross-cutting routines
• Data access: working with relational database management systems on the Java platform using JDBC and object-relational mapping tools and withNoSQL databases
• Transaction management: unifies several transaction management APIs and coordinates transactions for Java objects
• Model-view-controller: an HTTP- and servlet-based framework providing hooks for extension and customization for web applications and RESTful web services.
• Remote Access framework: configurative RPC-style export and import of Java objects over networks supporting RMI, CORBA and HTTP-based protocols including web services (SOAP)
• Convention-over-configuration: a rapid application development solution for Spring-based enterprise applications is offered in the Spring Roo module
• Batch processing: a framework for high-volume processing featuring reusable functions including logging/tracing, transaction management, job processing statistics, job restart, skip, and resource management
• Authentication and authorization: configurable security processes that support a range of standards, protocols, tools and practices via the Spring Security sub-project (formerly Acegi Security System for Spring).
• Remote Management: configurative exposure and management of Java objects for local or remote configuration via JMX
• Messaging: configurative registration of message listener objects for transparent message-consumption from message queues via JMS, improvement of message sending over standard JMS APIs
• Testing: support classes for writing unit tests and integration tests

[edit]Inversion of Control container (Dependency injection)

Central to the Spring Framework is its Inversion of Control container, which provides a consistent means of configuring and managing Java objects usingreflection. The container is responsible for managing object lifecycles: creating objects, calling initialization methods, and configuring objects by wiring them together.

Objects created by the container are also called Managed Objects or Beans. Typically, the container is configured by loading XML files containing Bean definitions which provide the information required to create the beans.

Objects can be obtained by means of Dependency lookup or Dependency injection. Dependency lookup is a pattern where a caller asks the container object for an object with a specific name or of a specific type. Dependency injection is a pattern where the container passes objects by name to other objects, via either constructors, properties, or factory methods.

In many cases one need not use the container when using other parts of the Spring Framework, although using it will likely make an application easier to configure and customize. The Spring container provides a consistent mechanism to configure applications and integrates with almost all Java environments, from small-scale applications to large enterprise applications.

The container can be turned into a partially-compliant EJB3 container by means of the Pitchfork project. Some^[who?] criticize the Spring Framework for not complying with standards.^[5] However, SpringSource doesn't see EJB3 compliance as a major goal, and claims that the Spring Framework and the container allow for more powerful programming models.^[6]

[edit]Aspect-oriented programming framework

The Spring Framework has its own AOP framework which modularizes cross-cutting concerns in aspects. The motivation for creating a separate AOP framework comes from the belief that it would be possible to provide basic AOP features without too much complexity in either design, implementation, or configuration. The Spring AOP framework also takes full advantage of the Spring Container.

The Spring AOP framework is interception based, and is configured at run time. This removes the need for a compilation step or load-time weaving. On the other hand, interception only allows for public method-execution on existing objects at a join point.

Compared to the AspectJ framework, Spring AOP is less powerful but also less complicated. Spring 1.2 includes support to configure AspectJ aspects in the container. Spring 2.0 added more integration with AspectJ; for example, the pointcut language is reused and can be mixed with SpAOP-based aspects. Further, Spring 2.0 added a Spring Aspects library which uses AspectJ to offer common Spring features such as declarative transaction management and dependency injection via AspectJ compile-time or load-time weaving. SpringSource also uses AspectJ for AOP in other Spring projects such as Spring Rooand Spring Insight, with Spring Security also offering an AspectJ-based aspect library.

Spring AOP has been designed to make it able to work with cross-cutting concerns inside the Spring Framework. Any object which is created and configured by the container can be enriched using Spring AOP.

The Spring Framework uses Spring AOP internally for transaction management, security, remote access, and JMX.

Since version 2.0 of the framework, Spring provides two approaches to the AOP configuration:

• schema-based approach.
• @AspectJ-based annotation style.

The Spring team decided not to introduce new AOP-related terminology; therefore, in the Spring reference documentation and API, terms such as aspect, join point, advice, pointcut, introduction, target object (advised object), AOP proxy, and weaving all have the same meanings as in most other AOP frameworks (particularly AspectJ).

[edit]Data access framework

Spring's data access framework addresses common difficulties developers face when working with databases in applications. Support is provided for all popular data access frameworks in Java: JDBC, iBatis / MyBatis, Hibernate, JDO, JPA, Oracle TopLink, Apache OJB, and Apache Cayenne, among others.

For all of these supported frameworks, Spring provides these features

• Resource management - automatically acquiring and releasing database resources
• Exception handling - translating data access related exception to a Spring data access hierarchy
• Transaction participation - transparent participation in ongoing transactions
• Resource unwrapping - retrieving database objects from connection pool wrappers
• Abstraction for BLOB and CLOB handling

All these features become available when using Template classes provided by Spring for each supported framework. Critics say these Template classes are intrusive and offer no advantage over using (for example) the Hibernate API directly.^{[7][not in citation given]} In response, the Spring developers have made it possible to use the Hibernate and JPA APIs directly. This however requires transparent transaction management, as application code no longer assumes the responsibility to obtain and close database resources, and does not support exception translation.

Together with Spring's transaction management, its data access framework offers a flexible abstraction for working with data access frameworks. The Spring Framework doesn't offer a common data access API; instead, the full power of the supported APIs is kept intact. The Spring Framework is the only framework available in Java which offers managed data access environments outside of an application server or container.^{[citation needed]}

While using Spring for transaction management with Hibernate, the following beans may have to be configured

• DataSource like com.mchange.v2.c3p0.ComboPooledDataSource or org.apache.commons.dbcp.BasicDataSource
• SessionFactory like org.springframework.orm.hibernate3.LocalSessionFactoryBean with a DataSource attribute
• HibernateProperties like org.springframework.beans.factory.config.PropertiesFactoryBean
• TransactionManager like org.springframework.orm.hibernate3.HibernateTransactionManager with a SessionFactory attribute

Other configurations

• AOP configuration of cutting points using <aop:config>
• Transaction semantics of AOP advice using <tx:advice>

[edit]Transaction management framework

Spring's transaction management framework brings an abstraction mechanism to the Java platform. Its abstraction is capable of:

• working with local and global transactions (local transaction does not require an application server)
• working with nested transactions
• working with transaction safepoints
• working in almost all environments of the Java platform

In comparison, JTA only supports nested transactions and global transactions, and requires an application server (and in some cases also deployment of applications in an application server).

The Spring Framework ships a PlatformTransactionManager for a number of transaction management strategies:

• Transactions managed on a JDBC Connection
• Transactions managed on Object-relational mapping Units of Work
• Transactions managed via the JTA TransactionManager and UserTransaction
• Transactions managed on other resources, like object databases

Next to this abstraction mechanism the framework also provides two ways of adding transaction management to applications:

• Programmatically, by using Spring's TransactionTemplate
• Configuratively, by using metadata like XML or Java 5 annotations (@Transactional, etc)

Together with Spring's data access framework — which integrates the transaction management framework — it is possible to set up a transactional system through configuration without having to rely on JTA or EJB. The transactional framework also integrates with messaging and caching engines.

[edit]Model-view-controller framework

The Spring Framework features its own MVC web application framework, which wasn't originally planned. The Spring developers decided to write their own web framework as a reaction to what they perceived as the poor design of the (then) popular Jakarta Struts web framework^[8], as well as deficiencies in other available frameworks. In particular, they felt there was insufficient separation between the presentation and request handling layers, and between the request handling layer and the model.^[9]

Like Struts, Spring MVC is a request-based framework. The framework defines strategy interfaces for all of the responsibilities which must be handled by a modern request-based framework. The goal of each interface is to be simple and clear so that it's easy for Spring MVC users to write their own implementations if they so choose. MVC paves the way for cleaner front end code. All interfaces are tightly coupled to the Servlet API. This tight coupling to theServlet API is seen by some as a failure on the part of the Spring developers to offer a high-level abstraction for web-based applications^{[citation needed]}. However, this coupling makes sure that the features of the Servlet API remain available to developers while offering a high abstraction framework to ease working with said API.

The DispatcherServlet class is the front controller^[10] of the framework and is responsible for delegating control to the various interfaces during the execution phases of a HTTP request.

The most important interfaces defined by Spring MVC, and their responsibilities, are listed below:

• HandlerMapping: selecting objects which handle incoming requests (handlers) based on any attribute or condition internal or external to those requests
• HandlerAdapter: execution of objects which handle incoming requests
• Controller: comes between Model and View to manage incoming requests and redirect to proper response. It essentially is like a gate that directs the incoming information. It switches between going into model or view.
• View: responsible for returning a response to the client. It is possible to go straight to view without going to the model part. It is also possible to go through all three.
• ViewResolver: selecting a View based on a logical name for the view (use is not strictly required)
• HandlerInterceptor: interception of incoming requests comparable but not equal to Servlet filters (use is optional and not controlled by DispatcherServlet).
• LocaleResolver: resolving and optionally saving of the locale of an individual user
• MultipartResolver: facilitate working with file uploads by wrapping incoming requests

Each strategy interface above has an important responsibility in the overall framework. The abstractions offered by these interfaces are powerful, so to allow for a set of variations in their implementations, Spring MVC ships with implementations of all these interfaces and together offers a feature set on top of theServlet API. However, developers and vendors are free to write other implementations. Spring MVC uses the Java java.util.Map interface as a data-oriented abstraction for the Model where keys are expected to be string values.

The ease of testing the implementations of these interfaces seems one important advantage of the high level of abstraction offered by Spring MVC.DispatcherServlet is tightly coupled to the Spring Inversion of Control container for configuring the web layers of applications. However, web applications can use other parts of the Spring Framework—including the container—and choose not to use Spring MVC.

[edit]Remote access framework

Spring's Remote Access framework is an abstraction for working with various RPC-based technologies available on the Java platform both for client connectivity and exporting objects on servers. The most important feature offered by this framework is to ease configuration and usage of these technologies as much as possible by combining Inversion of Control and AOP.

The framework also provides fault-recovery (automatic reconnection after connection failure) and some optimizations for client-side use of EJB remote stateless session beans.

Spring provides support for these protocols and products out of the box:

• HTTP-based protocols
  • Hessian: binary serialization protocol, open-sourced and maintained by CORBA-based protocols
  • RMI (1): method invocations using RMI infrastructure yet specific to Spring
  • RMI (2): method invocations using RMI interfaces complying with regular RMI usage
  • RMI-IIOP (CORBA): method invocations using RMI-IIOP/CORBA
• Enterprise JavaBean client integration
  • Local EJB stateless session bean connectivity: connecting to local stateless session beans
  • Remote EJB stateless session bean connectivity: connecting to remote stateless session beans
• SOAP
  • Integration with the Apache Axis web services framework

Apache CXF provides integration with the Spring Framework for RPC-style exporting of object on the server side.

Both client and server setup for all RPC-style protocols and products supported by the Spring Remote access framework (except for the Apache Axissupport) is configured in the Spring Core container.

There is alternative open-source implementation (Cluster4Spring) of a remoting subsystem included into Spring Framework which is intended to support various schemes of remoting (1-1, 1-many, dynamic services discovering).

[edit]Convention-Over-Configuration Rapid Application Development

Spring Roo is Spring's Convention-over-configuration solution for rapidly building applications in Java. It currently supports Spring Framework, Spring Security and Spring Web Flow, with remaining Spring projects scheduled to be added in due course. Roo differs from other rapid application developmentframeworks by focusing on:

• Java platform productivity (as opposed to other languages)
• Usability (particularly via the shell features and usage patterns)
• Runtime avoidance (with associated deployment advantages)
• Lock-in avoidance (Roo can be removed within a few minutes from any application)
• Extensibility (via add-ons)

[edit]Batch Framework

Spring Batch is a framework for batch processing that provides reusable functions that are essential in processing large volumes of records, including:

• logging/tracing
• transaction management
• job processing statistics
• job restart
• skip
• resource management

It also provides more advanced technical services and features that will enable extremely high-volume and high performance batch jobs through optimizations and partitioning techniques.

[edit]Integration Framework

Spring Integration is a framework for Enterprise application integration that provides reusable functions that are essential in messaging, or event-driven architectures.

• routers
• transformers
• adapters to integrate with other technologies and systems (HTTP, AMQP, JMS, XMPP, SMTP, IMAP, FTP (as well as FTPS/SFTP), file systems, etc.)
• filters
• service activators
• management and auditing

Spring Integration supports pipe-and-filter based architectures.

[edit]References

[edit]Bibliography

[edit]See also

• Google Guice
• Apache HiveMind
• Spring Web Flow

[edit]External links

Free software portal

The Wikibook Java Programming has a page on the topic of Spring framework

• Spring Framework
• Spring ActionScript
• Spring Batch
• The Spring Framework - Reference Documentation
• Spring: The art of using GRASP Patterns

Standard Widget Toolkit ( SWT )는 Java 플랫폼 에 위젯 툴킷 의 일종. 원래 IBM 이 개발했지만 현재는 Eclipse Foundation 이 Eclipse IDE 함께 관리 유지하고있다. 썬마 이크로 시스템즈 가 Java 표준의 일환으로 제공하는 Java 용GUI 툴킷이다 AWT 와 Swing 을 대체하는 것으로서 개발되었다.

SWT는 Java로 작성되고있다. GUI 구성 요소를 표시하기 위해 SWT는 운영 체제가 제공하는 GUI 라이브러리를 JNI (Java Native Interface )를 통해 사용 (이것은 시스템 고유의 API 를 사용하는 일반적인 방법이다). SWT를 사용하는 프로그램은 이식이 도구 키트 자체의 구현은 Java로 쓰여 있음에도 불구하고 각 플랫폼이다.

SWT는 Eclipse Public License 의 라이센스되고있다. 이 라이선스는 Open Source Initiative 가 오픈 소스 라이센스로 인정하고있다 ^[1] .

Java GUI 툴킷의 역사 [ 편집 ]

처음 Java 용 GUI 툴킷은 AWT ( Abstract Window Toolkit )이며, 썬 Java 표준의 일부로 JDK 1.0에서 등장했다. AWT는 비교적 간단하고 운영 체제 가 제공하는 네이티브 오브젝트 를 Java 코드로 감싸고 메뉴나 버튼 등 GUI 요소를 생성한다. AWT는 네이티브 위젯 래퍼로 매우 얇고, 플랫폼 고유의 코드를 개발자에게 비쳐 보이고 버그와 OS 고유의 버릇이 그대로 드러 있기 때문에 다른 플랫폼간에 이식 가능한 응용 프로그램을 만들려면 한계가 있었다.

Swing 은 2 세대의 도구 키트에서 Sun이 J2SE 1.2에서 도입했다. AWT보다 객체 지향 이다. Swing의 GUI 부품은 100 % Java이며, 네이티브 코드는 사용하지 않습니다. 네이티브 API를 래핑하는 대신, Swing는 낮은 수준의 OS 루틴을 사용하여 GUI 부품을 자기 부담으로 그립니다.

그 무렵, IBM 은 Smalltalk 를 이용한 통합 개발 환경 (IDE) VisualAge 를 개발하고 있었다. 이것을 오픈 소스로 공개하기로 결정, 그것은 Eclipse 의 개발로 이어져 갔다. Eclipse는 Microsoft Visual Studio 같은 IDE와 충돌있는 것으로하는 것을 목적으로하고 있었다. Eclipse는 Java로 작성되고 있으며, IBM의 개발자들은 "네이티브룩앤필 "와"기본 성능 "을 가진 툴킷이 필요하다고 생각, Swing을 대체하는 것으로서 SWT를 개발했다 .

설계 [ 편집 ]

SWT는 GTK + 객체와 Motif 객체 같은 원시 코드 개체의 래퍼이다. 따라서 SWT 위젯은 "무거운"네이티브 개체 가벼운 Java 래퍼를 씌운듯한 이미지로 "무겁다"라고 말하는 경우가 많다. SWT가 필요로하는 기능을 기본 GUI 라이브러리가없는 경우, SWT는 Swing과 같이 자신의 GUI 코드를 Java로 구현하고있다. SWT는 본질적으로, AWT의 성능과 룩앤필과 Swing의 그것의 중간에 있다고 할 수있다.

Eclipse Foundation에 따르면, SWT와 Swing은 목표 다른 다른 도구이다. SWT의 목적은 다양한 플랫폼의 네이티브 위젯에 액세스할 수있는 공통 API를 제공하기위한 것이다. 설계 목표의 첫 번째는 고성능 네이티브 룩앤필과 플랫폼 통합의 달성이다. 한편 Swing은 고도로 사용자 정의에서 모든 플랫폼에 공통적인 모양과 느낌의 제공에있다.

SWT는 Swing에 비교하면 간단한 도구 키트이며, 표준 개발 관련 기능은별로없는 ^[2] . 따라서 SWT가 Swing에 비해 기능이 적다고 비판하는 사람도있다 ^[3] .

Java의 설계자인 제임스 고스린 은 SWT가 단순 너무 AWT와 같은 이유로 새로운 플랫폼에 이식이 어렵다고 주장했다. 단순 너무 낮은 수준 너무 Win32 GUI API와 결합 너무 있기 때문에 Motif와 OS X Carbon 같은 다른 GUI 툴킷에 대한 대응이 어렵다고했다 ^[2] .

developer.com에서 Mauro Marinillia는 "SWT는 Swing에 비교하면 너무 단순 보인다. Swing 많은 정교한 기능을 가지고 있기 때문에 (예를 들어, 정교한 Swing 클래스 계층, 교환 가능한 모양과 느낌 느낌, Model View Controller 방법 등) "고 주장했다. 이에 대해 Model View Controller 같은 복잡한 문제를 일종의 강제적인 올바른 방법을 적용하는 것은 좋은 것이라고 생각하는 사람도있을 것이다. Marinillia 더 "(SWT와 비교하여) Swing 제공하는 기능은 풍부하고 세련되고 있으며, 추상화 수준이 높은 (즉, 특제 GUI 부품 복잡한 GUI를 구축하는 것이 쉽다)" 라고 계속 "일반적 SWT는 매달리기 쉬운가 복잡한 GUI를 그래서 구축하려고하면 Swing이 더 유연하고 쉬운 결과를 가져온다"고했다 ^{[ 요청 출처 ]} .

SWT는 Swing 기타 높은 수준의 GUI 툴킷이 제공하는 Model View Controller 아키텍처를 구현하고 있지 않지만, Eclipse 프로젝트의 하나로 개발된 JFace 라이브러리를 플랫폼에 의존하지 않는 고급 Model View Controller를 SWT에 구현하고있다. 개발자는 트리 / 테이블 / 목록과 같은 복잡한 SWT 컨트롤에 대해 JFace가 제공하는 유연한 추상 데이터 모델을 사용할 수도 있고, SWT 컨트롤을 직접 사용할 수도있다.

성능 [ 편집 ]

SWT는 "고성능"GUI 툴킷으로, Swing보다 시스템 리소스를 낭비하지 않도록 설계된 ^[4] . SWT와 Swing의 벤치 마크 비교를 몇 가지 실시, SWT가 Swing보다 효율이 좋은 것을 알 수있다. 그러나 벤치 마크에 사용된 어플 리케이션은 그다지 복잡하지 않고 SWT 항상 Swing보다 성능이 좋다 고는 말할 수 없다 ^[5] .

룩앤필 [ 편집 ]

SWT 위젯은 기본 위젯과 같은 룩앤필 을 제공한다. 이와는 대조적으로, Swing의 위젯은 기본 위젯에 가까운 복제이다. 경우에 따라이 차이가보기에도 분명된다. 예를 들어, Mac OS X의 트리 위젯 기능은 트리를 배포할 때 애니메이션을 기본 버튼을 사용자가 초점을 때 애니메이션을한다. Swing에서는 이러한 애니메이션은 행해지지 않는다.

SWT는 네이티브 GUI 코드 간단한 래퍼이기 때문에 (네이티브 API가 호환성을 한) 네이티브 코드가 변경되어도 큰 수정을 필요로한다. OS 업체들은 API의 호환성을 유지하도록 항상 조심하고있다. Swing에서는 사정이 다르다. Swing은 실행중인 응용 프로그램의 룩앤필을 교환할 수 있고 기본 GUI 테마를 에뮬레이트 가능하다. 이 기능은 OS의 GUI가 변경될 때마다 그 변화 (테마 및 기타 룩앤필 업데이트)를 반영해야한다. 반대로 말하면, 네이티브 API가 변경되면, SWT는 수정이 필수가되지만, Swing은 수정할 필요가 없다.

SWT는 "플랫폼과의 긴밀한 통합"을 목표로하고 기본 위젯을 이용한다. developer.com의 Mauro Marinillia에 따르면 "기본 플랫폼과의 긴밀한 통합이 필요한 경우, SWT는 좋은 선택"이라고하고있다 ^[6] . 이러한 조밀한 통합의 이점을 살린 예로 SWT는 Microsoft Windows 의 ActiveX 개체를 래핑 가능하다.

확장성과 다른 Java 코드와 비교 [ 편집 ]

네이티브 코드를 사용하기 위해 SWT 클래스는 모든 위젯 클래스에 상속이 쉽게 허용되지 않는다. 따라서 확장성에 문제가 있다고하는 사람도있다 ^[6] . 이와 Swing 더 쉽게 정의 가능하다. 두 툴킷도 새로운 위젯을 Java 코드만을 사용하여 쓸 수있다.

SWT는 AWT뿐만 아니라 수동으로 개체의 방출을 필요가있다. Swing 및 Java의 메모리 자동 가비지 컬렉션 과는 다르다. close ()하지 않으면 말라 I / O 리소스와 같다. SWT 객체는 "dispose ()"메소드를 사용해 명시적으로 해제해야, C 언어 의 "free"를 닮은 ^[7] . 이것을하지 않으면 메모리 누수 등의 바람직하지 않은 결과를 낸다. 그러나 부모와 자식 관계에있는 Widget은 부모를 dispose ()하면 자식도 dispose ()된다. 이 문제에 대해 "리소스를 명시적으로 해제 필요는 적어도 평균적인 Java 개발자는 개발 시간과 비용에 악영향을 미친다"고 의견도있다. 또한 "이것은 엇갈린이다. Swing 더 자동화된 느린 반면 SWT는보다 세밀한 컨트롤이있는가 복잡하게된다"고하고있다 ^[6] . SWT 수동으로 개체 방출을 필요로하는 것은 기본 개체를 사용하는 것이 주요 원인이다. 즉, 그들 객체는 Java VM의 관리 범위 밖에 있으며, Java VM에서 그들이 풀어 가능 여부를 판단할 수 없다.

플랫폼 지원 [ 편집 ]

GTK + 환경에서 Azureus BitTorrent 클라이언트

SWT는 플랫폼의 GUI 라이브러리에 대한 래퍼이기 때문에 Java가 동작하는 플랫폼 모두에서 작동하는 것은 아니다. 즉, SWT GUI 라이브러리마다 이식이 필요하며, Java가 새로운 플랫폼에 이식되어도 즉시 SWT가 이식되는 것은 아님 (Swing과 AWT는 Java 본체의 일부이지만, SWT는 그렇지 않다). 또한 Windows에서 SWT 제외하고는 비교적 효율이 나쁜 것으로 알려져있다 ^[3] . SWT는 플랫폼마다 다른 네이티브 라이브러리를 사용하고 있기 때문에, 플랫폼 고유의 버그도 SWT는 그대로 존재하고있다.

SWT는 Swing보다 낮은 수준의 세부 사항을 개발자에게 제공한다. 이것은 SWT가 기본 라이브러리에서 제공되는 GUI 기능의 상위 계층이기 때문에이며 기본 GUI 코드를 개발자에게 제시하는 것도 의도적인 것으로 보인다. SWT의 목적은 고급 사용자 인터페이스 디자인 프레임 워크를 제공하는 것이 아니라 가능한 한 많은 플랫폼에서 얇은 사용자 인터페이스 API를 제공하고 그 위에 고급 GUI 응용 프로그램을 구축하기에 충분한 기능을 제공 이다.

SWT의 구현은 플랫폼마다 다르기 때문에 여러 플랫폼으로 응용 프로그램을 배포할 때는 플랫폼마다 SWT (JAR 파일)가 필요하게된다.

SWT는 Java 클래스 라이브러리를 필요 최소한 밖에 사용하지 않기 때문에 기존 JDK (예 : 1.1.8)에서도 동작하는 Java 클래스 라이브러리를 완전히 지원하지 않을 휴대용 기기에서 작동하는 것으로 알려져있다 ^{[ 요청 출처 ]} .

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

• Microsoft Windows 및 32 비트 Java VM
• AIX , FreeBSD , Linux , HPUX :
  • Motif
  • GTK +
• Mac OS : Carbon
  • Cocoa 대응은 개발 중 (Mac OS X 10.5 64 비트 버전 Carbon을 지원하지 않기 때문에)
• QNX Photon
• Pocket PC
• Swing (SWTSwing 경유)

SWT 애플 리케이션 [ 편집 ]

SWT를 사용하는 응용 프로그램으로 다음의 것이있다.

• Vuze
• Eclipse 그 플러그인 군
• GumTree Platform (과학 기술 계산)
• Haystack ( PIM )
• jLibrary ( 컨텐츠 관리 시스템 )
• Panoptes (그래픽 JMX 관리자)
• RSSOwl 피드 수집기
• sancho ( P2P GUI)
• uDig ( 지리 정보 시스템 )
• Xinity BASE

SWT 관계 문서 [ 편집 ]

GUI 툴킷은 Swing보다 오래된 것이기 때문에, SWT 관련 문서 / 도서 Swing에 비해 적은 ^{[ 요청 출처 ]} .

SWT : The Standard Widget Toolkit 은 Eclipse Foundation 추천의 SWT 해설서이다 ^[8] . 이외에도 SWT 관련 서적으로 다음과 같다.

• Rob Warner, Robert Harris (2004 년) The definitive guide to SWT and JFace . Apress. 
• Eric Clayberg and Dan Rubel (2004 년). Eclipse : Building commercial - quality plug - in . Addison - Wesley. 
• Erich Gamma and Kent Beck (2004 년). Contributing to Eclipse . Addison - Wesley. 
• Sherry Shavor et al (2004 년) The Java Developers Guide to Eclipse . Addison - Wesley. 

Web에서 SWT [ 편집 ]

Eclipse 커뮤니티의 최근 움직임으로 SWT (와 JFace)을 Web위한 위젯 툴킷으로 이식하려고하고있다. Eclipse RAP ^[9] (Rich Ajax Platform)은 Qooxdoo AJAX 라이브러리와 SWT API를 조합한 것이다. 다른 Java AJAX 프로젝트 (Echo2와 GWT )뿐만 아니라 SWT API를 사용하면 데스크탑과 같은 형태로 Web 용 응용 프로그램 개발이 가능해진다.

개발 [ 편집 ]

Eclipse가 인기를 얻어 온 결과로, Swing과 SWT를 어떤 의미에서 "통합"하려고하는 활동도있다.

Swing과 SWT의 통합에 대해서는 다음과 같은 몇 가지 방법이 존재하고있다.

• Eclipse 프로젝트는 Swing 위젯 SWT 컨테이너 위젯에 포함 시키려고하고있다. ^{[ 요청 출처 ]}
• SwingWT 는 Swing API의 대체 구현을 제공하려는 프로젝트이다. 그 중 하나 SWT에서 Swing 위젯을 사용할 수 있도록하는 프로젝트가 진행되고있다 ^[10] .
• SWTSwing 는 반대로 Swing에서 SWT API를 제공하는 프로젝트이다. 이것은 SWT가 지원되지 않는 플랫폼에서 Java조차 작동하면 SWT 응용 프로그램을 실행 가능하게된다 ^[11] .

각주 [ 편집 ]

외부 링크 [ 편집 ]

• SWT 공식 사이트
• Eclipse 애플 리케이션
• Eclipse 애플 리케이션, 2 부
• Eclipse 문서 "platform plug - in developer guide"에 SWT에 대한 문서가있다.
• SWT Javadoc API eclipse.org