Java(TM) Media Framework (JMF) 2.1.1e Download Link

Projects/Server 2007.09.18 14:31 Posted by soulfree >동네청년<
http://java.sun.com/products/java-media/jmf/2.1.1/download.html
신고
TAG Java, jmf

썬 자바 시스템 RFID 소프트웨어 3.0

만드는 일/프로그램 2007.07.11 16:25 Posted by soulfree >동네청년<

올해 하반기에는 아마 Java로 RFID 어플리케이션을 작성하지 싶은데....
출처 : http://www.pcbee.co.kr/contents/news/na/36253.html
==============================================================================================

한국썬마이크로시스템즈(대표 유원식, http://kr.sun.com/)는 RFID 소프트웨어의 최신버전인 썬 자바 시스템 RFID 소프트웨어 3.0(Sun Java System RFID Software 3.0 )을 새롭게 출시한다고 밝혔다.


아울러 썬 자바 시스템 RFID 소프트웨어의 주요 고객사인 삼성 SDS와 부산물류사업단은 새롭게 출시된 썬 자바 시스템 RFID 소프트웨어 3.0의 주요 특징인 SAP와 연동 및 뛰어난 확장성에 대해 높이 평가한다고 밝혔다.


새롭게 출시된 썬 자바 시스템 RFID 소프트웨어 3.0은 고용량 데이터 관리를 지원하며 기업 비즈니스 시스템과 쉽게 통합된다. 아울러 빠르고 단순한 RFID 네트워크 운영 및 구축이 가능하다는 점도 신제품의 큰 특징이다.


또한 본 제품은 SAP 넷위버의 컴포넌트인 SAP 오토-ID 인프라스트럭처와 통합되어 양사의 솔루션으로 제공되는 RFID 데이터간 네트워크 커뮤니케이션이 가능하며, mySAP 비즈니스 스위트가 탑재된 어떤 RFID 디바이스에서도 원활한 데이터 흐름이 가능하다. 아울러 지니(Jini) 기술 기반의 다이나믹 네트워킹 기능으로 생산 요구가 높은 환경에서도 지속적으로 RFID데이터를 전달 할 수 있다.


크기가 작아 리더기나 소형기기, 기업의 RFID 데이터를 실행할 수 있는 어플라이언스에 쉽게 내장될 수 있는 것 또한 썬 자바 시스템 RFID 소프트웨어 3.0의 큰 특징이다. 고객은 썬의 솔루션이 내장된 RFID 시스템을 통해 데이터를 신속하게 전달할 수 있으며, 실시간으로 RFID 데이터를 확인 할 수 있다.


삼성 SDS RFID 추진사업단의 김진용 단장은 “삼성은 RFID의 구축으로 혁신을 통해 운영 효율성을 높이고 제조 비용을 절감하는 등 삼성의 기업 철학을 실천했으며, 이는 업계의 모범이 되고 있다.” 라며 “썬의 최신 RFID솔루션은 SAP와 통합되고 크기가 작아 엔터프라이즈 엣지단 및 백엔드 시스템을 포함하는 광대한 범위에 걸쳐 RFID를 구축할 수 있고 공급망에 대한 가시성을 제공해 빠른 의사결정을 내릴 수 있도록 지원할 것으로 기대된다.” 라고 말했다.


부산 차세대물류IT기술연구사업단의 홍봉희 단장은 “항만물류는 그 특성상 매일 엄청난 양의 컨테이너를 다루고 있어 정보의 과부하 없이 효율적인 확장이 가능하며, 정확하고 빠른 RFID 네트워크가 가능한 것이 중요하다.” 라며 “썬 자바 시스템 RFID 소프트웨어 3.0은 많은 양의 데이터를 효율적으로 처리하고 SAP 오토-ID와 통합되어 짧은 시간에 빠르고 효율적으로 일을 처리할 수 있도록 하는 제품이 될 것으로 기대된다.” 라고 밝혔다.


한국썬의 유원식 사장은 “오늘날 기업들은 창고나 상점 등과 같은 한정된 범위에서 벗어나 전반적인 공급망에 걸쳐 RFID를 도입하고자 하며 현존하는 시스템과의 원만한 통합을 통해 유통 프로세스의 효율성을 높이고 불필요한 시간 낭비를 줄이고자 한다.” 라며 “썬은 최근 씨비욘드의 인수를 통해 이 모든 기업의 요구를 충족시키는 RFID 미들웨어를 제공 할 수 있게 됐으며, 썬 자바 시스템 RFID 소프트웨어 3.0은 이를 위한 핵심 제품이라 할 수 있다. 썬은 새로운 솔루션을 통해 RFID 시장에서 리더로서 입지를 더욱 강화해 나갈 것이다.” 라고 밝혔다.


한편, 썬은 네트워크 솔루션 공급사인 콤트롤(Comtrol)이 고성능 RFID 스마트 기기에 썬 자바 시스템 RFID 3.0을 미들웨어로 통합해 제공하기로 했다고 밝혔다. 양사는 제품 통합을 통해 고객에게 더욱 확장된 RFID 솔루션을 제공 할 수 있게 됐다. 콤트롤은 썬 RFID 솔루션이 제공하는 효율성과 운영 경쟁력을 높이 평가했으며, EPC글로벌의 미들웨어 관련 규격인 ALE(Application Level Events) 지원하고 SOA상에 개발되어 다양한 표준 프로토콜 및 인터페이스를 지원한다는 점을 경쟁력으로 꼽았다.


썬은 이 밖에 썬 자바 시스템 RFID 3.0 기반의 'RFID 자산 관리 시스템'을 곧 출시하여 관련 솔루션 확산에 박차를 가할 계획이다.


썬 자바 시스템 RFID 소프트웨어 3.0의 주요기능은 아래와 같다


·         SAP 오토 ID 인프라스트럭처와 통합

·         자바 컴포지트 애플리케이션 플랫폼 스위트와 통합

·         자바 ME 디바이스 지원

·         개선된 관리 콘솔 – 그룹 지원

·         확대된 개발자 키트 – 추가적 애플리케이션 및 커스터마이제이션 API


썬 자바 시스템 RFID 소프트웨어 3.0에 대한 자세한 정보는 http://www.sun.com/software/products/rfid/index.xml. 에서 볼 수 있다.

신고
TAG Java, RFID, SUN

Java DataFlavor를 이용한 클립보드 사용

Projects/CoVNC 2007.02.07 15:00 Posted by soulfree >동네청년<

   // If an image is on the system clipboard, this method returns it;
   // otherwise it returns null.
   public static Image getClipboard() {
       Transferable t = Toolkit.getDefaultToolkit().getSystemClipboard().getContents(null);
  
       try {
           if (t != null && t.isDataFlavorSupported(DataFlavor.imageFlavor)) {
               Image text = (Image)t.getTransferData(DataFlavor.imageFlavor);
               return text;
           }
       } catch (UnsupportedFlavorException e) {
       } catch (IOException e) {
       }
       return null;
   }

Setting an image on the system clipboard requires a custom Transferable object to hold the image while on the clipboard.
   // This method writes a image to the system clipboard.
   // otherwise it returns null.
   public static void setClipboard(Image image) {
       ImageSelection imgSel = new ImageSelection(image);
       Toolkit.getDefaultToolkit().getSystemClipboard().setContents(imgSel, null);
   }
  
   // This class is used to hold an image while on the clipboard.
   public static class ImageSelection implements Transferable {
       private Image image;
  
       public ImageSelection(Image image) {
           this.image = image;
       }
  
       // Returns supported flavors
       public DataFlavor[] getTransferDataFlavors() {
           return new DataFlavor[]{DataFlavor.imageFlavor};
       }
  
       // Returns true if flavor is supported
       public boolean isDataFlavorSupported(DataFlavor flavor) {
           return DataFlavor.imageFlavor.equals(flavor);
       }
  
       // Returns image
       public Object getTransferData(DataFlavor flavor) throws UnsupportedFlavorException, IOException {
           if (!DataFlavor.imageFlavor.equals(flavor)) {
               throw new UnsupportedFlavorException(flavor);
           }
           return image;
       }
   }


신고

'Projects > CoVNC' 카테고리의 다른 글

Ultra VNC 소개  (0) 2007.02.13
vnc 소개  (0) 2007.02.09
Java DataFlavor를 이용한 클립보드 사용  (0) 2007.02.07
DIB 형식 파일로 저장  (0) 2007.02.06
DIB구조  (0) 2007.02.05
DIB를 DDB로 변환  (0) 2007.02.05

static의 의미

만드는 일/프로그램 2007.01.08 15:52 Posted by soulfree >동네청년<

1.클래스를 설계할 때, 멤버변수 중 모든 인스턴스에 공통적으로 사용해야하는 것에 static을 붙인다.
- 인스턴스를 생성하면, 각 인스턴스들은 서로 독립적기 때문에 서로 다른 값을 유지한다.
   경우에 따라서는 각 인스턴스들이 공통적으로 같은 값이 유지되어야 하는 경우 static을
   붙인다.


2. static이 붙은 멤버변수는 인스턴스를 생성하지 않아도 사용할 수 있다.
- static이 붙은 멤버변수(클래스변수)는 클래스가 메모리에 올라갈때 이미 자동적으로
  생성되기 때문이다.


3. static이 붙은 메서드(함수)에서는 인스턴스 변수를 사용할 수 없다.
- static이 메서드는 인스턴스 생성 없이 호출가능한 반면, 인스턴스 변수는 인스턴스를
   생성해야만 존재하기 때문에... static이 붙은 메서드(클래스메서드)를 호출할 때
   인스턴스가 생성되어있을수도 그렇지 않을 수도 있어서 static이 붙은 메서드에서
   인스턴스변수의 사용을 허용하지 않는다.
   (반대로, 인스턴스변수나 인스턴스메서드에서는 static이 붙은 멤버들을 사용하는 것이
    언제나 가능하다. 인스턴스변수가 존재한다는 것은 static이 붙은 변수가 이미 메모리에
    존재한다는 것을 의미하기 때문이다.)


4. 메서드 내에서 인스턴스 변수를 사용하지 않는다면, static을 붙이는 것을 고려한다.
- 메서드의 작업내용중에서 인스턴스 변수를 필요로 한다면, static을 붙일 수 없다.
   반대로 인스턴스변수를 필요로 하지 않는다면, 가능하면 static을 붙이는 것이 좋다.
   메서드 호출시간이 짧아지기 때문에 효율이 높아진다.
   (static을 안붙인 메서드는 실행시 호출되어야할 메서드를 찾는 과정이 추가적으로
   필요하기 때문에 시간이 더 걸린다.)


5. 클래스 설계시 static의 사용지침
- 먼저 클래스의 멤버변수중 모든 인스턴스에 공통된 값을 유지해야하는 것이 있는지
   살펴보고 있으면, static을 붙여준다.
- 작성한 메서드 중에서 인스턴스 변수를 사용하지 않는 메서드에 대해서 static을
   붙일 것을 고려한다.

일반적으로 인스턴스변수와 관련된 작업을 하는 메서드는 인스턴스메서드(static이 안붙은
메서드)이고 static변수(클래스변수)와 관련된 작업을 하는 메서드는 클래스메서드(static이 붙은 메서드)라고 보면 된다.


다음은 static에 대한 자세한 설명과 예제입니다.


static은 객체지향개념을 이해하는 가장 중요한 첫걸음이니 확실히 알아두셔야합니다.


==================================================================
  


3.2 클래스변수와 인스턴스변수


클래스변수와 인스턴스변수의 차이를 이해하기 위한 예로 카드 게임에 사용되는 카드를 클래스로 정의해보자.



카드 클래스를 작성하기 위해서는 먼저 카드를 분석해서 속성과 기능을 알아 내야한다. 속성으로는 카드의 무늬, 숫자, 폭, 높이 정도를 생각할 수 있을 것이다.
이 중에서 어떤 속성을 클래스 변수로 선언할 것이며, 또 어떤 속성들을 인스턴스 변수로 선언할 것인지 생각해보자.


class Card {
    String kind ;                         // 카드의 무늬 - 인스턴스 변수
    int number;                         // 카드의 숫자 - 인스턴스 변수
    static int width = 100 ;             // 카드의 폭 - 클래스 변수
    static int height = 250 ;            // 카드의 높이 - 클래스 변수
}


각 Card인스턴스는 자신만의 무늬(kind)와 숫자(number)를 유지하고 있어야 하므로 이들을 인스턴스변수로 선언하였고, 각 카드들의 폭(width)과 높이(height)는 모든 인스턴스가 공통적으로 같은 값을 유지해야하므로 클래스변수로 선언하였다.

만일 카드의 폭을 변경해야할 필요가 있을 때는 모든 카드의 width값을 변경하지 않고, 한 카드의 width값만 변경해도 모든 카드의 width값이 변경되는 셈이다.

[예제6-4] CardTest.java

class CardTest{
     public static void main(String args[]) {
           // 클래스변수(static 변수)는 객체생성없이 '클래스이름.클래스변수'로 직접 사용 가능하다.
           System.out.println("Card.width = " + Card.width);
           System.out.println("Card.height = " + Card.height);

           Card c1 = new Card();
           c1.kind = "Heart";
           c1.number = 7;

           Card c2 = new Card();
           c2.kind = "Spade";
           c2.number = 4;

           System.out.println("c1은 " + c1.kind + ", " + c1.number + "이며, 크기는 (" + c1.width + ", " + c1.height + ")" );
           System.out.println("c2는 " + c2.kind + ", " + c2.number + "이며, 크기는 (" + c2.width + ", " + c2.height + ")" );             System.out.println("이제 c1의 width와 height를 각각 50, 80으로 변경합니다.");
           c1.width = 50;
           c1.height = 80;

           System.out.println("c1은 " + c1.kind + ", " + c1.number + "이며, 크기는 (" + c1.width + ", " + c1.height + ")" );
           System.out.println("c2는 " + c2.kind + ", " + c2.number + "이며, 크기는 (" + c2.width + ", " + c2.height + ")" );
     }
}

class Card {
    String kind ;                         // 카드의 무늬 - 인스턴스 변수
    int number;                         // 카드의 숫자 - 인스턴스 변수
    static int width = 100;             // 카드의 폭 - 클래스 변수
    static int height = 250;             // 카드의 높이 - 클래스 변수
}

[실행결과]
Card.width = 100
Card.height = 250
c1은 Heart, 7이며, 크기는 (100, 250)
c2는 Spade, 4이며, 크기는 (100, 250)
이제 c1의 width와 height를 각각 50, 80으로 변경합니다.
c1은 Heart, 7이며, 크기는 (50, 80)
c2는 Spade, 4이며, 크기는 (50, 80)


Card클래스의 클래스변수(static변수)인 width, height 그리고 color는 Card클래스의 인스턴스를 생성하지 않고도 '클래스이름.클래스변수'와 같은 방식으로 사용할 수 있다.
Card인스턴스인 c1과 c2는 클래스 변수인 width와 height를 공유하기 때문에, c1의 width와 height를 변경하면 c2의 width와 height값도 바뀐 것과 같은 결과를 얻는다.
Card.width, c1.width, c2.width는 모두 같은 저장공간을 참조하므로 항상 같은 값을 갖게 된다.
인스턴스 변수는 인스턴스가 생성될 때 마다 생성되므로 인스턴스마다 각기 다른 값을 유지할 수 있지만, 클래스 변수는 모든 인스턴스가 하나의 저장공간을 공유하므로, 항상 공통된 값을 갖는다.
[플래시동영상]자료실의 플래시동영상 MemberVar.swf을 꼭 보도록하자.



3.9 클래스메서드(static메서드)와 인스턴스메서드


변수에서 그랬던 것과 같이, 메서드 앞에 static이 붙어 있으면 클래스메서드이고 붙어 있지 않으면 인스턴스메서드이다.
클래스 메서드는 호출방법 역시 클래스변수처럼, 객체를 생성하지 않고도 '클래스이름.메서드이름(매개변수)'와 같은 식으로 호출이 가능하다.
그렇다면 어느 경우에 static을 사용해서 클래스메서드로 정의해야하는 것일까?

클래스는 '데이터(변수)와 데이터에 관련된 메서드의 집합'이라고 할 수 있다. 같은 클래스 내에 있는 메서드와 멤버변수는 아주 밀접한 관계가 있다. 인스턴스메서드는 인스턴스변수와 관련된 작업을 하는, 즉 메서드의 작업을 수행하는데 인스턴스변수를 필요로 하는 메서드이다.
그래서 인스턴스변수와 관계없거나(메서드 내에서 인스턴스변수를 사용하지 않거나), 클래스변수만을 사용하는 메서드들은 클래스메서드로 정의한다.

물론 인스턴스변수를 사용하지 않는다고 해서 반드시 클래스 메서드로 정의해야하는 것은 아니지만, 그렇게 하는 것이 일반적이다.
참고로 Math클래스의 모든 메서드는 클래스메서드임을 알 수 있다. Math클래스에는 인스턴스변수가 하나도 없거니와 Math클래스의 함수들은 작업을 수행하는데 필요한 값들을 모두 매개변수로 받아서 처리 하기 때문이다. 이처럼, 단순히 함수들만의 집합인 경우에는 클래스메서드로 선언한다.

[참고]인스턴스 변수 뿐만 아니라 인스턴스 메서드를 호출하는 경우에도 인스턴스 메서드로 선언되어야 한다. 인스턴스 메서드를 호출하는 것 역시 인스턴스 변수를 간접적으로 사용하는 것이기 때문이다.

[예제6-12] MyMathTest2.java

class MyMath2 {
     long a, b;
    
     // 인스턴스변수 a, b를 이용한 작업을 하므로 매개변수가 필요없다.
     long add() {       return a + b; }
     long subtract() {       return a - b; }
     long multiply() {       return a * b; }
     double divide() {       return a / b; }

     // 인스턴스변수와 관계없이 매개변수만으로 작업이 가능하다.
     static long add(long a, long b) {       return a + b; }
     static long subtract(long a, long b) {       return a - b; }
     static long multiply(long a, long b) {       return a * b; }
     static double divide(double a, double b) {       return a / b; }
}

class MyMathTest2 {
     public static void main(String args[]) {
           // 클래스메서드 호출
           System.out.println(MyMath2.add(200L, 100L));
           System.out.println(MyMath2.subtract(200L, 100L));
           System.out.println(MyMath2.multiply(200L, 100L));
           System.out.println(MyMath2.divide(200.0, 100.0));

           MyMath2 mm = new MyMath2();
           mm.a = 200L;
           mm.b = 100L;
           // 인스턴스메서드는 객체생성 후에만 호출이 가능함.
           System.out.println(mm.add());
           System.out.println(mm.subtract());
           System.out.println(mm.multiply());
           System.out.println(mm.divide());

}
[실행결과]
300
100
20000
2.0
300
100
20000
2.0

인스턴스메서드인 add(), subtract(), multiply(), divide()는 인스턴스변수인 a와 b만으로도 충분히 원하는 작업이 가능하기 때문에, 매개변수를 필요로 하지 않으므로 괄호()에 매개변수를 선언하지 않았다.
반면에 add(long a, long b), subtract(long a, long b) 등은 인스턴스변수 없이 매개변수만으로 작업을 수행하기 때문에 static을 붙여서 클래스메서드로 선언하였다.
MyMathTest2의 main메서드에서 보면, 클래스메서드는 객체생성없이 바로 호출이 가능했고, 인스턴스메서드는 MyMath2클래스의 인스턴스를 생성한 후에야 호출이 가능했다.
이 예제를 통해서 어떤 경우 인스턴스메서드로, 또는 클래스메서드로 선언해야하는지, 그리고 그 차이를 이해하는 것은 매우 중요하다.



3.10 클래스멤버와 인스턴스멤버간의 참조와 호출.


같은 클래스에 속한 멤버들간에는 별도의 인스턴스를 생성하지 않고도 서로 참조 또는 호출이 가능하다. 단, 클래스멤버가 인스턴스멤버를 참조 또는 호출하고자 하는 경우에는 인스턴스를 생성해야 한다.
그 이유는 인스턴스멤버가 존재하는 시점에 클래스멤버는 항상 존재하지만, 클래스멤버가 존재하는 시점에 인스턴스멤버가 항상 존재한다는 것을 보장할 수 없기 때문이다.

[예제6-] ArrayEx.java

class MemberCall {
     int iv = 10;
     static int cv = 20;

     int iv2 = cv;
//   static int cv2 = iv;                   에러. 클래스변수는 인스턴스 변수를 사용할 수 없음.
     static int cv2 = new MemberCall().iv;   // 굳이 사용하려면 이처럼 객체를 생성해야함.

     static void classMethod1() {
           System.out.println(cv);
//         System.out.println(iv);       에러. 클래스메서드에서 인스턴스변수를 바로 사용할 수 없음.
           MemberCall c = new MemberCall();      
           System.out.println(c.iv);   // 객체를 생성한 후에야 인스턴스변수의 참조가 가능함.
    }

     void instanceMethod1() {
           System.out.println(cv);            
           System.out.println(iv);  // 인스턴스메서드에서는 인스턴스변수를 바로 사용가능.
    }

     static void classMethod2() {
           classMethod1();
//         instanceMethod1(); 에러. 클래스메서드에서는 인스턴스메서드를 바로 호출할 수 없음.
           MemberCall c = new MemberCall();
           c.instanceMethod1(); // 인스턴스를 생성한 후에야 인스턴스메서드를 호출할 수 있음.
     }
    
     void instanceMethod2() { // 인스턴스메서드에서는 인스턴스메서드와 클래스메서드
           classMethod1();         // 모두 인스턴스생성없이 바로 호출이 가능하다.
           instanceMethod1();
    }
}

클래스멤버(클래스변수와 클래스메서드)는 언제나 참조 또는 호출이 가능하다.
그렇기 때문에 인스턴스멤버가 클래스멤버를 참조, 호출하는 것은 아무런 문제가 안 된다.
클래스멤버간의 참조 또는 호출 역시 아무런 문제가 없다.

그러나, 인스턴스멤버(인스턴스변수와 인스턴스메서드)는 반드시 객체를 생성한 후에만 참조 또는 호출이 가능하기 때문에 클래스멤버가 인스턴스멤버를 참조, 호출하기 위해서는 객체를 생성하여야 한다.

하지만, 인스턴스멤버간의 호출에는 아무런 문제가 없다. 하나의 인스턴스멤버가 존재한다는 것은 인스턴스가 이미 생성되어있다는 것을 의미하며, 즉 다른 인스턴스멤버들도 모두 존재하기 때문이다.

실제로는 같은 클래스 내에서 클래스멤버가 인스턴스멤버를 참조 또는 호출해야하는 경우는 드물다. 만일 그런 경우가 발생한다면, 인스턴스메서드로 작성해야할 메서드를 클래스메서드로 한 것은 아닌지 한번 더 생각해봐야 한다.

[알아두면 좋아요]

수학에서의 대입법처럼, c = new MemberCall()이므로 c.instanceMethod1();에서 c대신 new MemberCall()을 대입하여 사용할 수 있다.

     MemberCall c = new MemberCall();
     int result = c.instanceMethod1();

위의 두 줄을 다음과 같이 한 줄로 할 수 있다.

     int result = new MemberCall().instanceMethod1();

대신 참조변수를 사용하지 않았기 때문에 생성된 MemeberCall인스턴스는 더 이상 사용할 수 없다.

내용출처 : [기타] 서적 : 플래시로 배우는 Java, 도우출판, 저자 남궁성
신고
TAG Java, static

Writing Advanced Applications
Appendix A: Security and Permissions

[<<BACK] [CONTENTS] [NEXT>>]

All applets and any applications invoked with a security manager must be granted explicit permission to access local system resources apart from read access to the directory and its subdirectories where the program is invoked. The JavaTM platform provides permissions to allow various levels of access to different types of local information.

Because permissions let an applet or application override the default security policy, you should be very careful when you assign permissions to not create an opening for malicious code to attack your system.

This appendix describes the available permissions and explains how each permission can create an opening for malicious attacks. One way to use this information is to help you limit what permissions a given applet or application might need to successfully execute. Another way to use this information is to educate yourself on the ways in which a particular permission can be exploited by malicious code.

As a safeguard, never trust an unknown applet or application. Always check the code carefully against the information in this appendix to be sure you are not giving malicious code permission to cause serious problems on the local system.


Overview

Permissions are granted to a program with a policy file. A policy file contains permissions for specific access. A permission consists of the permission name, a target, and in some cases, a comma-separated list of actions.

For example, the following policy file entry specifies a java.io.FilePermission permission that grants read access (the action) to the ${user.home}/text2.txt target.

grant {  permission java.io.FilePermission 	"${user.home}/text2.txt", "read";};
There is one policy file for Java platform installation (system) and an optional policy file for each user. The system policy file is in {java.home}/lib/security/java.policy, and the user policy file is in each user's home directory. The system and user policy files are combined. So for example,there could be a system policy file with very few permissions granted to all users on the system, and individual policy files granting additional permissions to certain users.

To run an application with the security manager and a policy file named polfile in the user's home directory, type:

  java -Djava.security.main   -DJava.security.policy=polfile  FileIO
To run an applet in appletviewer with a policy file named polfile in the user's home directory, type:
  appletviewer   -J-Djava.security.policy=polfile fileIO.html
When running an applet in a browser, the browser looks for the user and system policy files to find the permissions the applet needs to access local system resources on behalf of the user who downloaded the applet.

Knowing Which Permissions

When you run an applet or invoke an application with a security manager that needs permissions, you will get a stack trace if you did not provide a policy file with all the needed permissions. The stack trace contains the information you need to add the permission to the policy file that caused the stack trace. If the program needs additional permissions, you will keep getting stack traces until all the required permissions are added to the policy file. The only drawback to this approach is you have to try every possible code path in your application.

Another way to determine which permission your program needs is to browse Appendix B: Methods and Permissions. This appendix tells you which Java 2 platform software methods are prevented from executing without the listed permission. The information in Appendix B is also useful for developers who want to write their own security manager to customize the verifications and approvals needed in a program.

Here is a short example to show you how to translate the first couple of lines in a stack trace to a policy file entry. The first line tells you access is denied. This means this stack trace was generated because the program tried to access a system resource without the proper permission. The second line means you need a java.net.SocketPermission that gives the program permission to connect to and resolve the host name for Internet Protocol (IP) address 129.144.176.176, port 1521.

java.security.AccessControlException: access denied
(java.net.SocketPermission 129.144.176.176:1521 connect,resolve)

To turn this into a policy file entry, list the permission name, a target, and an action list as follows where java.net.SocketPermission is the permission name, 129.144.176.176:1521 is the target, and connect,resolve is the action list.
grant {  permission java.net.SocketPermission
"129.144.176.176:1521", "connect,resolve";};

AllPermission

java.security.AllPermission specifies all permissions in the system for all possible targets and actions. This permission should be used only during testing because it grants permission to run with all security restrictions disabled as if there were no security manager.
grant {  permission java.security.AllPermission;};

AWTPermission

java.awt.AWTPermission grants access to the following Abstract Window Toolkit (AWT) targets. The possible targets are listed by name with no action list.
grant {  permission java.awt.AWTPermission
"accessClipboard";
permission java.awt.AWTPermission
"accessEventQueue";
permission java.awt.AWTPermission
"showWindowWithoutWarningBanner";};
accessClipboard: This target grants permission to post information to and retrieve information from the AWT clipboard. Granting this permission could allow malicious code to share potentially sensitive or confidential information.

accessEventQueue: This target grants permission to access the AWT event queue. Granting this permission could allow malicious code to peek at and remove existing events from the system, or post bogus events that could cause the application or applet to perform malicious actions.

listenToAllAWTEvents: This target grants permission to listen to all AWT events throughout the system. Granting this permission could allow malicious code to read and exploit confidential user input such as passwords.

Each AWT event listener is called from within the context of that event queue's EventDispatchThread, so if the accessEventQueue permission is also enabled, malicious code could modify the contents of AWT event queues throughout the system, which can cause the application or applet to perform unintended and malicious actions.

readDisplayPixels: This target grants permission to read pixels back from the display screen. Granting this permission could allow interfaces such as java.awt.Composite that allow arbitrary code to examine pixels on the display to include malicious code that snoops on user activities.

showWindowWithoutWarningBanner: This target grants permission to display a window without also displaying a banner warning that the window was created by an applet. Without this warning, an applet might pop up windows without the user knowing they belong to an applet. This could be a problem in environments where users make security-sensitive decisions based on whether the window belongs to an applet or an application. For example, disabling the banner warning might trick the end user into entering sensitive user name and password information.

FilePermission

java.io.FilePermission grants access to a file or directory. The targets consist of the target pathname and a comma-separated list of actions.

This policy file grants read, write, delete, and execute permission to all files.

grant {  permission java.io.FilePermission
"<<ALL FILES>>", "read, write, delete, execute";};
This policy file grants read and write permission to text.txt in the user's home directory.
grant {  permission java.io.FilePermission
"${user.home}/text.txt", "read, write";};
You can use the following wild cards to specify the target pathname.
  • A pathname that ends in /*, where /* is the file separator character indicates a directory and all the files contained in that directory.
  • A pathname that ends with /- indicates a directory, and recursively, all files and subdirectories contained in that directory.
  • A pathname consisting of a single asterisk (*) indicates all files in the current directory.
  • A pathname consisting of a single dash (-) indicates all files in the current directory, and recursively, all files and subdirectories contained in the current directory.
The actions are specified in a list of comma-separated keywords and have the following meanings:
  • read: Permission to read a file or directory.
  • write: Permission to write to and create a file or directory.
  • execute: Permission to execute a file or search a directory.
  • delete: Permission to delete a file or directory.

When granting file permissions, always think about the implications of granting read and especially write access to various files and directories. The <<ALL FILES>> permission with write action is especially dangerous because it grants permission to write to the entire file system. This means the system binary can be replaced, which includes the Java1 Virtual Machine (VM) runtime environment.

NetPermission

java.net.NetPermission grants access to various network targets. The possible targets are listed by name with no action list.
grant {  permission java.net.NetPermission
"setDefaultAuthenticator";
permission java.net.NetPermission "requestPasswordAuthentication";};
setDefaultAuthenticator: This target grants permission to set the way authentication information is retrieved when a proxy or HTTP server asks for authentication. Granting this permission could mean malicious code can set an authenticator that monitors and steals user authentication input as it retrieves the input from the user.

requestPasswordAuthentication: This target grants permission to ask the authenticator registered with the system for a password. Granting this permission could mean malicious code might steal the password.

specifyStreamHandler: This target grants permission to specify a stream handler when constructing a Uniform Resource Locator (URL). Granting this permission could mean malicious code might create a URL with resources to which it would not normally have access, or specify a stream handler that gets the actual bytes from somewhere to which it does have access. This means the malicious code could trick the system into creating a ProtectionDomain/CodeSource for a class even though the class really did not come from that location.

PropertyPermission

java.util.PropertyPermission grants access to system properties. The java.util.Properties class represents persistent settings such as the location of the installation directory, the user name, or the user's home directory.
grant {  
permission java.util.PropertyPermission
"java.home", "read";
permission java.util.PropertyPermission
"os.name", "write";
permission java.util.PropertyPermission
"user.name", "read, write";};
The target list contains the name of the property; for example, java.home or os.name. The naming convention for the properties follows the hierarchical property naming convention, and includes wild cards. An asterisk at the end of the property name, after a dot (.), or alone signifies a wild card match. For example, java.* or * are valid, but *java or a*b are invalid.

The actions are specified in a list of comma-separated keywords, and have the following meanings:

  • read: Permission to read (get) a property.
  • write: Permission to write (set) a property.
Granting property permissions can leave your system open to intrusion. For example, granting permission to access the java.home property makes the installation directory vulnerable to attack, and granting permission to access the user.name and user.home properties might reveal the user's account name and home directory to code that might misuse the informaiton.

ReflectPermission

java.lang.reflect.ReflectPermission grants permission for various reflective operations. The possible targets are listed by name with no action list.
grant {  permission java.lang.reflect.ReflectPermission
"suppressAccessChecks";};
suppressAccessChecks: This target grants permission to access fields and invoke methods in a class. This includes public, protected, and private fields and methods. Granting this permission could reveal confidential information and make normally unavailable methods accessible to malicious code.

RuntimePermission

java.lang.RuntimePermission grants access to various runtime targets such as the class loader, Java VM, and thread. The possible targets are listed by name with no action list.
grant {  permission java.lang.RuntimePermission
"createClassLoader"; permission java.lang.RuntimePermission
"getClassLoader"; permission java.lang.RuntimePermission
"exitVM"; permission java.lang.RuntimePermission
"setFactory"; permission java.lang.RuntimePermission "setIO";
permission java.lang.RuntimePermission
"modifyThread"; permission java.lang.RuntimePermission
"modifyThreadGroup"; permission java.lang.RuntimePermission
"getProtectionDomain"; permission java.lang.RuntimePermission
"setProtectionDomain"; permission java.lang.RuntimePermission
"readFileDescriptor"; permission java.lang.RuntimePermission
"writeFileDescriptor"; permission java.lang.RuntimePermission
"loadLibrary.<library name>"; permission java.lang.RuntimePermission
"accessClassInPackage.<package name>"; permission java.lang.RuntimePermission
"defineClassInPackage.<package name>"; permission java.lang.RuntimePermission
"accessDeclaredMembers.<class name>"; permission java.lang.RuntimePermission
"queuePrintJob";};

The naming convention for target information where a library, package, or class name is added follows the hierarchical property naming convention, and includes wild cards. An asterisk at the end of the target name, after a dot (.), or alone signifies a wild card match. For example, loadLibrary.* or * are valid, but *loadLibrary or a*b are not.

createClassLoader: This target grants permission to create a class loader. Granting this permission might allow a malicious application to instantiate its own class loader and load harmful classes into the system. Once loaded, the class loader could place these classes into any protection domain and give them full permissions for that domain.

getClassLoader: This target grants permission to retrieve the class loader for the calling class. Granting this permission could enable malicious code to get the class loader for a particular class and load additional classes.

setContextClassLoader: This target grants permission to set the context class loader used by a thread. System code and extensions use the context class loader to look up resources that might not exist in the system class loader. Granting this permission allows code to change which context class loader is used for a particular thread, including system threads. This can cause problems if the context class loader has malicious code.

setSecurityManager: This target grants permission to set or replace the security manager. The security manager is a class that allows applications to implement a security policy. Granting this permission could enable malicious code to install a less restrictive manager, and thereby, bypass checks that would have been enforced by the original security manager.

createSecurityManager: This target grants permission to create a new security manager. Granting this permission could give malicious code access to protected and sensitive methods that might disclose information about other classes or the execution stack. It could also allow the introduction of a weakened security manager.

exitVM: This target grants permission to halt the Java VM. Granting this permission could allow malicious code to mount a denial-of-service attack by automatically forcing the VM to stop.

setFactory: This target grants permission to set the socket factory used by the ServerSocket or Socket class, or the stream handler factory used by the URL class. Granting this permission allows code to set the actual implementation for the socket, server socket, stream handler, or Remote Method Invocation (RMI) socket factory. An attacker might set a faulty implementation that mangles the data stream.

setIO: This target grants permission to change the value of the System.out, System.in, and System.err standard system streams. Granting this permission could allow an attacker to change System.in to steal user input, or set System.err to a null output stream, which would hide any error messages sent to System.err.

modifyThread: This target grants permission to modify threads by calls to the stop, suspend, resume, setPriority, and setName methods in the Thread class. Granting this permission could allow an attacker to start or suspend any thread in the system.

stopThread: This target grants permission to stop threads. Granting this permission allows code to stop any thread in the system provided the code already has permission to access that thread. Malicious code could corrupt the system by killing existing threads.

modifyThreadGroup: This target grants permission to modify threads by calls to the destroy, resume, setDaemon, setmaxPriority, stop, and suspend methods of the ThreadGroup class. Granting this permission could allow an attacker to create thread groups and set their run priority.

getProtectionDomain This target grants permission to retrieve the ProtectionDomain instance for a class. Granting this permission allows code to obtain policy information for that code source. While obtaining policy information does not compromise the security of the system, it does give attackers additional information, such as local file names for example, to better aim an attack.

readFileDescriptor: This target grants permission to read file descriptors. Granting this permission allows code to read the particular file associated with the file descriptor, which is dangerous if the file contains confidential data.

writeFileDescriptor: This target grants permission to write file descriptors. Granting this permission allows code to write to the file associated with the descriptor, which is dangerous if the file descriptor points to a local file.

loadLibrary.{library name}: This target grants permission to dynamically link the specified library. Granting this permission could be dangerous because the security architecture is not designed to and does not extend to native code loaded by way of the java.lang.System.loadLibrary method.

accessClassInPackage.{package name} This target grants permission to access the specified package by way of a class loader's loadClass method when that class loader calls the SecurityManager.checkPackageAcesss method. Granting this permission gives code access to classes in packages to which it normally does not have access. Malicious code may use these classes to help in its attempt to compromise security in the system.

defineClassInPackage.{package name}: This target grants permission to define classes in the specified package by way of a class loader's defineClass method when that class loader calls the SecurityManager.checkPackageDefinition method. Granting this permission allows code to define a class in a particular package, which can be dangerous because malicious code with this permission might define rogue classes in trusted packages like java.security or java.lang, for example.

accessDeclaredMembers: This target grants permission to access the declared members of a class. Granting this permission allows code to query a class for its public, protected, default (package), and private fields and methods. Although the code would have access to the private and protected field and method names, it would not have access to the private and protected field data and would not be able to invoke any private methods. Nevertheless, malicious code may use this information to better aim an attack. Additionally, malicious code might invoke any public methods or access public fields in the class, which could be dangerous if the code would normally not be able to invoke those methods or access the fields because it cannot cast the object to the class or interface with those methods and fields.

queuePrintJob: This target grants permission to initiate a print job request. Granting this permission could allow code to print sensitive information to a printer or maliciously waste paper.

SecurityPermission

java.security.SecurityPermission grants access to various security configuration parameters. The possible targets are listed by name with no action list. Security permissions currently apply to methods called on the following objects:
  • java.security.Policy, which represents the system security policy for applications.
  • java.security.Security, which centralizes all security properties and common security methods. It manages providers.
  • java.security.Provider, which represetns an implementation of such things as security algorithms (DSA, RSA, MD5, or SHA-1) and key generation.
  • java.security.Signer, which manages private keys. Even though, Signer is deprecated, the related permissions are available for backwards compatibility.
  • java.security.Identity, which manages real-world objects such as people, companies, or organizations whose identities can be authenticated using their public keys.
grant {  permission java.security.SecurityPermission
"getPolicy";
permission java.security.SecurityPermission
"setPolicy";
permission java.security.SecurityPermission
"getProperty.os.name";
permission java.security.SecurityPermission
"setProperty.os.name";
permission java.security.SecurityPermission
"insertProvider.SUN";
permission java.security.SecurityPermission
"removeProvider.SUN";
permission java.security.SecurityPermission
"setSystemScope";
permission java.security.SecurityPermission
"setIdentityPublicKey";
permission java.security.SecurityPermission
"setIdentityInfo";
permission java.security.SecurityPermission
"addIdentityCertificate";
permission java.security.SecurityPermission
"removeIdentityCertificate";
permission java.security.SecurityPermission
"clearProviderProperties.SUN";
permission java.security.SecurityPermission
"putProviderProperty.<provider name>";
permission java.security.SecurityPermission
"removeProviderProperty.SUN";
permission java.security.SecurityPermission
"getSignerPrivateKey";
permission java.security.SecurityPermission
"setSignerKeyPair";};
getPolicy: This target grants permission to retrieve the system-wide security policy. Granting this permission discloses which permissions would be granted to a given application or applet. While revealing the policy does not compromise the security of the system, it does provide malicious code with additional information it could use to better aim an attack.

setPolicy: This target grants permission to set the system-wide security policy. Granting this permission could allow malicious code to grant itself all the necessary permissions to successfully mount an attack an attack on the system.

getProperty.{key}: This target grants permission to retrieve the security property specified by {key}. Depending on the particular key for which access has been granted, the code may have access to the list of security providers and the location of the system-wide and user security policies. While revealing this information does not compromise the security of the system, it does provide malicious code with additional information which it may use to better aim an attack.

setProperty.{key}: This target grants permission to set the security property specified by {key}. This could include setting a security provider or defining the location of the the system-wide security policy. Malicious code that has permission to set a new security provider may set a rogue provider that steals confidential information such as cryptographic private keys. In addition, malicious code with permission to set the location of the system-wide security policy may point it to a security policy that grants the attacker all the necessary permissions it requires to successfully mount an attack on the system.

insertProvider.{provider name}: This target grants permission to add the new security provider specified by {provider name}. Granting this permission allows the introduction of a possibly malicious provider that could do such things as disclose the private keys passed to it. This is possible because the Security object, which manages the installed providers, does not currently check the integrity or authenticity of a provider before attaching it.

removeProvider.{provider name}: This target grants permission to remove the provider specified by {provider name}. Granting this permission could change the behavior or disable execution of other parts of the program. If a provider requested by the program has been removed, execution might fail.

setSystemScope: This target grants permission to set the system identity scope. Granting this permission could allow an attacker to configure the system identity scope with certificates that should not be trusted. This could grant code signed with those certificates privileges that would be denied by the original identity scope.

setIdentityPublicKey: This target grants permission to set the public key for an Identity object. If the identity is marked trusted, this allows an attacker to introduce its own public key that is not trusted by the system's identity scope.This could grant code signed with that public key privileges that would be otherwise denied.

SetIdentityInfo: This target grants permission to set a general information string for an Identity object. Granting this permission allows attackers to set the general description for an identity. Doing so could trick applications into using a different identity than intended or prevent applications from finding a particular identity.

addIdentityCertificate: This target grants permission to add a certificate for an Identity object. Granting this permission allows attackers to set a certificate for an identity's public key making the public key trusted to a wider wider audience than originally intended.

removeIdentityCertificate: This target grants permission to remove a certificate for an Identity object. Granting this permission allows attackers to remove a certificate for an identity's public key. This could be dangerous because public key suddenly becomes considered less trustworthy than it otherwise would be.

printIdentity: This target grants permission to print out the name of a principal, the scope in which the principal is used, and whether the principal is considered trusted in that scope. The printed scope could be a filename, in which case it might convey local system information. For example, here is a sample printout of an identity named carol, who is marked not trusted in the user's identity database:

carol[/home/luehe/identitydb.obj][not trusted].

clearProviderProperties.{provider name} This target grants permission to clear a Provider object so it no longer contains the properties used to look up services implemented by the provider. Granting this permission disables the lookup of services implemented by the provider. This could change the behavior or disable execution of other parts of the program that would normally utilize the Provider, as described under the removeProvider.{provider name} permission above.

putProviderProperty.{provider name}: This target grants permission to set properties for the specified provider. The provider properties each specify the name and location of a particular service implemented by the provider. Granting this permission allows code to replace the service specification with another one with a different implementation and could be dangerous if the new implementation has malicaious code.

removeProviderProperty.{provider name}: This target grants permission to remove properties from the specified provider. Granting this permission disables the lookup of services implemented by the provider making them inaccessible. Granting this permission to malicious code could allow the malicious code to change the behavior or disable execution of other parts of the program that would normally utilize the Provider object, as described under the removeProvider.{provider name} permission above.

getSignerPrivateKey: This target grants permission to retrieve the private key of a Signer object. Private keys should always be kept secret. Granting this permission could allow malicious code to use the private key to sign files and claim the signature came from the Signer object.

setSignerKeyPair: This target grants permission to set the public and private key pair for a Signer object. Granting this permission could allow an attacker to replace the target's key pair with a possibly weaker (smaller) key pair. This would also allow an attacker to listen in on encrypted communication between the target and its peers. The target's peers might wrap an encryption session key under the target's new public key, which would allow the attacker (who possesses the corresponding private key) to unwrap the session key and decipher the communication data encrypted under that session key.

SerializablePermission

java.io.SerializablePermission grants access to serialization operations. The possible targets are listed by name with no action list.
grant {  permission java.io.SerializablePermission
"enableSubclassImplementation";
permission java.io.SerializablePermission "enableSubstitution";};
enableSubclassImplementation: This target grants permission to implement a subclass of ObjectOutputStream or ObjectInputStream to override the default serialization or deserialization of objects. Granting this permission could allow code to use this to serialize or deserialize classes in a malicious way. For example, during serialization, malicious code could store confidential private field data in a way easily accessible to attackers; or, during deserialization malicious code could deserialize a class with all its private fields zeroed out.

enableSubstitution: This target grants permission to substitute one object for another during serialization or deserialization. Granting this permission could allow malicious code to replace the actual object with one that has incorrect or malignant data.

SocketPermission

The java.net.SocketPermission permission grants access to a network by way of sockets. The target is a host name and port address, and the action list specifies ways to connect to that host. Possible connections are accept, connect, listen, and resolve.

This policy file entry allows a connection to and accepts connections on port 7777 on the host puffin.eng.sun.com.

grant {  permission java.net.SocketPermission
"puffin.eng.sun.com:7777", "connect, accept";};
This policy file entry allows connections to, accepts connections on, and listens on any port between 1024 and 65535 on the local host.
grant {  permission java.net.SocketPermission
"localhost:1024-", "accept, connect, listen";};

The host is expressed with the following syntax as a DNS name, as a numerical IP address, or as localhost (for the local machine). The asterisk (*) wild card can be included once in a DNS name host specification. If included, it must be in the left-most position, as in *.sun.com.

  host = (hostname | IPaddress)[:portrange]  
portrange = portnumber | -portnumber | portnumber-[portnumber]

The port or port range is optional. A port specification of the form N-, where N is a port number, means all ports numbered N and above, while a specification of the form -N indicates all ports numbered N and below.

The listen action is only meaningful when used with localhost, and the resolve (resolve host/ip name service lookups) action is implied when any of the other actions are present.

Granting code permission to accept or make connections to remote hosts may be dangerous because malevolent code can more easily transfer and share confidential data among parties that might not otherwise have access to the data.


Note: On Unix platforms, only root is normally allowed access to ports lower than 1024.

[TOP]

_______
1 As used on this web site, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.

신고