자바 native heap

j2me 2006.11.08 19:18

jvm에서 사용하는 메모리 힙은 두가지로 존재한다.

첫번째 java object을 할당하기 위한 java heap

두번째 jvm 자체적으로 사용하기 위한 native heap

 

native heap에는 다음과 같은 것이 포함되며, 명령어를 통해 조절이 불가능하다


a. 가장 기초 thread를 제외한 모든 thread
b. buffer, lookup table 및 ZIP 관련 작업(GZIPOutputStream methods)
c. Swing.AWT 하에서 native GUI와 관련된 Buffer 및 구조체
d. JNI code에 의해 사용된 data
e. Just-in-time(JIT) compiler 및 Mixed-Mode-interperter(MMI)를 지원하는 함수
f. JIT 관련 수행 코드

Posted by 김용환 '김용환'
PicoBrowser :
http://bearlib.sourceforge.net/www/pico.html
 
You could approach Opera concerning their mini browser.
http://www.opera.com/products/mobile/operamini/
 
Or Reqwireless concerning their WebViewer. 
http://www.reqwireless.com/webviewer.html
Posted by 김용환 '김용환'

WIPI is shown various heterogeneous application run time in Korea. A application in a specific mobile device is running, others not running.


And, according to a communication network vendor, their platform is different. So, hardware vendor and mobile application have a couple of applications (app is just only one.) dependent  a specific communication network vendor.

 

WIPI is desgined for balance of strictness for compatibility across implementations and flexibility for differentiation, and independent of underlying OS and air interface. It support java and c. Different common platform, main characters of WIPI are HAL (defined porting layer) and Fast binary code execution(COD compiliation).


WIPI introduction (just old, but helpful) http://www.aptsec.org/meetings/2003/APTIF-4/(10Rev1)TTA.ppt
http://www.innoace.com/download/09%20WIPI/WIPI.pdf


WIPI Standard document here :
http://wipi.or.kr/English/standard_2.0_list.php
(You know which api support and also 3d api on WIPI documents.)

 

Downoloading site about WIPI java emulator & sdk :
 http://www.developerzone.co.kr/ENGLISH/index.asp
(You have to gain a id and download it release-sdk download page.)

 

I hope to help you more.
Thanks and Regards
John Kim

 

 

-----Original Message-----
From: A mailing list for KVM discussion [mailto:KVM-INTEREST@JAVA.SUN.COM]
On Behalf Of John Bridges
Sent: Tuesday, March 14, 2006 12:32 AM
To: KVM-INTEREST@JAVA.SUN.COM
Subject: Re: WIPI C and WIPI JAVA

WIPI is a common effort to standardise the application platforms available on Korean networks - iirc.

They have GVM, SKVM, BREW, Java etc etc and I (when looking at the docs many moons ago) - WIPI C is supposed to replace GVM/BREW - or at least make them look the same at an application layer, and WIPI Java does the same for SKVM/j2me.

... and that's about the limit of my knowledge there - most of the sites detailing them require a Korean Government ID to register.

JB

kena kabra wrote:

> Hello All,
>
> Can anybody tell what is WIPI C and WIPI JAVA ?
> How it is different from J2ME.Which api's does it supports and also is
> there any 3D support on WIPI.
> I am reffering to *HERO (from Pantech), and the Kickflip (from VK).
> Hero is based on the IM-8300 in Korea.*
> **
> Also let me where can i find its sdk and document.
>
> Thanks and Regards,
> Kena
>
>
>
>
>
>
> ======================================================================
> ===== To unsubscribe, send email to listserv@java.sun.com and include
> in the body of the message "signoff KVM-INTEREST". For general help,
> send email to listserv@java.sun.com and include in the body of the
> message "help".

 

--
==============================
John Bridges
Director
ikkyou

Tel: +44 1732 74 22 22
Fax: +44 870 055 4911
email: John.Bridges@ikkyou.com
===============================

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body of the message "signoff KVM-INTEREST".  For general help, send email to listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body of the message "signoff KVM-INTEREST".  For general help, send email to listserv@java.sun.com and include in the body of the message "help".

Posted by 김용환 '김용환'

JVM web pages where I know are below.

 

Java virtual machine spec page in sun
http://java.sun.com/docs/books/vmspec/index.html

 

Open Source JVM  implementation page - RVM http://jikesrvm.sourceforge.net/

GNU JVM implementation page - KAFFE http://www.kaffe.org/

 

Under the hood from artima.com
http://www.artima.com/underthehood/
http://www.javaworld.com/columns/jw-hood-index.shtml

 

Inside jvm from artima.com
http://www.artima.com/insidejvm/resources/index.html

 

Many people said me "Inside the Java virtual machine" book is good to study JVM.

If anybody know the good resources, please share it with pleasure.

 

Sincererly
YongHwan


-----Original Message-----
From: A mailing list for KVM discussion [mailto:KVM-INTEREST@JAVA.SUN.COM]
On Behalf Of Gowri Satish Adimulam
Sent: Thursday, March 16, 2006 2:59 PM
To: KVM-INTEREST@JAVA.SUN.COM
Subject: concepts of Virtual mahine

Hi ,

Iam new to Java ,
can any body let me know where can i find some resouces about Java Virtual machines .

.
Thanks
Gowri

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body of the message "signoff KVM-INTEREST".  For general help, send email to listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body of the message "signoff KVM-INTEREST".  For general help, send email to listserv@java.sun.com and include in the body of the message "help".

Posted by 김용환 '김용환'

j2me에서는 키를 처리할 수 있는 방법은 두가지이다.

Canvas 클래스에서 key 이벤트 처리가 가능하다.

  • keyPressed()
  • keyRepeated()
  • keyReleased()
  • pointerPressed()
  • pointerDragged()
  • pointerReleased()
  • getGameAction()
  •  

    이외, Command, CommandListener를 이용하여 키를 처리할 수 있다.

     

    Posted by 김용환 '김용환'

     
     
    ▶ 난이도중하
     
    MIDP가 모바일 디바이스에 있어서 훌륭한 플랫폼인 이유는 MIDP가 제공하는 보안에서 기인한다. MIDP의 보안 모델은 본래 Java 프로그래밍 모델에서 유래한 것으로서, MIDlet 코드가 가상머신 상에서 작동하므로 바이너리 코드상에 존재하는 위험한 오류를 피할 수 있는 기능이 있다. 잘못 쓰여진 코드나 악의적인 목적으로 작성된 코드는 디바이스를 고장낼 위험이 있다. 이러한 최악의 경우에는 잘못 작성된 Java 코드가 실행중인 Java 환경을 중지시켜 디바이스의 나머지 부분은 피해를 입지 않도록 보호된다.
    MIDP 2.0의 보안 지원은 JVM으로만 끝나는 것은 아니다. 여기서는 다른 종류의 MIDP 2.0 기능들이 어떻게 사용자와 디바이스를 악의적 소프트웨어로부터 보호하는지에 대해 설명한다. J2ME Wireless Toolkit 2.0(베타 2 이후 버전)을 사용해 MIDP 2.0 보안 아키텍처를 살펴본다.
     

    MIDP 2.0 스펙은 허가/거부 방식으로 퍼미션(Permissions)을 관리한다. 네트워크 커넥션을 만드려면 MIDlet에 필요한 퍼미션이 허가돼야 한다.

     
    예를 들어, MIDlet에서 HTTP 프로토콜을 통해 서버와 통신하고자 한다면 HTTP 커넥션에 대한 퍼미션이 열려야 한다. MIDP 2.0에 정의된 퍼미션은 네트워크 프로토콜에 대응되는 형태이지만, MIDP 아키텍처에서는 추가적인 API를 제공하고 있으므로 자신만의 퍼미션을 정의할 수도 있다.
    각각의 퍼미션은 고유의 이름이 정해져 있다. MIDP 2.0의 퍼미션 목록은 다음과 같다.
     
    * javax.microedition.io.Connector.http
    * javax.microedition.io.Connector.socket
    * javax.microedition.io.Connector.https
    * javax.microedition.io.Connector.ssl
    * javax.microedition.io.Connector.datagram
    * javax.microedition.io.Connector.serversocket
    * javax.microedition.io.Connector.datagramreceiver
    * javax.microedition.io.Connector.comm
    * javax.microedition.io.PushRegistry
     
    퍼미션명과 클래스명이 비슷해보이지만 실제로는 서로 다르다. 한 예로 javax.microedtion.io.Connector.https 퍼미션은 javax.microedtion.io.Connector 클래스를 사용해 HTTP 커넥션을 만드는 것을 관리한다.
    MIDlet은 코드 형태가 아닌, 보호 도메인(Protection Domain)을 통해 퍼미션을 획득한다. 그러나 먼저 코드 보안에 대해 설명하기에 앞서 간단한 코드를 살펴보기로 하자.
    다음의 간단한 MIDlet(이 글의 소스코드는 http://wireless. java.sun.com/midp/articles/permissions/src/HTTPMIDlet.zip에서 다운받을 수 있다.)은 HTTP 커넥션을 생성하고 서버 응답의 일부를 얻는다.
     
    import java.io.*;
    import javax.microedition.io.*;
    import javax.microedition.lcdui.*;
    import javax.microedition.midlet.*;
    public class HTTPMIDlet
    extends MIDlet
    implements CommandListener, Runnable {
    private Display mDisplay;
    private Form mMainScreen;

    public HTTPMIDlet() {
    mMainScreen = new Form(“HTTPMIDlet”);
    mMainScreen.append(
    “Press OK to create an HTTP connection.”);

    Command exitCommand =
    new Command(“Exit”, Command.EXIT, 0);
    Command okCommand =
    new Command(“OK”, Command.OK, 0);
    mMainScreen.addCommand(exitCommand);
    mMainScreen.addCommand(okCommand);
    mMainScreen.setCommandListener(this);
    }

    public void startApp() {
    if (mDisplay == null)
    mDisplay = Display.getDisplay(this);
    mDisplay.setCurrent(mMainScreen);
    }

    public void pauseApp() {
    }

    public void destroyApp(boolean unconditional) {}

    // CommandListener 메쏘드

    public void commandAction(Command c, Displayable s) {
    if (c.getCommandType() == Command.EXIT)
    notifyDestroyed();
    else if (c.getCommandType() == Command.BACK)
    mDisplay.setCurrent(mMainScreen);
    else if (c.getCommandType() == Command.OK) {
    // 대기 메시지 출력
    Form waitForm = new Form(“Connecting...”);
    mDisplay.setCurrent(waitForm);
    // 접속 시도
    Thread t = new Thread(this);
    t.start();
    }
    }

    // Runnable 메쏘드

    public void run() { String url = “http://wireless.java.sun.com/”;

    Form resultsForm = new Form(“Results”);
    Command backCommand =
    new Command(“Back”, Command.BACK, 0);
    resultsForm.addCommand(backCommand);
    resultsForm.setCommandListener(this);

    HttpConnection hc = null;
    InputStream in = null;

    try {
    // 서버에 접속한다
    hc = (HttpConnection)Connector.open(url);

    // 응답을 받아온다
    in = hc.openInputStream();

    int length = 256;
    byte[] raw = new byte[length];
    int readLength = in.read(raw);

    String message = new String(raw, 0, readLength);
    resultsForm.append(message);
    }
    catch (Exception e) {
    resultsForm.append(
    new StringItem(“Exception: “, e.toString()));
    }
    finally {
    if (in != null) {
    try { in.close(); }
    catch (IOException ioe) {}
    }
    if (hc != null) {
    try { hc.close(); }
    catch (IOException ioe) {}
    }
    }
    mDisplay.setCurrent(resultsForm);
    }
    }
     

    HTTPMIDlet의 run() 메쏘드는 서버에 접속해 필요한 데이터를 얻은 뒤, 이를 화면에 출력하는 형태로 구성돼 있다. 지금은 보안 도메인에 대해서 생각하지 말고 프로그램을 빌드한 뒤 HTTPMIDlet을 실행시켜보자. OK 명령을 선택해 프로그램이 접속을 시도하면, HTTPMIDlet은 Connector.open( ) 메쏘드를 호출한다. 만약 J2ME Wireless Toolkit(http://java.sun.com/products/j2mewtoolkit)을 사용하고 있다면 에뮬레이터가 퍼미션을 선택할 것을 요구한다(그림 1).
    이 시점에서 해당 접속에 대한 퍼미션을 허가하거나 거부할 수 있다. 퍼미션을 영구적으로 허가하거나 거부할 수도 있다. 그러나 영구적 허가는 뒤에 설명할 MIDlet 슈트 설치에서만 의미가 있다. 만약 접속을 허가하면 애플리케이션이 정상적으로 작동된다. MIDlet은 HTTP 커넥션을 통해 얻은 데이터를 출력한다(그림 2).
    반면 뭔가 좋지 않은 기분이 들어 커넥션을 거부한다면 Connector. open( )은 SecurityException을 던지게 된다. HTTPMIDlet은 이 예외를 잡아 예외에 대한 설명 메시지를 출력한다. MIDlet은 네트워크 접속으로부터 발생하는 모든 종류의 SecurityException을 잡아서 처리토록 해야 한다(그림 3).
    에뮬레이터는 HTTP 커넥션이 성립될 때 사용자에게 퍼미션 허가를 요구해야 한다는 사실을 어떻게 아는가? 왜 퍼미션이 자동적으로 허가되거나 거부되지 않는가? 이는 HTTPMIDlet을 담고 있는 보호 도메인과 관련돼 있다.
     
    보호 도메인은 다음과 같은 두 부분으로 구성된다.
     
    - 허가된 퍼미션(MIDlet 슈트 내부에 부여됨)과 사용자에게 물어봐야 하는 퍼미션
    - 보호 도메인 허가에 대한 기준
     
    J2ME Wireless Toolkit의 ‘Run’ 버튼을 누르면, 현재 MIDlet 슈트는 Untrusted라는 보호 도메인 내에서 실행된다. 이 도메인 안에서 사용자에게 모든 퍼미션을 물어야 한다. HTTPMIDlet이 HTTP 커넥션을 얻고자 시도할 때 에뮬레이터가 퍼미션 허가 여부를 물어본 이유가 바로 이것이다.
    MIDlet 슈트의 실행시간 보호 도메인은 Edit>Preferences를 선택한 뒤 Security 탭을 통해 변경할 수 있다(그림 4).
    J2ME Wireless Toolkit에는 네 개의 보안 도메인이 있다. Minimum과 Untrusted, Trusted, Maximum 도메인이 그것들이다. Minimum 도메인 내의 MIDlet은 모든 퍼미션을 거부한다. Untrusted 도메인은 모든 퍼미션에 대해 허가 여부를 물어본다. Trusted 도메인은 MIDlet 보안의 열반상태로 표현되며, 모든 퍼미션이 허락된다. Maximum 도메인은 Trusted 도메인과 동일하다.
    Minimum 도메인을 선택하고 HTTPMIDlet을 다시 실행해보자. 이제 OK 버튼을 선택해 접속을 시도하면 즉시 퍼미션이 거부되며, HTTPMIDlet은 SecurityException을 보여준다.
    J2ME Wireless Toolkit의 보안 도메인은 보안 도메인을 구현하는 한 가지 방법일 뿐이다. 제조업자와 통신업자, 다른 MIDP 구현자들은 각자의 목적에 맞는 도메인을 직접 만들 수 있다.
     
    보호 도메인은 allowed 퍼미션과 user 퍼미션을 갖는다. user 퍼미션을 선택하면 사용자에게 퍼미션 허가 여부를 묻는다. user 퍼미션은 세 가지 형태의 변형(스펙에는 이를 ‘상호작용 모드’라고 지칭하고 있다.)이 있다. MIDlet이 퍼미션을 요구하는 최초의 시점에서, 구현에 따라 사용자에게 퍼미션의 허가 또는 거부를 묻는다. 세 가지 형태의 모드는 구현에 있어서 사용자가 선택한 퍼미션 허가 여부를 얼마나 기억하고 있어야 하는지를 나타낸다.
    oneshot 퍼미션의 경우, MIDP 구현은 사용자 선택을 전혀 기억하지 않으며, 퍼미션 허가가 필요할 때마다 매번 사용자에게 허가 여부를 묻는다. session 퍼미션의 경우, 구현은 MIDlet 종료시까지 사용자의 선택을 기억한다. 끝으로 blanket 퍼미션에서는 사용자의 선택이 MIDlet 슈트의 언인스톨 시점까지 계속적으로 유효하다.
    보호 도메인은 사용자가 명시적으로 허가하지 않은 권한에 대해서는 반드시 거부해야 한다. 예를 들어 HTTPOnly 보호 도메인이 다음과 같은 단일 퍼미션만을 포함하고 있다고 하자.

    allow: javax.microedition.io.Connector.http

    이 도메인은 명시된 퍼미션 이외에 대해서는 모두 거부한다. 퍼미션을 좀더 느슨하게 정의하고 싶다면, 다른 종류의 퍼미션에 대해서는 사용자가 선택하도록 다음과 같이 지정할 수 있다.

    allow: javax.microedition.io.Connector.http
    blanket: javax.microedition.io.Connector.https
    blanket: javax.microedition.io.Connector.socket


    이 경우, HTTP와 소켓 접속에 대해서는 사용자가 퍼미션 허가 여부를 결정해야 한다.
    보호 도메인의 정의와 설정은 MIDP 구현의 영역임을 기억하자. 애플리케이션 개발자로서 MIDP 2.0 스펙에 의해 정의된 보안 아키텍처에서 효과적으로 작업하는 것은 개발자의 몫이다.
     
    JAD 내의 특별한 속성은 MIDlet 슈트가 특정 퍼미션에서의 의존성을 표시하는 데 사용된다. 이 속성들을 사용해 ‘이 MIDlet 슈트는 HTTP 접속을 필요로 하며, 소켓 접속을 필요로 할 수도 있다’고 명시할 수 있다. 이 경우에는 디스크립터 내의 속성을 다음과 같이 작성할 수 있다.

    MIDlet-Permissions: javax.microedition.io.Connector.http
    MIDlet-Permissions-opt: javax.microedition.io.Connector.socket


    다행히도 이 속성들을 수작업으로 추가할 필요는 없다. J2ME Wireless Toolkit 2.0은 속성을 쉽게 추가할 수 있도록 도와준다. 즉 Settings...을 클릭한 뒤에 Permissions 탭을 선택한다. 그런 다음 필요한 퍼미션과 선택적 퍼미션들을 추가한다. 툴킷은 이 퍼미션들을 MIDlet 슈트 JAD 내에 자동으로 추가한다.
    필요한 퍼미션과 선택적 퍼미션을 JAD에 넣을 때 얻을 수 있는 이점은 무엇인가? JAD는 MIDlet 슈트가 특정 동작을 시도할 것을 인스톨 시점에서 디바이스에게 알릴 수 있는 편리한 기능을 갖고 있다. 만약 디바이스가 MIDlet 슈트가 요청하는 몇 개의 퍼미션을 허가하지 않는 보호 도메인 내에 MIDlet을 인스톨하려고 하면 인스톨에 실패한다. 이러한 메커니즘이 없다면 사용자는 MIDlet 슈트를 설치한 뒤에야 해당 MIDlet 슈트가 정상적으로 동작하지 않음을 알게 된다.
     

    지금부터 보호 도메인의 측면은 어떻게 MIDlet 슈트가 도메인 내에 진입하는지에 대한 설명이다.
    다운받은 코드는 상당히 위험하다. 특히 코드 작성자를 모르거나 코드가 어디에서 온 것인지를 모른다면 더욱 그렇다. 비록 가상머신 상에서 실행중인 MIDlet이 바이너리 코드보다는 안전하기는 하지만, 여전히 위험은 존재한다. 다운받은 MIDlet은 인가되지 않은 네트워크 커넥션을 만들 수 있으며, 이 커넥션들은 사용자 메모리를 사용한다. 악의적인 MIDlet은 사용자 정보를 수집하고, 이를 서버에 전송해 악의적인 목적으로 사용할 수 있다. MIDP 디바이스는 사용자에게 게임과 애플리케이션과 같은 다양한 선택 사항을 제공하는 유연성을 제공하지만, 이 유연성으로 인해 출처와 의도가 의심스러운 코드를 실행할 위험에 빠지게 만들기도 한다.

    사용자가 다운받은 MIDlet을 실행하는 데 있어서 좀더 안전하게끔 보호 도메인을 설정할 수 있다. MIDP 스펙에는 어떻게 보호 도메인이 규정되는지에 대해서는 매우 모호하게 정의되어 있다. 많은 부분이 구현자의 자유재량에 맡긴다. 이러한 영역에는 보호 도메인의 개수와 보호 도메인에 대한 정의 같은 부분이 포함된다. 그러나 스펙에서는 암호화된 서명과 인증서에 기반한 보호 도메인 개념을 제시하고 있다. 이 개념은 통신업자나 소프트웨어 개발자가 싸이닝 키 조합을 생성하고 인정받은 인증기관으로부터 인증서를 획득하도록 하는 것이다. 통신업자나 개발자는 MIDlet 슈트 JAR의 서명을 계산하고, 서명과 인증을 애플리케이션 디스크립터에 저장한다.

    싸인된 MIDlet 슈트는 사용자에게 MIDlet 슈트가 변경되지 않았으며 식별 가능한(따라서 법적 의무를 지는) 원천으로부터 온 것임을 증명한다. 디바이스 상의 MIDP 구현은 디스크립터의 서명을 검사함으로써 사용자의 신원을 검증한다. 개발자의 공개키를 사용하면 MIDP 슈트 자체의 무결성을 검증할 수 있다.

    J2ME Wireless Toolkit 2.0 버전에는 키와 MIDlet 슈트의 싸이닝을 편리하게 관리해주는 툴이 포함되어 있다. 예를 들어 HTTPMIDlet 프로젝트를 서명하는 경우를 가정해보자. Project>Package>Create Package를 통해 MIDlet 슈트를 패키징한 뒤, Project>Sign을 사용해 싸이닝할 수 있다(그림 5).

    이 윈도우에는 툴킷에게 알려진 모든 싸이닝 키 조합이 나타난다. Java keystore에 생성해둔 키 조합을 사용해 MIDlet 슈트를 싸인하고 싶다면, J2ME Wireless Toolkit의 Import Key Pair를 사용해 키 조합을 가져오면 된다.
    싸이닝에 사용할 새로운 키 조합을 생성하고 싶은 경우에는 New Key Pair를 클릭한다. 키명(key alias), 도메인명(domain name), 회사명(company name)을 적절한 값으로 채운다(그림 6).

    툴킷은 새로운 키 조합을 생성하고 이를 사용 가능한 싸이닝 키 조합 목록에 표시한다. 이 시점에서 툴킷은 해당 키 조합을 어떤 보호 도메인과 연관시킬 것인가를 묻는다. 에뮬레이터는 이때 선택한 보호 도메인 내에 MIDlet을 설치하게 된다. 이 예에서는 Trusted를 선택한다(그림 7).

    키 조합을 생성하고 보호 도메인을 선택했으면, MIDlet 슈트를 싸이닝하는 방법은 매우 간단하다. 사용할 키 조합의 명칭을 선택하고 Sign MIDlet Suite를 클릭한다. 만약 File>Utilities를 통해 Sign MIDlet Suite 윈도우를 띄웠다면, 툴킷은 싸인할 MIDlet 슈트의 디스크립터 위치를 물을 것이다. 만약 HTTPMIDlet 프로젝트를 사용하는 경우라면 디스크립터는 J2ME Wireless Toolkit 디렉토리 내의 apps/HTTPMIDlet/bin/HTTPMIDlet.jad가 될 것이다. Project>Sign을 KToolbar 메뉴로부터 선택했다면, 툴킷은 현재 활성화된 프로젝터의 디스크립터를 사용한다.
    MIDlet 슈트의 싸이닝이 끝나면 툴킷이 이를 알리는 메시지를 띄운다. 만약 싸이닝 여부를 확인하고 싶다면 디스크립터를 텍스트 편집기로 열어본다. 두 개의 새로운 속성인 MIDlet-Certificate-1-1과 MIDlet-Jar-RSA-SHA1가 추가되어 있을 것이다. 이 두 속성은 모두 바이너리 데이터를 텍스트로 인코딩하는 데 사용되는 base64 형태로 저장된다.
    싸인된 MIDlet 슈트를 생성한 뒤에는 무엇을 해야 할까? J2ME Wireless Toolkit을 사용해, MIDlet 슈트를 에뮬레이터에 설치하고 올바른 보호 도메인 상에서 작동되는지를 확인해본다. 모든 MIDP 구현(툴킷 에뮬레이터 포함)에는 MIDlet과 MIDlet 슈트를 관리하는 애플리케이션 관리 소프트웨어(AMS. Application Management Software)가 포함되어 있다. MIDlet 슈트의 인스톨과 실행, MIDlet 실행 종료 후의 정리는 모두 AMS가 관리한다(혹시 MIDlet 내의 startApp()를 누가 호출하는지에 대해 궁금한 적이 있는가? 바로 AMS가 호출한다.).
    툴킷 에뮬레이터에는 OTA(Over The Air) 프로비저닝을 처리할 수 있는 AMS가 포함되어 있다. 에뮬레이터의 AMS가 MIDlet 슈트 디스크립터에 대한 링크를 포함하고 있는 웹 페이지를 가리키도록 하자. 그러면 AMS는 MIDP 스펙에 정의되어 있는 OTA 프로토콜을 사용해 MIDlet 슈트를 다운받은 후 설치한다.
    다행히도 이 기능을 사용하기 위해 직접 서버를 셋업할 필요는 없다. J2ME Wireless Toolkit 2.0(베타 2 또는 그 이상의 버전)에는 OTA 서버 에뮬레이션이 포함되어 있어 싸인된 MIDlet 슈트의 OTA 설치를 쉽게 테스트해볼 수 있다.

    MIDlet 슈트를 패키징 및 싸이닝 했다고 가정하고 Project>Run via OTA를 KToolbar 메뉴로부터 선택한다. 에뮬레이터가 나타나고 AMS 로고 화면이 나타난다(그림 8).
    Apps를 선택해 설치된 MIDlet 슈트의 목록을 표시한다(그림 9).
    싸이닝을 마친 MIDlet 슈트를 설치하기 위해 Install Application을 선택하고 select 버튼을 클릭한다. AMS는 URL을 요청한다. 그러나 로컬 OTA 서버의 주소가 자동으로 입력될 것이다(그림 10).
    이제 Go 명령을 선택한다. AMS는 툴킷의 OTA 서버에 접속하고, 설치할 MIDlet 슈트를 선택할 것을 요청한다(그림 11). 하나의 애플리케이션만 나타날 것이다.
    Install을 선택해 설치를 시작한다. AMS는 MIDlet 슈트에 대한 몇 가지 기본 정보를 보여주고 계속 설치할지 여부를 묻는다(그림 12).

    Install을 다시 한번 선택하면, AMS는 MIDlet 슈트를 설치하고 이를 실행가능한 MIDlet 슈트 목록에 추가한다. HTTPMIDlet 예를 실행하면, 에뮬레이터가 퍼미션을 묻지 않고도 HTTP 커넥션이 연결됨을 확인할 수 있다. 어떻게 이런 일이 가능한가? 이는 키 조합을 생성할 때, 해당 키 조합을 Trusted 보호 도메인과 연관시켜 두었기 때문이다. 에뮬레이터는 Run via OTA를 사용할 때 MIDlet 슈트를 Trusted 도메인 내에 설치했다. 따라서 HTTPMIDlet이 HTTP 커넥션을 시도할 때, Trusted 보호 도메인으로부터 퍼미션을 얻을 수 있는 것이다.
     
     
    지금까지 MIDP 디바이스 상의 보안 아키텍처에 대한 의미와 MIDP 2.0에서 보호하고 있는 네트워크 동작에 대해 살펴보았다. J2ME Wireless Toolkit은 MIDlet이 필요로 하는 퍼미션을 쉽게 선택할 수 있도록 도와준다. MIDlet은 보호 도메인이라는 장소 안에 증명서(credentials)에 따라서 정렬되어 저장된다. 보호 도메인은 퍼미션의 집합과 도메인 내 입장에 필요한 기준의 집합이다. MIDP 2.0 스펙에는 MIDlet 슈트를 암호화 싸이닝하는 방법을 포함하고 있다. 이 방법은 J2ME Wireless Toolkit에 포함되어 있으며, 이 툴에는 키 조합과 MIDlet 슈트 싸이닝에 필요한 간단한 방법을 제공한다. 끝으로 툴킷의 Run via OTA 기능을 사용해 싸이닝한 MIDlet 슈트의 설치를 쉽게 테스트해볼 수 있다.
    MIDP 2.0의 보안 아키텍처는 유연한 동시에 강력하다. J2ME Wireless Toolkit을 사용하면 새로운 보안 아키텍처를 이용해 사용자가 보다 안전하게 실행할 수 있는 소프트웨어를 개발할 수 있다.
     

     

    Posted by 김용환 '김용환'

    http://www.vikdavid.com/mobile/

     

    Java on PocketPC, the Unofficial FAQ 페이지

    Posted by 김용환 '김용환'

    http://www.forum.nokia.com/info/sw.nokia.com/id/bd70d77a-f82f-47ce-a4f8-ca3d868e60a8/MIDP_System_Properties_v1_1.zip.html

     


     노키아 폰에서의 시스템 환경변수값을 알수 있다.

    Posted by 김용환 '김용환'

    J2me properties

    j2me 2006.02.03 19:15

    http://developers.sun.com/techtopics/mobility/midp/questions/properties/

     

    J2ME Defined System Properties

    JSR Property Name
    Default Value¹
    30 microedition.platform null
      microedition.encoding ISO8859_1
      microedition.configuration CLDC-1.0
      microedition.profiles null
    37 microedition.locale null
      microedition.profiles MIDP-1.0
    75 microedition.io.file.FileConnection.version 1.0
      file.separator (impl-dep)
      microedition.pim.version 1.0
    118 microedition.locale null
      microedition.profiles MIDP-2.0
      microedition.commports (impl-dep)
      microedition.hostname (impl-dep)
    120 wireless.messaging.sms.smsc (impl-dep)
    139 microedition.platform (impl-dep)
      microedition.encoding ISO8859-1
      microedition.configuration CLDC-1.1
      microedition.profiles (impl-dep)
    177 microedition.smartcardslots (impl-dep)
    179 microedition.location.version 1.0
    180 microedition.sip.version 1.0
    184 microedition.m3g.version 1.0
    185 microedition.jtwi.version 1.0
    195 microedition.locale (impl-dep)
      microedition.profiles IMP-1.0
    205 wireless.messaging.sms.smsc (impl-dep)
    205 wireless.messaging.mms.mmsc (impl-dep)
    211 CHAPI-Version 1.0

    ¹(impl-dep) indicates that the default value is implementation-dependent.

     

    Posted by 김용환 '김용환'

    j2me 의 General File Connection 프레임웍에 사용예..

     

    출처 : http://www.devx.com/wireless/Article/21871/0/page/1 

     

     

    rom the earliest days of J2ME, network connectivity has been a central focus of the design. So much so that a generic architecture, referred to as the Generic Connection Framework (GCF), was created to standardize not only how applications create network connections but the associated connection interfaces device manufacturers must implement. The GCF is a fundamental part of J2ME and is available to all application profiles including Personal Profile and the Mobile Information Device Profile (MIDP).
    Figure 1. The J2ME Stack: The configuration layer forms the basis for the J2ME stack and defines the characteristics of the J2ME.



    In order to make the GCF available to all J2ME application profiles, the GCF is implemented in the configuration layer. The configuration layer is a set of J2ME libraries that form the basis of any J2ME architecture. Packages such as java.lang, java.util, java.io, and so forth can be found in the configuration layer. Figure 1 shows how the configuration layer relates to the profile layer in J2ME
     
     
     
     
    J2ME Configurations
    Currently, there are two J2ME configurations that support networking: the Connected Limited Device Configuration (CLDC) and the Connected Device Configuration (CDC). The CLDC is designed for more limited devices that require a smaller API footprint. MIDP is based on the CLDC. The CDC is designed for devices with more power and API footprint but are still too small to support standard Java. The Personal Profile is based on the CDC.

     

    In order to enhance the upward compatibility of J2ME applications from the CLDC range of devices to the CDC range of devices, the CLDC and CDC have a strict superset-subset relationship. Figure 2 shows the relationship between the CLDC, CDC, and J2SE. Note that the CLDC and CDC contain APIs that are unique to J2ME and not part of standard Java. Libraries that are unique to J2ME exist in the javax.microedition.* packages.

    Figure 2. Concentric Circles. The CDC and CLDC have a strict subset-superset relationship. Note also that J2ME configurations contain APIs that extend beyond what standard Java (J2SE) provides.

     

    Configurations and Connectivity
    The GCF is implemented in the CLDC, thereby making it available to any J2ME application since, by definition, the CDC must include everything defined by the CDLC. This has the effect of standardizing network connectivity throughout the J2ME environment, regardless of the profile or the device—a big advantage for J2ME developers.

     

    Creating Network Connections using the GCF
    Before discussing the architecture any further, I want to look at some code. At the heart of the GCF is the Connector class and a set of interfaces that are defined in the javax.microedition.io package. The Connector class is a factory that creates connection instances. The interfaces define the types of connections supported. How the implementer actually provides the network connectivity is not of concern, to either the GCF or the application developer, as long as the connection returned supports the behaviors defined by the GCF interface. An example of an HTTP connection is shown below.

    
    HttpConnection c = (HttpConnection)
    Connector.open("http://www.gearworks.com",  
      Connector.READ_WRITE, true);
    
    The Connector class figures out what type of connection to create by parsing the connection string ("http://www.gearworks.com" in this case). The connection string is composed of three parts: the scheme, target, and parameters. The scheme is required but the latter two are optional. All connection strings follow the pattern noted below.
    
    {scheme}: [{target}] [{parameters}]
    
    In the HTTP example the scheme is "http" and the target is "www.gearworks.com." There are no parameters.

    Although the connection string looks a lot like a URL, it can be used to create many different types of connections, not just HTTP connections. Table 1 shows examples of different types of connections that may be created using the GCF. Note however, the actual support for a specific connection is subject to the J2ME profile requirements and what a vendor chooses to implement. If the connection is not supported by the J2ME implementation a ConnectionNotFoundException is thrown.

    HTTP http://www.host.com: 8080
    Socket socket://host.com:80
    Socket Listener socket://:1234
    Datagram Sender datagram://host.com:9001
    Datagram Listener datagram://: 9001
    File file:/myfile.txt
    Comm Port comm:com0;baudrate=19200;parity=odd

    Table 1. Examples of different types of connections that may be created using the GCF. Support for the actual connection type, however, is implementation dependent.

     

     

    Digging into Datagrams
    It is quite possible for someone to have worked with Java for some time without ever needing to understand or use datagrams. For mobile devices, however, datagrams offer some advantages in that they are rather lightweight when compared to TCP-based connections such as sockets. User Datagram Protocol, UDP, is one of the more common datagram protocols. However, because most datagram protocols follow the same basic principals as to their usage, the GCF is able to support datagrams generically.
     
    Datagrams are based on a connection-less paradigm, which means that a conversation is not established between two systems. Instead, datagrams are blindly transmitted across a network connection. To transmit a datagram from one system to another, an application creates a datagram and sends it to the intended target. This is a rather simple process in J2ME. However, there is a caveat to using datagrams in that they offer no guarantee or acknowledgement as to whether the datagram actually reached the intended recipient. As a result, a datagram implementation must either not care if the recipient actually receives the data 100 percent of the time, or an acknowledgement/handshake must be implemented manually by the application.

     

    Using Datagrams
    The following example shows how to create a datagram and send it to a specific IP address.

    
    try	{
      DatagramConnection dgc = (DatagramConnection)
        Connector.open("datagram://localhost:9001");
      try {
        byte[] payload = "Test Message".getBytes();
        Datagram datagram = 
          dgc.newDatagram(payload, payload.length);
        dgc.send(datagram);
      } finally {
          dgc.close();
      }
    } catch (IOException x) {
      x.printStackTrace();
    }
    In this example, a MIDlet creates a Datagram containing the text "Hello from a Datagram" and sends it to an application listening for datagrams on the local machine on port 9001. This example will execute just fine even if there is no application running to receive the datagram, thus demonstrating the connection-less nature of datagrams. The sender has no indication that the datagram was consumed by the target system.

    Next I show how an application might receive the datagram sent by the previous code snippet.

    
    try {
      DatagramConnection dgc = (DatagramConnection) 
        Connector.open("datagram://:9001");
      try {
        int size = 100;
        Datagram datagram = dgc.newDatagram(size);
        dgc.receive(datagram);
        System.out.println(
          new String(datagram.getData()).trim());
      } finally {
          dgc.close();
      }
    } catch (IOException x){
      x.printStackTrace();
    }
    
    In the receive example, a datagram connection is established on port 9001. A datagram is created with a size of 100 bytes; if a received datagram contains more than 100 bytes, any data beyond the 100-byte mark is ignored. Once the datagram is created the receive() method is called, putting the thread in a wait state until a datagram is received. When a datagram is received, the payload is extracted from the datagram container and printed to the console.

    In order to run the send and the receive examples, two instances of a MIDlet can be run from the Wireless Toolkit, one to perform the receive and one to perform the send.

     

    Socket To Me
    Another type of connection commonly available on J2ME devices is the TCP-based socket connection. Sockets are different than datagrams because they use a connection-based paradigm to transmit data. This means that both a sender and a receiver must be running and establish a communication channel for data to be exchanged. To use a real-world analogy, a socket connection is like calling a friend on the telephone. If the friend does not answer, a conversation cannot take place. Datagrams on the other hand are more like sending a letter to a friend, where a note is placed into an envelope, addressed, and mailed.

    The following code demonstrates how to set up a listener to monitor a port for an inbound socket connection.

    
    try
    {
      ServerSocketConnection ssc = (ServerSocketConnection) 
      Connector.open("socket://:9002");
      StreamConnection sc = null;
      InputStream is = null;
      try{
        sc = ssc.acceptAndOpen();
        is = sc.openInputStream();
        int ch = 0;
        StringBuffer sb = new StringBuffer();
        while ((ch = is.read()) != -1){
          sb.append((char)ch);
        }
        System.out.println(sb.toString());
      } finally{
          ssc.close();
          sc.close();
          is.close();
      }
    } catch (IOException x) {
        x.printStackTrace();
    }
    
    In this example a ServerSocketConnection is opened on port 9002. This type of connection is used for sole purpose of listening for an inbound socket connection. The code goes into a wait state when the acceptAndOpen() method is called. When a socket connection is established, the acceptAndOpen() method returns with an instance of a SocketConnection. Opening an input stream on this connection allows data to be read from the transmission.

    The next example demonstrates the code required by the client to initiate the socket connection.

    
    try{
      SocketConnection sc = (SocketConnection) 
        Connector.open("socket://localhost:9002");
      OutputStream os = null;
      try{
        os = sc.openOutputStream();
        byte[] data = "Hello from a socket!".getBytes();
        os.write(data);
      } finally{
          sc.close();
          os.close();
      }
    } catch (IOException x){
    	x.printStackTrace();
    }
    
    In this example a SocketConnection is established on port 9002 of the local machine. When using sockets, this is the point on the server side that the acceptAndOpen() method returns. If the connection is successfully opened, the OutputStream is obtained and a message is written to the stream. Note that because sockets are connection based, if there is no server listening for an incoming socket connection an exception will be thrown.
     

    Reading Web Content
    The last example will cover reading data using the MIDP HttpConnection. Note that this connection interface is not part of the CLDC or CDC, but is defined rather in the MIDP and Personal Profiles themselves. The behavior of HttpConnection is one that combines an InputStream and an OutputStream into a single connection. A single HttpConnection may open and use exactly one OutputStream and exactly one InputStream. The order in which the streams are used is important as well. The OutputStream, if used, must be used before the InputStream. Once the streams have been used the connection should be closed and a new HttpConnection should be opened to continue communications if necessary. This follows the HTTP request-response paradigm.

    The HttpConnection is a bit more tricky to use than the socket or datagram connections because there is a lot that happens behind the scenes. There are three states to an HttpConnection:

    • Setup
    • Connected
    • Closed
    The setup state is the first state encountered after a connection is opened. While in this state, connection parameters can be set such as the request method (GET, POST or HEAD) using the setRequestMethod() method or any header properties using the setRequestProperty() method.

    The transition from setup to connected is triggered by any methods that cause data to be sent to the server. The following is a list of methods that cause this transition.

    • openInputStream
    • openDataInputStream
    • getLength
    • getType
    • getEncoding
    • getHeaderField
    • getResponseCode
    • getResponseMessage
    • getHeaderFieldInt
    • getHeaderFieldDate
    • getExpiration
    • getDate
    • getLastModified
    • getHeaderField
    • getHeaderFieldKey
    Once the connection transitions to the connected state, any calls to setRequestMethod() and setRequestProperty() will throw an IOException. The state transition from setup to connected reflects the underlying handshake of the HttpConnection as headers are sent to the server and the connection prepares to send data. The following example demonstrates reading Web content from an HttpConnection.
    
    HttpConnection c = null;
    InputStream is = null;
    StringBuffer sb = new StringBuffer();
    try {
      c = (HttpConnection)Connector.open(
         "http://www.gearworks.com”, 
         Connector.READ_WRITE, true);
      c.setRequestMethod(HttpConnection.GET); //default
      is = c.openInputStream(); // transition to connected!
      int ch = 0;
      for(int ccnt=0; ccnt < 150; ccnt++) { // get the title.
        ch = is.read();
        if (ch == -1){
          break;
        }
        sb.append((char)ch);
      }
    }
    catch (IOException x){
    	x.printStackTrace();
    }
    finally{
         try     {
           is.close();
              c.close();
         } catch (IOException x){
              x.printStackTrace();
         }
    }
    System.out.println(sb.toString());
    In this example, the server at www.gearworks.com is contacted. Because this is an HttpConnection and no port is specified, port 80 is used by default. The request method is set to GET (note GET is the default and is explicitly set here only for the example). 
     
     
     
    Knowing When to Use Which Protocol
    As I've just explained, the GCF makes a number of networking options available to applications, but there are a few things you need to know in order to decide which to use when. In the case of MIDP, the specification only requires support for HTTP, although many devices support datagrams and sockets as well, because these protocols are needed to implement HTTP. However, before making commitments to datagrams or sockets it is a good idea to make sure they are supported on the platforms you are targeting. Because HTTP is guaranteed to be supported by MIDP this is usually the best protocol choice due to portability. HTTP moves through firewalls easily since it generally operates over port 80. However, of the three protocols discussed, HTTP incurs the most overhead, which may drive up the user's cost of using the application on the network.

    Datagrams, on the other hand, tend to have far less overhead and can be easier on the end-user's budget. The caveat, as discussed previously, is that the application must take on the task of ensuring that all data arrived at the other end and that the order of that data received is correct.

    Finally, sockets fall somewhere in the middle of HTTP and datagrams in that data sent over a socket is managed by the protocol, but requires fewer network resources than HTTP. This means that the application does not have to concern itself with making sure data is received on the other end. Sockets are generally a lighter-weight option over HTTP since the application controls when the end points communicate. HTTP, on the other hand, must make several trips between the end points to exchange header information as well as the data.

    The GCF provides a lot of functionality and standardizes how connections are established throughout the J2ME architecture. The GCF is extensible as well, allowing manufacturers to support their own interfaces and connection types. In some cases a manufacturer may use the GCF to support streaming multimedia content with a special connection or for establishing connections to a GPS receiver. Having this kind of flexibility prevents J2ME from being constrained to a common set of protocols while maintaining consistency throughout the architecture.

    Page 4 of 4
    Posted by 김용환 '김용환'