JavaScript Closures


JavaScript variables can belong to the local or global scope.

Private variables can be made possible with closures.


Global Variables

A function can access all variables defined inside the function, like this:

Example

function myFunction() {
    var a = 4;
    return a * a;
}

Try it Yourself »

But a function can also access variables defined outside the function, like this:

Example

var a = 4;
function myFunction() {
    return a * a;
}

Try it Yourself »

In the last example, a is a global variable.

In a web page, global variables belong to the window object.

Global variables can be used (and changed) by all scripts in the page (and in the window).

In the first example, a is a local variable.

A local variable can only be used inside the function where it is defined. It is hidden from other functions and other scripting code.

Global and local variables with the same name are different variables. Modifying one, does not modify the other.

NoteVariables created without the keyword var, are always global, even if they are created inside a function.

Variable Lifetime

Global variables live as long as your application (your window / your web page) lives.

Local variables have short lives. They are created when the function is invoked, and deleted when the function is finished.


A Counter Dilemma

Suppose you want to use a variable for counting something, and you want this counter to be available to all functions.

You could use a global variable, and a function to increase the counter:

Example

var counter = 0;

function add() {
    counter += 1;
}

add();
add();
add();

// the counter is now equal to 3

Try it Yourself »

The counter should only be changed by the add() function.

The problem is, that any script on the page can change the counter, without calling add().

If I declare the counter inside the function, nobody will be able to change it without calling add():

Example

function add() {
    var counter = 0;
    counter += 1;
}

add();
add();
add();

// the counter should now be 3, but it does not work !

Try it Yourself »

It did not work! Every time I call the add() function, the counter is set to 1.

A JavaScript inner function can solve this.


JavaScript Nested Functions

All functions have access to the global scope.  

In fact, in JavaScript, all functions have access to the scope "above" them.

JavaScript supports nested functions. Nested functions have access to the scope "above" them.

In this example, the inner function plus() has access to the counter variable in the parent function:

Example

function add() {
    var counter = 0;
    function plus() {counter += 1;}
    plus();    
    return counter; 
}

Try it Yourself »

This could have solved the counter dilemma, if we could reach the plus() function from the outside.

We also need to find a way to execute counter = 0 only once.

We need a closure.


JavaScript Closures

Remember self-invoking functions? What does this function do?

Example

var add = (function () {
    var counter = 0;
    return function () {return counter += 1;}
})();

add();
add();
add();

// the counter is now 3

Try it Yourself »

Example Explained

The variable add is assigned the return value of a self-invoking function.

The self-invoking function only runs once. It sets the counter to zero (0), and returns a function expression.

This way add becomes a function. The "wonderful" part is that it can access the counter in the parent scope.

This is called a JavaScript closure. It makes it possible for a function to have "private" variables.

The counter is protected by the scope of the anonymous function, and can only be changed using the add function.

NoteA closure is a function having access to the parent scope, even after the parent function has closed.




source - http://www.w3schools.com/js/js_function_closures.asp








자바스크립트에는 클로저( Closure)라는 개념이 있습니다.(랭귀지에 따라 클로저가 있는 언어도 있고 그렇지 않은 언어도 있습니다.) 오랫동안 잘 이해하고 있다가 어느정도 이해는 되었지만 아직 몸에 익지 않았다가 최근에 두번이나 클로저로 해결할 문제를 누가 물어와서 정리를 합니다.

클로저는 자신의 범위(Scope) 밖에 있는 변수들에 접근할 수 있는 함수를 의미합니다.

사실 이 말만 가지고는 잘 감이 오지 않고 보통 자바스크립트내에서는 함수의 생명주기는 끝이났지만 함수내의 변수를 내부함수가 참조하고 있기 때문에 유지되어 접근할수 있는 함수를 클로저라고 합니다.

1
2
3
4
<input type="button" id="btn1"/>
<input type="button" id="btn2"/>
<input type="button" id="btn3"/>
<input type="button" id="btn4"/>

위와 같이 버튼이 4개 있고 각 버튼을 클릭했을때 각 버튼당 1,2,3,4가 찍히게 하고 싶다고 하겠습니다. 당연히 가장 쉬운 방법은 각 버튼에 인라인으로 onclick="alert('1')" 처럼 각 버튼당 파라미터를 주는 것이 쉽겠지만 이럴 경우 요즘 일반적인 구조와 동작을 불리하는 Unobtrusive Javascript에도 맞지 않고 유지보수에도 별로 좋지 않습니다. 

일반적으로 사람들이 위와같은 구현을 하기 위해서 가장 먼저 시도하는 코드는 아래와 같을 것입니다.

1
2
3
4
5
6
7
window.onload = function() {
    for(var i=1; i < 5; i++ ) {
        document.getElementById("btn" + i).addEventListener("click", function() {
            alert(i);
        }, false);
    }
}

모두는 아니겠지만 보통 위와같은 코드를 시도하리라고 생각하고 정상적으로 동작할 것을 기대하지만 위 코드는 제대로 동작하지 않습니다. for문을 돌면서 각 버튼에 click이벤트리스너를 등록하고 각 루프에서의 i를 alert으로 보여줍니다. 이렇게 할경우 의도한 것은 1,2,3,4의 alert()을 의도한것이지만 alert()에 넘겨준 파라미터는 i의 값이 아닌 i의 참조이기 때문에 실제 버튼을 클릭하면 모든 버튼을 클릭할 때 i의 최종값이 5가 모두 찍혀버립니다. 



이 상황이 클로저가 적합한 상황인데 클로저를 사용하는 것은 이해만 하면 그렇게 어렵지 않습니다.

1
2
3
4
5
6
7
8
9
window.onload = function() {
    for(var i=1; i < 5; i++ ) {
        (function(m) {
            document.getElementById("btn" + m).addEventListener("click", function() {
                alert(m);
            }, false);
        })(i);
    }
}

위와 같이 작성합니다. for문안에 실행할 구문을 익명함수( (function() {})와 같은 형태)로 만들고는 i를 파라미터로 넘기면서 실행시켜버립니다.(익명함수에 (i)를 붙혀서 바로 실행시켰습니다.) 이렇게 하면 익명함수안의 내부변수인 m에 i의 값이 할당되어 버리고 구조상은 실행뒤에 소멸되어야 하지만 클로저로 인하여 각 값으로 할당된 멤버변수를 각 이벤트리스너에서 그대로 사용할 수 있게 됩니다. 위 코드로 실행하면 각 버튼을 클릭시 1,2,3,4의 원하던 값이 찍히게 됩니다.


덧) 그냥 예제코드이기 때문에 표준인 addEventListener만을 사용했습니다. IE에서 돌려보실 계획이라면 attachEvent를 사용하셔야 합니다.

덧2) 제가 클로저의 개념을 아주 명확히 파악하지 못한관계로 설명이 명확치 않았습니다. 위 소스에 대한 명확한 설명은 아래 댓글에 odyss님이 해주셨으므로 참고해주시기 바랍니다. 공부를 더 열심해야겠군요. ㅠㅠ


댓글

약간 보충설명을 하자면,
첫번째 예제는 클로저의 생성으로 인한 부작용을 보여줍니다.
원래 의도는 각 버튼마다 alert시에 1,2,3,4를 결과로 보여주려는 의도이나 이벤트 핸들러 함수의 i값이 바깥쪽 변수인 i값에 대한 참조를 유지하고 있어, 즉 클로저의 생성으로 인해 최종값인 5를 모두 가리키게 되는 예제입니다.
사실 두번째 예제는 클로저의 부작용을 막기위한 처리로 제시한 예제인데, 이 예제도 클로저가 생성되긴 합니다만 익명함수의 인자로 값을 넘겨버림으로써 바깥쪽 변수인 i에 대한 변수스코프를 끊어버리고, 이벤트 핸들러에서는 익명함수의 인자값에 접근함으로써 의도한 대로 처리가 되게 됩니다.
괄호로 둘러싼 함수표현식 안에서는 바깥쪽 변수에 접근하지 못한다는 것을 여기서 아실 수 있습니다.


댓글에 약간의 태클을 걸자면, 위 예제에서 괄호로 둘러싸인 함수가 외부 변수에 접근할 수 있습니다;

함수가 특정 오브젝트의 실행컨텍스트로 실행될 때..그러니까 메소드로 실행될 때 메소드 내부에 있는 함수의 컨텍스트는 글로벌이 된다는 것을 혼동하신거 같네요...


출처 - http://blog.outsider.ne.kr/506






클로져(Closure) is what?

Scope에 제약을 받지 않는 변수들을 포함하고 있는 코드블록이다.

이러한 변수들은 코드블럭이나 글로벌 컨텍스트에서 정의되지 않고 코드 블록이 정의된 환경에서 정의된다.

"클로져"라는 명칭은 실행할 코드블록(자유 변수의 관점에서, 변수 레퍼런스와 관련하여 폐쇄적이지 않는) 과 자유변수들에 대한 바인딩을 제공하는 평가 환경(범위)의 결합에서 탄생한 것이다.

사실 저런 이야기 매우 어렵습니다.   그래서 좀더 어렵고 혼돈되게 책에 있는 내용을 인용합니다.

From javascript definitive guide 5th


This combination of code and scope is known as a closure (…). All 
Javascript functions are closures.

When a nested function is exported outside the scope in which it is defined

When a nested function is used in this way, it is often explicitly called a closure


이 코드와 
스코프의 조합은 클로져 알려져 있습니다
자바스크립트 모든 함수들은 
클로져입니다.

중첩합수가 함수 정의하는 것을 스코프 밖에서 이루어질 때 입니다.

중첩함수를 이 방식으로 사용할 때 그것은 자주 명백하게 클로져 불러지고 있습니다.


2008.10.14 추가내용

When a nested function is exported outside the scope in which it is defined

"중첩된 함수가 그 함수가 정의된 유효 범위의 바깥으로 익스포트(export)될 때다."

 (한글 번역서p.191)<낭망백수님 의견>

매우 혼동스러워 집니다.  그래서 클로져라는게 도대체 무엇인지 개념적으로 A = B이다. 라고 답을 낸 다는 것은 너무 단편적인 결론을 요구하는 것이기 때문에 클로져의 개념을 이해하는 것을 목적으로 둡니다..

좀더 빠른 이해를 돕기 위해서 그림으로 표현해봅니다.

사용자 삽입 이미지

outerFn()은 우리가 알고 있는 function입니다.   function을 수행하게 되면 var을 통해서 function 내에서만 사용되거나 설정되는 variable을 가집니다. 이는 달리 말해 function scope에서만 참조되는 변수이지만 경우에 따라 클로져(closure)에 의해서 참조가 가능해진다는 것입니다.

outerFn 내의 var closure='is Closure.'; 는 메모리에 적재를 하게 되고 이는 outerFn이 수행될때 해당 메모리를 참조하게 되고 수행이 종료되고 참조가 없어지면 자동으로 GC(가비지 컬렉션)이 일어나 메모리에서 해제되게 됩니다.

하지만 var closure = 'is Closure.'; 를 어디선가 참조를 하고 있다면 아니 그전에 다른곳에서 참조가 발생할 때 바로 클로져가 생성되면서 클로저를 통해서 해당 variable를 참조하게 됩니다.

사용자 삽입 이미지
위에서 볼때 func에는 outerFn에 의해서 반환된 function을 가지고 있습니다.  이 function은 outerFn이 가지고 있는 내부 variable를 참조하고 있습니다.  이때 outerFn이 갖은 variable을 외부에서 참조하려고 하니 쉽게 private를 public으로 참조하려고 하니 과연 되지 않아야 하지만 우리의 javascript의 유연함은 이뤄 말할 수 없을 만큼의 기능을 가지고 있습니다.

아무튼 그렇게 클로져는 이런 상태에서 private를 참조하려고 시도할 때 발상하여 해당 참조를 해야하는 function의 즉 outerFn의 코드블럭을 클로져를 통해서 참조할 수 있게 됩니다.  클로져 자체가 코드블럭이라 해도 과언이 아니겠습니다.

위의 그림에서는 클로져가 발생했고 이는 GC에 의해서 메모리 해제가 되지 않습니다.  즉 func 이 계속적으로 클로져를 통하여 var closure = 'is Closure.'; 를 계속 참조하고 있기 때문입니다.  그래서 우리는 강제적으로 클로저를 해제할 수 있는 상태를 만들어 주어야 합니다.

사용자 삽입 이미지

'조만간 Gabage Collection in Javascript 에 대한 글을 포스팅하려 준비중입니다.  그때 좀더 자세한 사항을 포스팅하도록 하겠습니다. 약속'

var func = outerFn(); 을 하고.
     func('function'); 을 통해서 원하는 결과 값을 얻었다면 var func = null; 을 통해서 클로져를 통한 참조 point를 null 시켜주게 되면 주기적으로 GC에 의해서 메모리에서 반환되게 됩니다.


결론
사용자 삽입 이미지
  Scope에 제약을 받지 않는 변수들을 포함하고 있는 코드블록이다. 
그리고 이는 Javascript에서 메모리 누수를 발생하는 요인중에 하나이다.



참조 : 
 1, 
http://www.ibm.com/developerworks/kr/library/j-jtp04247.html 
 2. 
http://en.wikipedia.org/wiki/Closure_%28computer_science%29 


출처 - 




Posted by linuxism
,


[각 패턴의 특징]
  • 프레젠테이션 티어(상단)
    • Intercepting Filter 패턴
      request를 직접 처리 하기 전에 가로채서, 선언적 방식으로 중복되는 전후처리를 한다.
    • Front Controller 패턴
      모든 request를 한 곳으로 보낸다.
    • Context Object 패턴
      특정 프로토콜에 한정되는 내용이나 불필요한 데이터를 포함하는 원래 객체 대신, 필요한 데이터만 Context Object로 만들어서 넘김
    • Application Controller 패턴
      request를 처리하는 액션 관리와 뷰 관리 컴포넌트를 중앙 집중화 한다.
    • View Helper 패턴
      View를 만드는 과정에서 제어 로직, 데이터 접근 로직, 포맷 로직을 분리한다. (예를들면 JSP 에서 스크립틀릿 대신 JSTL, Custom Tag 등을 헬퍼로 사용)
    • Composite View 패턴
      View를 만들 때 레이아웃을 조합한다. (예를들면 Header/Footer를 일관적으로 붙이는 것)
    • Service to Worker 패턴
      제어권이 뷰로 넘어가기 전에 프레젠테이션 모델을 가져오도록 제어 로직과 요청 핸들링을 중앙 집중화한다. 뷰는 프레젠테이션 모델에 근거해서 동적 응답을 생성한다. (비즈니스 로직 결과에 따라 View가 선택됨)
    • Dispatcher View 패턴
      정적 뷰이거나 동적 내용이 거의 없는 뷰, 간단한 애플리케이션을 만들 때만 제한적인 용도로 사용. (정적인 Business Helper 이용)
  • 비즈니스 티어(중간)
    • Business Delegate 패턴
      비즈니스 서비스 접근을 캡슐화하는 패턴
    • Service Locator 패턴
      서비스와 컴포넌트 검색을 쉽게 하는 패턴
    • Session Facade 패턴
      비즈니스 티어 컴포넌트를 캡슐화하고, 원격 클라이언트에서 접근할 수 있는 서비스를 제공하는 패턴
    • Application Service 패턴
      여러 컴포넌트에 분산되어 있는 관련된 비즈니스 로직 오퍼레이션을 조합하여 하나의 인터페이스로 서비스
    • Business Object 패턴
      객체 모델을 사용하여 비즈니스 데이터, 비즈니스 로직, 퍼시스턴스 로직을 분리
    • Composite Entity 패턴
      로컬 엔티티 빈과 POJO 패턴이라고 알려져있음. 데이터를 전송하기위한 객체에 대한 패턴
    • Transfer Object 패턴
      일명 Value Object(VO, TO) 패턴이라 알려져 있음. 데이터를 전송하기 위한 객체에 대한 패턴
    • Transfer Object Assembler 패턴
      하나의 Transfer Object로 모든 데이터를 처리할 수 없으므로, 여러 Transfer Object를 조합하거나 변형한 객체를 생성하여 사용하는 패턴
    • Value List Handler 패턴
      데이터 조회를 처리하고, 결과를 임시 저장하며, 결과 집합을 검색하여 필요한 항목을 선택하는 역할을 수행

  • 인테그레이션 티어(하단)
    • Data Access Object 패턴
      일명 DAO라고 알려져있음. DB 접근을 전담하는 클래스를 추상화하고 캡슐화함
    • Service Activator 패턴
      비동기적 호출을 처리하기 위한 패턴
    • Domain Store 패턴
      Business Object Model 에서 영속성을 분리하고자 할 때.
    • Web Service Broker 패턴
      하나 이상의 서비스를 XML 및 웹 프로토콜로 노출함. RPC방식이나 메시징 인터페이스
위쪽은 화면에 가깝고 아래쪽은 DB에 가깝다

[J2EE 리펙토링]
  1. 프레젠테이션 티어 리팩토링
    • 컨트롤러 도입
    • 동기화 토큰 도입
    • 각기 다른 로직을 지역화 하기 (응집도와 결합도)
    • 프레젠테이션 티어에 한정된 세부 구현을 비즈니스 티어로부터 숨기기
    • 뷰 안에 있는 포맷 변환 코드 제거하기
    • 클라이언트로부터 리소스 숨기기
  2. 비즈니스 티어와 통합 티어 리팩토링
    • 세션 빈으로 엔티티 빈 감싸기
    • Business Delegate 도입
    • 세션 빈 병합하기
    • 엔티티 빈 상호 통신 줄이기
    • 비즈니스 로직을 세션 빈으로 옮기기
  3. 일반 리팩토링
    • 데이터 접근 코드 분리(dao)
    • 티어에 따른 아키텍처 리팩토링
    • 커넥션 풀 이용하기

참고


출처 - http://kaylis.tistory.com/61



'Design Pattern > Common' 카테고리의 다른 글

디자인 패턴(책)  (0) 2013.04.16
Programming paradigms  (0) 2013.01.01
DSL(domain-specific language)  (0) 2013.01.01
Rich Domain Model  (0) 2012.11.05
java - 디자인 패턴 - 팩토리 패턴  (0) 2012.08.02
Posted by linuxism
,


he Java Platform, Enterprise Edition or Java EE (formerly known as Java 2 Platform, Enterprise Edition or J2EE) has undergone several changes since 1.0 as well as numerous additions of new specifications.

Contents

  [hide

[edit]JPE (May 1998)

Announcement of the JPE (Java Professional Edition) project at Sun.

[edit]J2EE 1.2 (December 12, 1999)

List of J2EE 1.2 specifications Developer's Guide.
TechnologyVersion
JDBC Standard Extension API2.0
Java Naming and Directory Interface Specification (JNDI)1.2
RMI-IIOP1.0
Java Servlet2.2
JavaServer Pages (JSP)1.1
Enterprise JavaBeans (EJB)1.1
Java Message Service API (JMS)1.0
Java Transaction API (JTA)1.0
JavaMail API1.1
JavaBeans Activation Framework (JAF)1.0

[edit]J2EE 1.3 (September 24, 2001)

List of J2EE 1.3 specifications developed under JSR 58 Tutorial
TechnologyVersion
JDBC Extension2.0
Java API for XML Processing (JAXP)1.1
Java Servlet2.3
JavaServer Pages (JSP)1.2
JavaServer Pages Standard Tag Library (JSTL)1.0
Enterprise JavaBeans (EJB)2.0
J2EE Connector Architecture1.0
Java Message Service API (JMS)1.0
Java Transaction API (JTA)1.0
JavaMail API1.2
JavaBeans Activation Framework (JAF)1.0
Java Authentication and Authorization Service (JAAS)1.0

[edit]J2EE 1.4 (November 11, 2003)

List of J2EE 1.4 specifications developed under JSR 151 Tutorial
TechnologyVersionJSR
Web Services Technologies:
Web Services for J2EE 1.11.0
Java API for XML Processing (JAXP)1.2
Java API for XML-based RPC (JAX-RPC)1.1
Java API for XML Registries (JAXR)1.0
Web Application Technologies:
Java Servlet2.4JSR154
JavaServer Pages (JSP)2.0JSR152
JavaServer Pages Standard Tag Library (JSTL)1.1JSR52
JavaServer Faces (JSF)1.1JSR127
Enterprise Application Technologies:
Enterprise JavaBeans (EJB)2.1
J2EE Connector Architecture1.5
Java Message Service API (JMS)1.1
Java Transaction API (JTA)1.0
JavaMail API1.3
JavaBeans Activation Framework (JAF)1.0
Management and Security Technologies:
Java Authorization Service Provider Contract for Containers (JACC)1.0
Java Management Extensions (JMX)1.2
Enterprise Edition Management API1.0
Enterprise Edition Deployment API1.1

[edit]Java EE 5 (May 11, 2006)

List of JEE 5 specifications developed under JSR244 Tutorial
TechnologyVersionJSR
Web Services Technologies:
Web Services1.2JSR109
Java API for XML-Based Web Services (JAX-WS)2.0JSR224
Java Architecture for XML Binding (JAXB)2.0JSR222
Web Service Metadata for the Java Platform2.0JSR181
Java API for XML-Based RPC (JAX-RPC)1.1JSR101
Java API for XML Registries (JAXR)1.0JSR93
SOAP with Attachments API for Java (SAAJ)1.3JSR67
Streaming API for XML (StAX)1.0JSR173
Web Application Technologies:
Java Servlet2.5JSR154
JavaServer Faces (JSF)1.2JSR252
JavaServer Pages (JSP)2.1JSR245
JavaServer Pages Standard Tag Library (JSTL)1.2JSR52
Debugging Support for Other Languages1.0JSR45
Enterprise Application Technologies:
Enterprise JavaBeans (EJB)3.0JSR220
Java Persistence API (JPA)1.0JSR220
Jave EE Connector Architecture1.5JSR112
Common Annotations for the Java Platform1.0JSR250
Java Message Service API (JMS)1.1JSR914
Java Transaction API (JTA)1.1JSR907
JavaMail API1.4JSR919
JavaBeans Activation Framework (JAF)1.1JSR925
Management and Security Technologies:
Java Authorization Service Provider Contract for Containers (JACC)1.1JSR115
J2EE Application Deployment1.2JSR88
J2EE Management1.1JSR77

[edit]Java EE 6 (Dec 10, 2009)

Java EE 6 introduced the concept of profile, which represents a configuration of the platform suited to a particular class of applications. The Web Profile offers a complete stack, with technologies addressing presentation and state management (JavaServer Faces, JavaServer Pages), core web container functionality (Servlet), business logic (Enterprise JavaBeans Lite), transactions (Java Transaction API), persistence (Java Persistence API) and more.

List of JEE 6 specifications developed under JSR 316 Tutorial
TechnologyVersionJSRIncluded in Web Profile
Web Services Technologies:
Java API for RESTful Web Services (JAX-RS)1.1JSR311
Web Services1.3JSR109
Java API for XML-Based Web Services (JAX-WS)2.2JSR224
Java Architecture for XML Binding (JAXB)2.2JSR222
Web Services Metadata for the Java Platform2.1JSR181
Java API for XML-based RPC (JAX-RPC)1.1JSR101
Java APIs for XML Messaging (JAXM)1.3JSR67
Java API for XML Registries (JAXR)1.0JSR93
Web Application Technologies:
Java Servlet3.0JSR315Green tick
JavaServer Faces (JSF)2.0JSR314Green tick
JavaServer Pages (JSP)2.2JSR245Green tick
Expression Language (EL)2.2JSR245Green tick
JavaServer Pages Standard Tag Library (JSTL)1.2JSR52Green tick
Debugging Support for Other Languages1.0JSR45Green tick
Enterprise Application Technologies:
Enterprise JavaBeans (EJB)3.1JSR318Green tick Lite
Java Persistence API (JPA)2.0JSR317Green tick
Contexts and Dependency Injection for Java1.0JSR299Green tick
Dependency Injection for Java1.0JSR330Green tick
Bean Validation1.0JSR303Green tick
Managed Beans1.0JSR316Green tick
Interceptors1.1JSR318Green tick
Java EE Connector Architecture1.6JSR322
Common Annotations for the Java Platform1.1JSR250Green tick
Java Message Service API (JMS)1.1JSR914
Java Transaction API (JTA)1.1JSR907Green tick
JavaMail API1.4JSR919
Management and Security Technologies:
Java Authentication Service Provider Interface for Containers (JASPIC)1.0JSR196
Java Authorization Service Provider Contract for Containers (JACC)1.4JSR115
Java EE Application Deployment1.2JSR88
J2EE Management1.1JSR77

Java EE 6 was first going to be developed under JSR 313 but was canceled. Java EE 6 was developed under JSR 316 and released on December 10, 2009.

The development was plagued with controversy, although passed by 14 yes votes, 1 no vote (Apache), and 1 abstention (Borland), members aired concerns relating to the licensing terms applied by Sun Microsystems.[1]

IBM's "yes" vote was caveated with:

IBM’s vote is based on the technical merits of this JSR and is not a vote on the licensing terms. IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage. We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM’s preferred licensing model.

Intel's was caveated with:

The Spec Lead has told us there are no “field of use restrictions” on implementations for this particular JSR. The Apache open letter about Java SE [2] claimed that a confidential license for a required JCP test suite restricts how Independent Implementations of that JCP spec can be used. Licenses to test for JCP compatibility must not be used to limit or restrict competing, compatible implementations; licenses containing such limitations do not meet the requirements of the JSPA, the agreement under which the JCP operates. For every JCP ballot, we will ask the Spec Lead whether such restrictions exist in their license.

Red Hat commented

The spec lead of the EE6 specification has confirmed that the EE6 TCK would contain no “field of use restrictions”, as originally raised by Apache with regard to another JSR (i.e. the SE TCK licensing). That is a good thing.
However, in the absence of an explicit JSPA rule that would forbid such field-of-use restrictions, we will remain worried that a similar issue might resurface anytime, for any JSR.
Consequently, in the future, for any submitted JSR (by SUNW or not), we will specifically expect the spec lead to provide clear information on that aspect and take the answer in account when casting our vote.

Apache voted NO with the following comment:

The Apache Software Foundation’s vote is based on the point of view that this spec lead - Sun - is in violation of the JSPA[2]
and therefore shouldn’t be allowed to start another JSR until the above matter is resolved.
This vote is not a comment on the technical merits of the JSR. If not for the issue of the spec lead, the ASF would have otherwise voted “yes”.

[edit]References

[edit]External links




자바 플랫폼, 엔터프라이즈 에디션 또는 Java EE (이전에는 J2EE라 불리었음) 는 버전 1.0 부터 수많은 새로운 사양의 추가로 인해 여러 번의 개정이 있었다.

목차

  [숨기기

[편집]JPE (1998년 5월)

JPE 프로젝트 선언

[편집]J2EE 1.2 (1999년 10월 12일)

사양 다운로드

사양 리스트 :

[편집]J2EE 1.3 (2001년 9월 24일)

JSR 58 기준으로 개발

사양 리스트 :

[편집]J2EE 1.4 (2003년 11월 11일)

JSR 151 기준으로 개발

사양 리스트:

[편집]Java EE 5 (2006년 5월 11일)

JSR 244 기준으로 개발

사양 리스트 :

  • JDBC (Java DataBase Connectivity, JDBC) , 버전 3.0
  • JNDI (Java Naming and Directory Interface, JNDI), 버전 1.2
  • 자바 메시지 서비스 (Java Message Service, JMS), 버전 1.1
  • 자바 트랜잭션 API (Java Transaction API, JTA), 버전 1.1
  • 자바 트랜잭션 서비스 (Java Transaction Service, JTS), 버전 1.0
  • 자바 메일 (JavaMail) , 버전 1.4
  • JAF (JavaBeans Activation Framework), 버전 1.1
  • JCA (J2EE Connector Architecture, JCA), 버전 1.5
  • JAXP (Java API for XML Processing, JAXP), 버전 1.3
  • JAAS (Java Authentication and Authorization Service, JAAS), 버전 1.0
  • JACC (Java Authorization Service Provider Contract for Containers, JACC), 버전 1.1
  • Java EE용 웹서비스, 버전 1.2
  • JAX-RPC (Java API for XML-based RPC, JAX-RPC), 버전 1.1
  • JAXR (Java API for XML Registries, JAXR), 버전 1.0
  • JMX (Java Management eXtensions, JMX), 버전 1.2
  • Java Platform, Enterprise Edition Management Specification, 버전 1.1
  • Java Platform, Enterprise Edition Deployment Specification, 버전 1.1
  • JAX-WS (Java API for XML-based Web Services, JAX-WS), 버전 2.0
  • JAXB (Java Architecture for XML Binding, JAXB), 버전 2.0
  • SAAJ (SOAP with Attachments API for Java, SAAJ), 버전 1.3
  • Web Services Metadata for the Java Platform, 버전 2.0
  • StAX (Streaming API for XML, StAX), 버전 1.0

[편집]Java EE 6 (2008년)

JSR 313 기준으로 개발중이었으나 취소되었다. 현재 JSR 316 기반하에 2008년 발표를 목표로 개발중이다.

새로이 추가되는 사양

  • JSR-196 Java Authentication SPI for Containers
  • JSR-236 Timer for Application Servers
  • JSR-237 Work Manager for Application Servers
  • JSR-299 Web Beans
  • JSR-311 JAX-RS: Java API for RESTful Web Services

사양 업그레이드 예정

[편집]같이 보기




Posted by linuxism
,