in black and white
Main menu
Share a book About us Home
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

More Java Pitfalls Share Reactor - Daconta M,C.

Daconta M,C. More Java Pitfalls Share Reactor - Wiley publishing, 2003. - 476 p.
ISBN: 0-471-23751-5
Download (direct link): morejavapitfallssharereactor2003.pdf
Previous << 1 .. 38 39 40 41 42 43 < 44 > 45 46 47 48 49 50 .. 166 >> Next

Manifest-Version: 1.0
Main-Class: Example
Created-By: 1.3.1
Why doesn't this work? First, it is important to recognize that the command-line ("java Example") invocation of the JVM uses the same CLASSPATH as the compiler. So, obviously, if it compiled then, it will run.
The Failure to Execute 109
However, double-clicking on a JAR file, or executing java -jar (except in the JDK HOME\bin directory), attempts to use the JRE, which has its own CLASSPATH. So, the additional necessary JARs can be placed in the JRE HOME\lib\ext directory. Note that it is not the lib directory itself, unlike the JDK.
However, unless you want to install the classes into that directory, you should add them into your JAR file and reference them in the JAR's manifest file.
Manifest-Version: 1.0
Main-Class: Example
Class-Path: jaxp.jar xalan.jar xerces.jar
Created-By: 1.3.1
Deploying Java Applications
A tremendous number of problems in installing, configuring, and running Java applications has to do with the misunderstanding of how to specify how the JVM should find classes to load. The first method used looks like the one found in Listing 13.1.
01 APPDATA=C:\Documents and Settings\crichardson\Application Data
02 CLASSPATH=D:\soap-2_2;C:\Program Files\Apache Tomcat
03 CommonProgramFiles=C:\Program Files\Common Files
05 ComSpec=C:\WINNT\system32\cmd.exe
08 OS=Windows_NT
09 [... ]
Listing 13.1 Environment variables
This shows the classic and traditional way of handling the Java CLASSPATH. Set an environment variable, or rather, add to the already existing environment variable. A number of other environment variables were left in this example to highlight how broad the spectrum of things stored in the environment is and the number of applications that must make use of it.
Furthermore, we have one CLASSPATH that all applications use. This provides a major issue for deploying applications, because there are possible conflicts that can occur among executable JAR files. This is just the Java version of the "DLL hell" phenomenon—not only for the presence or absence of JAR files, but also the difference in versions of JAR files.
Another mechanism that is used for assembling a CLASSPATH is the -cp switch in executing the Java Virtual Machine execution.
110 Item 13
C:\j2sdk1.4.0\jre\bin\javaw -cp
1.0\jaxm\client.jar" org.javapitfalls.jar.Example
While this option allows for a more explicit and direct way to control the CLASSPATH for your application, it still is neither very user-friendly nor very configuration-friendly. In effect, this is what happens with a lot of applications; everyone packages their own JAR files and references them using the CLASSPATH JVM option in order to control what is available in their applications.
However, this can lead to a great deal of redundancy. For example, I searched for "xerces*.jar" on my development machine. This would capture all of the versions of the popular Apache XML parsing API Xerces. Granted, a development box is not exactly the most representative example of a deployment machine, but I got 73 instances of Xerces. Basically, every Java application running on my machine that uses XML, some of which are not development tools or APIs, has a copy of Xerces to process XML. Those 73 instances take up 108 MB of disk space, to do essentially the same thing.
What if there is a bug fix out for Xerces that needs to be integrated into my applications, or even bigger, a performance improvement. I have to copy it to 73 different places in my application. Furthermore, with the introduction of XML into JDK 1.4, there is a potential for class conflicts. This is because the Java platform has evolved to the point where it provides new features, and XML processing is part of it.
So, why not be able to extend the platform? Earlier, we discussed an example of what people do wrong in creating an executable JAR file. Those mistakes are due to poor understanding of the Java extension mechanism.
The Java Extension Mechanism
The Java Extension Mechanism is how developers can extend the Java platform without having to worry about the issues concerning the CLASSPATH. The most obvious way to create an extension is to copy a JAR file into the JRE HOME/lib/ext directory. Furthermore, Java Plug-in and Java Web Start provide facilities for installing extensions on demand and automatically.
Previous << 1 .. 38 39 40 41 42 43 < 44 > 45 46 47 48 49 50 .. 166 >> Next