可是今天我把j2ee.jar从classpath中移到$JAVA_HOME/jre/lib/ext/里后,重启以后再启动j2ee,就报错了..... 类似于下面这种 No local string for j2ee.listenPort J2EE server listen port: 1050 No local string for j2ee.naming Naming service started: 1050 No local string for enterprise.log.logging.serverversion.started No local string for enterprise.log.using.vm.name.version.from No local string for enterprise.log.vm's.classpath不知道如果把所有的.jar从classpath中移到$JAVA_HOME/jre/lib/ext/,还会有什么事发生,所以现在很是疑惑两者的区别之处.
How the Java Launcher Finds Classes The Java launcher, java, initiates the Java virtual machine. The virtual machine searches for and loads classes in this order: Bootstrap classes - Classes that comprise the Java platform, including the classes in rt.jar and i18n.jar. Extension classes - Classes that use the Java Extension mechanism. These are bundled as .jar files located in the extensions directory. User classes - Classes defined by developers and third parties that do not take advantage of the extension mechanism. You identify the location of these classes using the -classpath option on the command line the preferred method) or by using the CLASSPATH environment variable. (See Setting the Classpath for Windows or Solaris.) In effect, these three search paths are joined to form a simple class path. This is similar to the "flat" class path previously used, but the current model has some important differences: It is relatively difficult to accidentally "hide" or omit the bootstrap classes. In general, you only have to specify the location of user classes. Bootstrap classes and extension classes are found "automatically". The tools classes are now in a separate archive (tools.jar) and can only be used if included in the user class path (to be explained shortly). How the Java Launcher Finds Bootstrap Classes Bootstrap classes are the classes that implement the Java 1.2 platform. Bootstrap classes are in the rt.jar and i18n.jar archives in /jdk1.2/jre/lib. These archives are specified by the value of the bootstrap class path which is stored in the sun.boot.class.path system property. This system property is for reference only, and should not be directly modified.It is very unlikely that you will need to redefine the bootstrap class path. The nonstandard option, -Xbootclasspath, allows you to do so in those rare cicrcumstances in which it is necessary to use a different set of core classes.Note that the classes which implement the JDK development tools are in separate archive from the bootstrap classes. The tools archive is /jdk1.2/lib/tools.jar. The development tools add this archive to the user class path when invoking the launcher. However, this augmented user class path is only used to execute the tool. The tools that process source code, javac and javadoc, use the orginal class path, not the augmented version. (For more information, see How Javac and Javadoc Find Classes, below.) How the Java Launcher Finds Extension Classes Extension classes are classes which extend the Java platform. Every .jar file in the extension directory, jre/lib/ext, is assumed to be an extension and is loaded using the Java Extension Framework. Loose class files in the extension directory will not be found. They must be contained in a .jar file (or .zip file). There is no option provided for changing the location of the extension directory. If the jre/lib/ext directory contains multiple .jar files, and those files contain classes with the same name, such as: smart-extension1_0.jar contains class smart.extension.Smart smart-extension1_1.jar contains class smart.extension.Smart the class that actually gets loaded is undefined. How the Java Launcher Finds User Classes User classes are classes which build on the Java platform. To find user classes, the launcher refers to the user class path -- a list of directories, JAR archives, and ZIP archives which contain class files.A class file has a subpath name that reflects the class's full-qualified name. For example, if the class com.mypackage.MyClass is stored under /myclasses, then /myclasses must be in the user class path and the full path to the class file must be /myclasses/com/mypackage/MyClass.class. If the class is stored in an archive named myclasses.jar, then myclasses.jar must be in the user class path, and the class file must be stored in the archive as com/mypackage/MyClass.class.On Solaris, the user class path is specified as a string, with a colon (:) separating the class path entries. The java launcher puts the user class path string in the java.class.path system property. The possible sources of this value are: The default value, ".", meaning that user class files are all class files in the current directory (or under it, if in a package). The value of the CLASSPATH environment variable, which overrides the default value. The value of the -cp or -classpath command line option, which overrides both the default value and the CLASSPATH value. The JAR archive specified by the -jar option, which overrides all other values. If this option is used, all user classes come from the specified archive. How the Java Launcher Finds JAR-class-path Classes A JAR file usually contains a "manifest" -- a file which lists the contents of the JAR. The manifest can define a JAR-class-path, which further extends the class path (but only while loading classes from that JAR). Classes accessed by a JAR-class-path are found in the following order:In general, classes referenced by a JAR-class-path entry are found as though they were part of the JAR file. The JAR files that appear in the JAR-class-path are searched after any earlier class path entries, and before any entries that appear later in the class path. However, if the JAR-class-path points to a JAR file that was already searched (for example, an extension, or a JAR file that was listed earlier in the class path) then that JAR file will not be searched again. (This optimization improves efficiency and prevents circular searches.) Such a JAR file is searched at the point that it appears, earlier in the class path. If a JAR file is installed as an extension in the jdk's ext subdirectory, then any JAR-class-path it defines is ignored. All the classes required by an extension are presumed to be part of the JDK or to have themselves been installed as extensions.
效果应该是一样的吧。
类似于下面这种
No local string for j2ee.listenPort
J2EE server listen port: 1050
No local string for j2ee.naming
Naming service started: 1050
No local string for enterprise.log.logging.serverversion.started
No local string for enterprise.log.using.vm.name.version.from
No local string for enterprise.log.vm's.classpath不知道如果把所有的.jar从classpath中移到$JAVA_HOME/jre/lib/ext/,还会有什么事发生,所以现在很是疑惑两者的区别之处.
$JAVA_HOME/jre/lib/ext/也是一个固定的classpath罢了
The Java launcher, java, initiates the Java virtual machine. The virtual machine searches for and loads classes in this order: Bootstrap classes - Classes that comprise the Java platform, including the classes in rt.jar and i18n.jar. Extension classes - Classes that use the Java Extension mechanism. These are bundled as .jar files located in the extensions directory. User classes - Classes defined by developers and third parties that do not take advantage of the extension mechanism. You identify the location of these classes using the -classpath option on the command line the preferred method) or by using the CLASSPATH environment variable. (See Setting the Classpath for Windows or Solaris.)
In effect, these three search paths are joined to form a simple class path. This is similar to the "flat" class path previously used, but the current model has some important differences: It is relatively difficult to accidentally "hide" or omit the bootstrap classes. In general, you only have to specify the location of user classes. Bootstrap classes and extension classes are found "automatically". The tools classes are now in a separate archive (tools.jar) and can only be used if included in the user class path (to be explained shortly). How the Java Launcher Finds Bootstrap Classes
Bootstrap classes are the classes that implement the Java 1.2 platform. Bootstrap classes are in the rt.jar and i18n.jar archives in /jdk1.2/jre/lib. These archives are specified by the value of the bootstrap class path which is stored in the sun.boot.class.path system property. This system property is for reference only, and should not be directly modified.It is very unlikely that you will need to redefine the bootstrap class path. The nonstandard option, -Xbootclasspath, allows you to do so in those rare cicrcumstances in which it is necessary to use a different set of core classes.Note that the classes which implement the JDK development tools are in separate archive from the bootstrap classes. The tools archive is /jdk1.2/lib/tools.jar. The development tools add this archive to the user class path when invoking the launcher. However, this augmented user class path is only used to execute the tool. The tools that process source code, javac and javadoc, use the orginal class path, not the augmented version. (For more information, see How Javac and Javadoc Find Classes, below.)
How the Java Launcher Finds Extension Classes
Extension classes are classes which extend the Java platform. Every .jar file in the extension directory, jre/lib/ext, is assumed to be an extension and is loaded using the Java Extension Framework. Loose class files in the extension directory will not be found. They must be contained in a .jar file (or .zip file). There is no option provided for changing the location of the extension directory.
If the jre/lib/ext directory contains multiple .jar files, and those files contain classes with the same name, such as: smart-extension1_0.jar contains class smart.extension.Smart
smart-extension1_1.jar contains class smart.extension.Smart
the class that actually gets loaded is undefined.
How the Java Launcher Finds User Classes
User classes are classes which build on the Java platform. To find user classes, the launcher refers to the user class path -- a list of directories, JAR archives, and ZIP archives which contain class files.A class file has a subpath name that reflects the class's full-qualified name. For example, if the class com.mypackage.MyClass is stored under /myclasses, then /myclasses must be in the user class path and the full path to the class file must be /myclasses/com/mypackage/MyClass.class. If the class is stored in an archive named myclasses.jar, then myclasses.jar must be in the user class path, and the class file must be stored in the archive as com/mypackage/MyClass.class.On Solaris, the user class path is specified as a string, with a colon (:) separating the class path entries. The java launcher puts the user class path string in the java.class.path system property. The possible sources of this value are: The default value, ".", meaning that user class files are all class files in the current directory (or under it, if in a package). The value of the CLASSPATH environment variable, which overrides the default value. The value of the -cp or -classpath command line option, which overrides both the default value and the CLASSPATH value. The JAR archive specified by the -jar option, which overrides all other values. If this option is used, all user classes come from the specified archive. How the Java Launcher Finds JAR-class-path Classes
A JAR file usually contains a "manifest" -- a file which lists the contents of the JAR. The manifest can define a JAR-class-path, which further extends the class path (but only while loading classes from that JAR). Classes accessed by a JAR-class-path are found in the following order:In general, classes referenced by a JAR-class-path entry are found as though they were part of the JAR file. The JAR files that appear in the JAR-class-path are searched after any earlier class path entries, and before any entries that appear later in the class path. However, if the JAR-class-path points to a JAR file that was already searched (for example, an extension, or a JAR file that was listed earlier in the class path) then that JAR file will not be searched again. (This optimization improves efficiency and prevents circular searches.) Such a JAR file is searched at the point that it appears, earlier in the class path. If a JAR file is installed as an extension in the jdk's ext subdirectory, then any JAR-class-path it defines is ignored. All the classes required by an extension are presumed to be part of the JDK or to have themselves been installed as extensions.