dec00_ericg.txt

TechTips j2me的常用技巧. 网络功能

 J 2 M E    T  E  C  H    T  I  P  S

                      TIPS, TECHNIQUES, AND SAMPLE CODE


WELCOME to the Java Developer Connection(sm) (JDC)
Java(tm) 2 Platform, Micro Edition (J2ME(tm)) 
Tech Tips, for December 18, 2000. This issue covers:

         * The J2ME Development Cycle
         * Making HTTP Connections with MIDP
                  
The J2ME Tech Tips are written by Eric Giguere
(http://www.ericgiguere.com), an engineer at iAnywhere 
Solutions, inc, and author of the book "Java 2 Micro
Edition: Professional Developer's Guide."

You can view this issue of the J2ME Tech Tips on the Web at
http://java.sun.com/jdc/J2METechTips/2000/tt1218.html

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
THE J2ME DEVELOPMENT CYCLE

Java 2 Platform, Micro Edition (J2ME) is a set of technologies 
and specifications that enable Java applications to run on 
devices such as cell phones, Personal Digital Assistants, or 
set top boxes, that are unable to accommodate the Java(tm) 2 
Platform, Standard Edition (J2SE(tm)) runtime environment. These 
devices have severe resource constraints when compared to desktop 
or server computers, limitations that kept the Java Platform off 
these devices until now.

Central to J2ME are the concepts of configurations and profiles. 
A configuration defines the core runtime environment for J2ME 
implementations. It specifies the capabilities of the Java 
Virtual Machine*, a supported subset of J2SE classes, and 
additional J2ME-specific classes. A profile builds on the 
configuration by adding classes and specifying behaviors in 
support of families of specific devices or types of applications.  
A profile can also build on another profile.

How do configurations and profiles affect the normal Java 
development cycle? In some ways there is little change: 
you still use the same tools as before (such as, javac, jar, 
and javadoc). In fact, you need a Java 2 SDK (formerly
known as a JDK), in order to build J2ME applications. The 
J2SE 1.3 SDK is the currently recommended SDK, although
you can use a Java 2 SDK such as JDK 1.2.2. Configurations 
accept standard Java class files and JAR files as input to the 
virtual machine, which is why the J2SE tools can be used.

What's different are the options you use when invoking the Java 
compiler. Placing the configuration classes in the compiler's 
class path won't work, because the compiler automatically 
searches the J2SE core classes first, regardless of what's in the 
class path. This means that the compiler won't catch any 
references to classes or methods that are missing from 
a particular J2ME configuration, leading to runtime errors when 
you deploy your application.

The solution is simple: use the -bootclasspath option to replace 
the J2SE classes with the J2ME classes. As an example, you can 
apply this to the Connected Limited Device Configuration (CLDC).
Assuming that you've installed the CLDC reference implementation
on your machine, and defined a CLDC_HOME environment variable, 
you compile a CLDC application like this under Windows:

    javac -bootclasspath %CLDC_HOME%\bin\api\classes *.java
    
On Solaris, you use:

    javac -bootclasspath $CLDC_HOME/bin/api/classes *.java
    
To keep the class files as small as possible, you normally
also use the -g:none option to remove all debugging
information.

If you compile your J2ME application to use the Connected Device 
Configuration (CDC) instead of the CLDC, use the CDC classes,
instead of the CLDC classes, with the -bootclasspath option.  
If you compile against a particular profile, just add the 
profile's classes to the boot class path.

For CLDC-based applications, there is an additional step to
follow after compiling your Java source code. The CLDC includes 
a new Java virtual machine (VM) called the K Virtual Machine 
or KVM for short. The KVM is a completely new implementation of 
a Java virtual machine, designed from the start to work on 
resource-constrained devices. One of the things it does is change 
how classes are verified, or checked for correctness. Instead of 
running the complete verification process on the device, most of 
it is done offline, using a tool called a preverifier. The 
preverifier does the actual verification and inserts extra 
information into the class files. (Note that the modifications 
are transparent to non-KVM virtual machines.) The KVM looks for 
this information and uses it to perform a much simpler 
verification based on the data collected by the preverifier.

You can find the preverifier in the bin of the CLDC reference 
implementation. On Windows you invoke the preverifier (on
a single line, of course) like this:

    %CLDC_HOME%\bin\preverify -classpath %CLDC_HOME%\bin\api\classes
        -d verified dir-or-class-list

The syntax for Solaris is similar, just adjust the paths and
the environment variable expansion. The options are similar to
those of javac: 

o The -classpath option lists the directories (note that the 
  current version of the preverifier doesn't handle JAR files) 
  in which to find referenced classes.
  
o The -d option defines the output directory for the preverified 
  classes.
  
o The dir-or-class-list argument is the set of directory and/or
  class names to preverify. Directories are searched recursively
  for any class files.

When preverifying classes, be sure to keep the unverified and
the preverified classes separate. It's usually best to keep them
in separate directories. For example, say you define a simple
HelloWorld.java source file:

    public class HelloWorld {
        public static void main( String[] args ){
            System.out.println( "Hello, world!" );
        }
    }
    
You could compile and preverify it in Windows as follows, assuming 
that the CLDC's bin directory is in your path:

    javac -g:none -bootclasspath %CLDC_HOME%\bin\api\classes 
          -d unverified HelloWorld.java
    
    preverify -classpath %CLDC_HOME%\bin\api\classes 
          -d preverified unverified

In Solaris:

    javac -g:none -bootclasspath $CLDC_HOME/bin/api/classes 
          -d unverified HelloWorld.java

    preverify -classpath $CLDC_HOME/bin/api/classes
          -d preverified unverified	  

The HelloWorld.class in the preverified directory is the one you 
actually want to run:

In Windows:

    kvm -classpath preverified;%CLDC_HOME%\bin\api\classes HelloWorld

In Solaris:

    kvm -classpath preverified:$CLDC_HOME/bin/api/classes HelloWorld
    
Apart from these few changes, developing in J2ME is almost the
same as developing in J2SE, making the transition to Java 
programming for small devices relatively simple. 

There is also a toolkit, called the J2ME Wireless Toolkit, that 
can further simplify the J2ME development process. For more 
information about the J2ME Wireless Toolkit, see 
http://java.sun.com/products/j2mewtoolkit/.

For further information on the J2ME development cycle, see
the white paper Java 2 Micro Edition (J2ME) Technology for
Creating Mobile Devices 
(http://java.sun.com/products/cldc/wp/KVMwp.pdf). 

For further information about the Connected Limited Device 
Configuration (CLDC), see http://java.sun.com/products/cldc/.

Also visit the Consumer & Embedded Technology Center 
(http://java.sun.com/jdc/products/j2me/)
for articles, tutorials, and other resources on J2ME technologies.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
MAKING HTTP CONNECTIONS WITH MIDP 

HTTP connectivity is one of the requirements of the Mobile 
Information Device Profile (MIDP). A MIDP-enabled device must be 
able to interact with a web server through conventional HTTP 
requests. If the network doesn't directly support HTTP, then the 
device must route its requests through a gateway. But this is all
transparent to the application developer.

In the MIDP, you interact with the network using the Generic 
Connection framework. (This is true for any profile built on 
top of the Connected Limited Device Configuration (CLDC)). The 
framework is a set of classes and interfaces defined by the CLDC 
that replaces most of the java.io and java.net classes defined 
by J2SE.