1. static 키워드의 특징.
1. 멤버 변수와 메서드에 사용할 수 있다.
2. new 연산자를 이용하여 객체를 생성하지 않고도 접근이 가능하게 해준다.
3. 2번의 이유로 staitc 으로 정의를 하면 객체가 생성되기 전 미리 메모리에 로딩되어진다.
4. 클래스명으로 접근이 가능하다.
5. 메서드 내에서 즉, 지역 변수에는 static 변수를 사용할 수 없다.
6. static 메서드 내에서는 this 를 사용 할수 없다.
7. 6번의 이유로 this 는 객체 자신을 가리키는데 staitc 은 객체가 생성 되기 전 메모리에 먼저 로딩이 되어지기 때문이다.
2. static 키워드의 사용시 고려사항
1. 클래스를 설계할 때, 멤버변수 중 모든 인스턴스(객체)에 공통적으로 사용해야하는 것에 static를 붙인다.
2. static이 붙은 멤버변수는 인스턴스(객체)를 생성하지 않아도 사용할 수 있다.
3. static이 붙은 메서드에서는 인스턴스(객체) 변수를 사용 할 수 없다. (1. static 키워드의 특징 중 7번의 이유.)
4. 메서드 내에서 인스턴스 변수를 사용하지 않는다면, static을 붙이는 것을 고려한다.
5. 클래스의 멤버변수 중 모든 인스턴스에 공통된 값을 유지해야 하는 것이 있다면, static 을 붙이는 것을 고려한다.
- 2011/08/09 17:18
- laydios.egloos.com/2823680
- 덧글수 : 0
- 2011/06/29 17:59
- laydios.egloos.com/2798626
- 덧글수 : 0
final 키워드는 주로 class 나 method 의 재정의(overriding)를 막기 위하여 사용되며, 맴버변수나 로컬변수 등에서 변수 초기화 이후 바꿀수 없는 변수를 만드는 용도로도 사용을 합니다.
참고 :
위키피디아(영문) final (java) : http://en.wikipedia.org/wiki/Final_(Java)
위키피디아(한글) 자바와 C++의 비교 : http://ko.wikipedia.org/wiki/%EC%9E%90%EB%B0%94%EC%99%80_C%2B%2B%EC%9D%98_%EB%B9%84%EA%B5%90
C++ 의 const 와 비슷하기는 합니다만, C++ 에서의 const 는 개념적으로 '읽기 전용' 을 명시하며, java 의 final 은 변수가 다시 할당될 수 없음을 명시 합니다. (자바와 C++의 비교 - 언어의 특징의 문법 부분 참고)
1. class 의 final 사용.
class 가 상속되지 않도록 하기 위하여 선언합니다.
예)
final class SampleClass {
}
2. method 의 final 선언
상속 관계에 있는 상위 class 와 하위 class 에서 상위 class 에 있는 method 가 재정의(overriding) 되지 않도록 하기 위하여 정의 합니다.
예)
calss SampleClass {
public final sampleMethod() {
}
}
3. variable(변수) 의 final 선언
초기 값이 변경되면 안되거나 변경할 경우 예외가 발생할수 있는 경우 사용하며, 문서화의 한 형태로 가독성을 높이고 수정이 용이 하다는 이점이 있습니다.
final int sampleVariable = 1;
final String sampleVariable = "aaa";
등등
- 2011/06/24 17:02
- laydios.egloos.com/2795675
- 덧글수 : 0
nmap -sT -O localhost
옵션설명 :
-sS/sT/sA/sW/sM : TCP SYN/Connect()/ACK/Window/Maimon scans
-O : Enable OS detection
port 의 상태를 한눈에 확인 하기를 원한다면, 아래의 방법으로 확인이 가능하다.
netstat -anp
옵션설명 :
-a, --all, --listening display all sockets (default: connected)
-n, --numeric don't resolve names
-p, --programs display PID/Program name for sockets
다른 옵션의 사용법은 man, 또는 --help option 로 확인이 가능하다.
- 2011/06/13 18:35
- laydios.egloos.com/2789441
- 덧글수 : 0
pom.xml 설정시 dependency 설정에서 scorp 종류와 설명.
compile : 컴파일 할때 필요. 테스트 및 런타임에도 클래스 패스에 포함 된다. scorp 을 설정 하지 않는 경우 기본값이다.
runtime : 런타임에 필요. JDBC 드라이버 등이 예가 된다. 컴파일 시에는 필요하지 않지만, 실행 시에 필요한 경우.
provided : 컴파일 시에 필요하지만, 실제 런타임 때에는 컨테이너 같은 것에서 제공되는 모듈. servlet, jsp api 등이 이에 해당. 배포시 제외된다.
test : 테스트 코드를 컴파일 할때 필요. 테스트시 클래스 패스에 포함되며, 배포시 제외된다.
예시)
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet.jsp</groupId>
<artifactId>jsp-api</artifactId>
<version>2.1</version>
<scope>provided</scope>
</dependency>
- 2011/05/27 17:01
- laydios.egloos.com/2780054
- 덧글수 : 0
이는 원 저작권자와 해당 오픈소스SW의 정보를 표시하기 위한 부분이며, 수정 및 삭제할 수 없도록 하기 위하여 오픈소스SW 라이선스들의 공통적인 준수사항 중 하나로 ‘저작권 관련 문구 유지’사항이 존재 합니다.
이는 오픈소스SW 원 저작권자의 저작인격권을 보호하기 위한 사항으로, 소스코드에 오픈소스SW의 명칭, SW의 버전정보, 개발자의 이름, 개발자의 연락처 등 성명표시권과 동일성유지권을 보장하기 위한 문구에 대해 수정하거나 삭제가 불가능함을 언급하고 있습니다.
오픈소스SW의 소스코드도 현재 저작물의 하나로써 저작권법으로 보호를 받고 있기 때문에 저작권 관련 문구를 수정하거나 삭제하여 이를 침해할 경우 법적 책임을 지게 될 수도 있습니다.
따라서, 제3자가 귀하의 라이브러리를 사용할 경우 저작권 관련 문구를 통해 귀하의 라이브러리를 사용한다는 것을 확인할 수 있습니다.
2. GNU LGPL(Lesser General Public License), MPL(Mozilla Public License)
LGPL의 요구사항만 잘 준수한다면 LGPL 라이브러리에 응용프로그램을 정적 혹은 동적으로 링크시킨다고 해도 응용프로그램의 소스코드를 공개할 필요가 없습니다.
단, LGPL 라이브러리의 소스코드를 수정하였을 때에는 2차적 파생 저작물에 해당하므로 라이브러리의 소스코드를 제공해야 합니다.
또한, LGPL 전문에 ”라이브러리의 복제본을 무상이나 유상으로 배포할 경우에, 당신은 우리가 당신에게 부여한 모든 권리를 수취인에게도 그대로 부여해야 한다.“라는 내용으로 요구 조건만 준수한다면 상업적인 유상 배포도 허용하고 있습니다.
또한, MPL은 최초 개발자와 기여자에 대한 부여사항으로 제2조의 1항과 2항에 각각 “제조, 사용, 실행, 판매 및 판매를 위한 청약, 혹은 기타 방식으로 처분하는 행위”를 허용한다고 명시하여 상업적인 배포를 허가하고 있습니다.
또한, "함께 결합되는 저작물에 대해서는 GNU GPL3에 의해 구속된다"라고명시되어 있습니다.
AGPL을 따르는 오픈소스SW를 링크하여 사용한 경우, 즉 소스코드를 라이브러리 형태로 포함만 하였을 지라도 오픈소스SW가 결합된 Linux 드라이버 또한 GPL의 전염성(GPL과 동일한 소스코드 공개 의무)에 따라 AGPL 저작물이 됩니다.
또한, Linux용 드라이버를 호출하여 사용하는 서비스 프로그램의 경우, AGPL 저작물인 Linux 드라이버를 사용하고 있기 때문에(서비스 프로그램에 Linux 드라이버가 포함된다면) 결합된 프로그램 전체 역시 AGPL이 적용 됩니다.
라이선스의 양립성 문제는 주로 GPL 조건의 엄격성 때문에 나타나게 되며 GPL과 MPL의 양립성 문제 또한 동일한 이유로 나타나는 문제입니다.
이러한 문제는 오픈소스SW 진영에서도 심각하게 받아들여지고 있으며 이를 해결하기 위하여 여러 가지 방법들이 제시되고 있습니다.
이러한 노력의 일환으로 각 라이선스의 후속 버전에 양립성 문제를 해결하기 위한 조항을 추가하고 있습니다.
또한, 배포자는 특정 라이선스와의 양립성이 문제될 시 이를 해결하기 위한 대안적인 수단으로 듀얼 라이선스 정책을 적용할 수 있습니다.
일례로, 어떤 사용자가 MPL로 배포된 오픈소스SW를 GPL로 배포된 오픈소스SW와 함께 사용하려고 할 때 GPL의 엄격한 요구사항에 의해 양립성 문제가 생깁니다.
이 때 원 저작권자가 동일한 오픈소스SW를 GPL, 혹은 GPL과 양립이 가능한 Apache License 2.0(GPLv2와는 양립불가)등을 통하여 배포할 경우, 사용자는 양립성 문제로 동시에 사용할 수 없었던 GPL 오픈소스SW와 함께 사용하는것이 가능해집니다.
이러한 방법으로 듀얼 라이선스 정책은 오픈소스SW의 양립성 문제를 해결하는 대안적인 수단이 될 수 있습니다.
* LGPL의 정적 링크와 동적 링크시 소스코드 공개 범위
LGPL은 동 라이선스 하에 배포된 라이브러리를 수정하지 않는다면 동적 혹은 정적으로 링크하여도 소스코드에 대한 공개를 요구하지 않습니다.
단, LGPL 라이브러리를 정적으로 링크하였을 시에는 소스코드에 대한 공개 의무는 없더라 하더라도 배포 시 제3자에 대한 라이브러리의 사용을 보장하기 위해 오브젝트 코드를 공개할 것을 요구하고 있습니다.
따라서, LGPL을 정적으로 링크하여 사용한다고 하더라도 소스코드는 공개할 필요가 없습니다.




최근 덧글