Java runs from jar files. There is no advantage in "unpacking" them as you suggest. The jvm itself is contained in a clutch of jar files. Java classloaders that handle jar files can decompress from the jar file only the class files needed by the application directly into memory. There's actually less work finding a class within the jar file directory than there is finding it in a file system directory.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Chris Bipes
Sent: Wednesday, February 06, 2013 1:27 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: class path question
Would it not be a better practice to unpack the jar file? That way when you load the classes, you do not have to unpack them within the job start? I just have not seen anyone recommend that but I do like your explanation Scott. I also like that you can search within a JAR file but I don't think that would be best practice, would it?
Chris Bipes
Director of Information Services
CrossCheck, Inc.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Wednesday, February 06, 2013 10:57 AM
To: Midrange Systems Technical Discussion
Subject: Re: classpath question
Hi Tim,
First of all, you don't want /QIBM/UserData/Java400/ext in your CLASSPATH. That directory is for "java extensions" that are always loaded in all Java invocations. So stuff there is ALWAYS loaded, no matter what the application is, and is completely separate from the classpath.
The reason you don't want to use that directory for everything, even though it seems simple, is it can cause version conflicts. Your whole system uses /QIBM/USerData/JAva400/ext, so if one piece of software needs one version of something, and another piece needs another version of something, you'd be in trouble if it's in "ext". Not to mention that loading unnecessary code with every Java program is inefficient.
As for the CLASSPATH itself -- remember it's a list of places to look for Java classes. Just as a library list is a list of places to look for programs (et al). Each thing in the classpath is a "container"
(much like a library is a container for programs).
a JAR file is a ZIP file containing many Java "CLASS" objects. So it is a container -- just like a library would be.
You can also put CLASS files directly in an IFS directory and reference it.
But you can't just reference a directory that contains JAR files.. you have to list the files themselves, because JARs are containers. They're not the CLASS files themselves.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
