⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 may01_ericg.txt

📁 TechTips j2me的常用技巧. 网络功能
💻 TXT
📖 第 1 页 / 共 3 页
字号:
                        // Send pong message to the peer
                           sendPong();
                    } else {
                        // Don't know what type of message this was
                        System.out.println("     Unknown message");
                    }
                }

                inputStream.close();
                outputStream.close();
                socket.close();

            } catch (IOException ioe) {
                ioe.printStackTrace();
                break;
            }
        }

    }

    static void sendPong() {
        byte[]  dataBuffer = PONG_MSG.getBytes();

        try {
            outputStream.write(dataBuffer, 0, dataBuffer.length);
            outputStream.flush();
            System.out.println("Sent: "+ PONG_MSG);
        } catch (Exception e) {
          e.printStackTrace();
        }
    }

}

You will also need a policy file and a security properties file 
to run the application. Use the following policy file 
(java.policy):

grant {
        permission java.net.SocketPermission "*:1024-65535", 
                "connect,accept,listen,resolve";
};

// Standard extensions get all permissions by default

grant codeBase "file:${java.home}/lib/ext/*" {
        permission java.security.AllPermission;
};

// default permissions granted to all domains

grant { 
        // Allows any thread to stop itself using the 
        // java.lang.Thread.stop() method that takes no argument.
        // Note that this permission is granted by default only 
        // to remain backwards compatible.
        // It is strongly recommended that you either remove this 
        // permission from this policy file or further restrict 
        // it to code sources that you specify, because 
        // Thread.stop() is potentially unsafe.
        // See "http://java.sun.com/notes" for more information.
        permission java.lang.RuntimePermission "stopThread";

        // allows anyone to listen on un-privileged ports
        permission java.net.SocketPermission "localhost:1024-", 
                                                        "listen";

        // "standard" properies that can be read by anyone

        permission java.util.PropertyPermission "java.version", 
                                                          "read";
        permission java.util.PropertyPermission "java.vendor", 
                                                          "read";
        permission java.util.PropertyPermission 
                                       "java.vendor.url", "read";
        permission java.util.PropertyPermission 
                                    "java.class.version", "read";
        permission java.util.PropertyPermission 
                                               "os.name", "read";
        permission java.util.PropertyPermission 
                                            "os.version", "read";
        permission java.util.PropertyPermission "os.arch", 
                                                          "read";
        permission java.util.PropertyPermission "file.separator", 
                                                          "read";
        permission java.util.PropertyPermission "path.separator", 
                                                          "read";
        permission java.util.PropertyPermission "line.separator", 
                                                          "read";

        permission java.util.PropertyPermission 
                            "java.specification.version", "read";
        permission java.util.PropertyPermission 
                             "java.specification.vendor", "read";
        permission java.util.PropertyPermission 
                               "java.specification.name", "read";

        permission java.util.PropertyPermission 
                         "java.vm.specification.version", "read";
        permission java.util.PropertyPermission 
                          "java.vm.specification.vendor", "read";
        permission java.util.PropertyPermission 
                            "java.vm.specification.name", "read";
        permission java.util.PropertyPermission 
                                       "java.vm.version", "read";
        permission java.util.PropertyPermission "
                                         java.vm.vendor", "read";
        permission java.util.PropertyPermission "java.vm.name", 
                                                          "read";
};


Use the following master security properties file 
(java.security):


#
# This is the "master security properties file".
#
# In this file, various security properties are set for use by
# java.security classes. This is where users can statically 
# register Cryptography Package Providers ("providers" for short). 
# The term "provider" refers to a package or set of packages that 
# supply a concrete implementation of a subset of the cryptography 
# aspects of the Java Security API. A provider may, for example, 
# implement one or more digital signature algorithms or message 
# digest algorithms.
#
# Each provider must implement a subclass of the Provider class.
# To register a provider in this master security properties file, 
# specify the Provider subclass name and priority in the format
#
#    security.provider.<n>=<className> 
#
# This declares a provider, and specifies its preference 
# order n. The preference order is the order in which providers are 
# searched for requested algorithms (when no specific provider is 
# requested). The order is 1-based; 1 is the most preferred, 
# followed by 2, and so on.
#
# <className> must specify the subclass of the Provider class whose 
# constructor sets the values of various properties that are 
# required for the Java Security API to look up the algorithms or 
# other facilities implemented by the provider.
# 
# There must be at least one provider specification in 
# java.security. There is a default provider that comes standard 
# with the JDK. It is called the "SUN" provider, and its Provider 
# subclass named Sun appears in the sun.security.provider package. 
# Thus, the "SUN" provider is registered via the following:
#
#    security.provider.1=sun.security.provider.Sun 
#
# (The number 1 is used for the default provider.) 
#
# Note: Statically registered Provider subclasses are 
# instantiated when the system is initialized. Providers can be 
# dynamically registered instead by calls to either the addProvider 
# or insertProviderAt method in the Security class.

#
# List of providers and their preference orders (see above):
#
security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.rsajca.Provider

#
# Class to instantiate as the system Policy. This is the name of 
# the class that will be used as the Policy object.
#
policy.provider=sun.security.provider.PolicyFile

# The default is to have a single system-wide policy file, 
# and a policy file in the user's home directory.
policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy

# whether or not we expand properties in the policy file
# if this is set to false, properties (${...}) will not be expanded 
# in policy files.
policy.expandProperties=true

# whether or not we allow an extra policy to be passed on the 
# command line with -Djava.security.policy=somefile. Comment out 
# this line to disable this feature.
policy.allowSystemProperty=true

# whether or not we look into the IdentityScope for trusted 
# Identities when encountering a 1.1 signed JAR file. If the 
# identity is found and is trusted, we grant it AllPermission.
policy.ignoreIdentityScope=false

#
# Default keystore type.
#
keystore.type=jks

#
# Class to instantiate as the system scope:
#
system.scope=sun.security.provider.IdentityDatabase

#
# List of comma-separated packages that start with or equal this 
# string will cause a security exception to be thrown when
# passed to checkPackageAccess unless the corresponding 
# RuntimePermission ("accessClassInPackage."+package) has
# been granted.
package.access=sun.

#
# List of comma-separated packages that start with or equal this 
# string will cause a security exception to be thrown when
# passed to checkPackageDefinition unless the corresponding
# RuntimePermission ("defineClassInPackage."+package) has
# been granted.
# 
# by default, no packages are restricted for definition, and none 
# of the class loaders supplied with the JDK call 
# checkPackageDefinition.
#
#package.definition=

 
To build the application:

1. Download Foundation Profile version 1.0 from: 
http://www.sun.com/software/communitysource/j2me/cdc/download.html
   (The CDC is bundled with the Foundation Profile in the 
   download.)

2. Compile the Foundation Profile. Follow the instructions in the
   download. (This builds the CDC as well as the Foundation 
   Profile.)
   
3. Make a security subdirectory in the build/<platform>/lib 
   directory. For example:
   
   mkdir build/linux/lib/security
    
4. Copy java.policy and java.security to the security 
   subdirectory. For example:

   cp java.policy build/linux/lib/security
   cp java.security build/linux/lib/security   
   
5. Compile the application source code using Java 2 SDK version 
   1.3. Run javac as usual, but use the -bootclasspath option 
   instead of the -classpath option to include the Foundation 
   Profile classes. The -bootclasspath option excludes the 
   standard J2SE classes from the compilation, which makes it 
   possible to detect your application's use of classes and 
   methods not defined in the CDC or the Foundation Profile.
   
   cd <your_test_dir>
   javac -bootclasspath \ 
   <cdcfoundation_dir>/build/linux/lib/foundation.jar:\
        <cdcfoundation_dir>/build/linux/btclasses.zip \
        PeerListener.java \
        PeerFinder.java

6. Run PeerListener:

   cd <cdcfoundation_dir>/build/linux/bin
   cvm -Djava.class.path=<your_test_dir> PeerListener
  
   You'll see the following line displayed in the window: 
   
     Listening for peer finder connection... 
   
In another window, run PeerFinder:

   cd <cdcfoundation_dir>/build/linux/bin
   cvm -Djava.class.path=<your_test_dir> PeerFinder
 
   You'll see the following lines displayed in the window: 
   
     Sent: ping
     Listening for return message...
     Received peer listener reply: pong   

Some things to note about this example:

o It uses J2SE-style APIs (java.net.Socket and 
  java.net.ServerSocket). Unlike the case for CLDC, there is no 
  need to learn the Generic Connection Framework API.  
o It uses buffered input and output streams. This makes for 
  faster I/O.
o It complies with J2SE-style security (including use of a policy 
  file and the default Security Manager).
o It can be compiled and run on both J2SE and CDC-Foundation 
  Profile. 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
HANDLING MULTIPLE SIMULTANEOUS MIDP ALERTS

The April 16, 2001 issue of the J2ME Tech Tips introduced you to 
timers and alerts. If you write a multithreaded MIDP application 
-- whether you spawn the threads yourself or use timers to 
schedule background tasks -- it's easy to trigger two or more 
alerts simultaneously. In other words, while one alert is being 
displayed, a second alert is triggered. Dealing with this 
situation is not as simple as you might think. Alerts are 
displayed using the two-argument form of the Display object's 
setCurrent method, as in the following:

Display     display = ...;
Alert       alert = ...;
Displayable next = ...;

display.setCurrent( alert, next );

The first argument is the alert to display and the second is the 
screen object to display after the alert is dismissed or times 
out. The second argument is referred to as the "alert 

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -