Class.forname()

java-programmer, Class.forname() Hello ,
I have a necessity to delete a jar file which is in the CLASSPATH.
But JVM locks it after a class.forName() call, even though the class
loaded is NOT in the JAR file I want to delete. ( I cannot remove the
JAR file from the CLASSPATH )

First of all is it possible?

Any help is appreciated

thanks in advance

java-programmer >> Class.forname()
"Phoneix" <email***@***.com> wrote in message
news:email***@***.com...
> Hello ,
> I have a necessity to delete a jar file which is in the CLASSPATH.
> But JVM locks it after a class.forName() call, even though the class
> loaded is NOT in the JAR file I want to delete. ( I cannot remove the
> JAR file from the CLASSPATH )
>
> First of all is it possible?

I would guess that what's really happening is that the Class.forName ()
opens the jars in the classpath and keeps them open for future queries.
They should be released when the application halts. Can you describe what
you're really trying to accomplish and why you need to modify the jars of a
program that is running?

Cheers,
Matt Humphrey email***@***.com http://www.iviz.com/

java-programmer >> Class.forname() >
> I would guess that what's really happening is that the Class.forName ()
> opens the jars in the classpath and keeps them open for future queries.
> They should be released when the application halts. Can you describe what
> you're really trying to accomplish and why you need to modify the jars of a
> program that is running?
>
> Cheers,
> Matt Humphrey email***@***.com http://www.iviz.com/

thanks for the reply Matt.
Yes, We have an application which acts as a launcher for many other
applications. One of the applications which gets launched is an Value
Objects generation tool which regenerates the jar file if the customer
makes changes to the value objects. Trouble is this jar is in the
class path of the launcher which is required for other tools.
To complicate matters we are not using Class.forname() actually. We
are using JNI's equivalent of jinenv->findClass() . ( since our apps
has both C++ and Java parts ) Complicated enough ? :-) . WE donot
know how to close the file handles for the JAR files opened during the
findclass() search by the systemClassLoader. We though of writing a
custom class loader but how to we hook up that to "jvm.dll" which is
what we load from our C++ program.( And then do a create_JVM call etc
).
Every text talks about how there 3 classloaders gets into action or
what is heirarchy of search etc but no one talks how to release the
handles opened during a search for class. Funny thing is even if you
do a resolve or find for a non-existent class name , JVM locks the JAR
files . I tried forcing GC hoping since there is no reference anywhere
to the class and the lock will be released , nope the file locks are
firm as ever .
Coming from a assembly/C++ background these lack of control is
frustrating :-)

java-programmer >> Class.forname() Phoneix wrote:
> Hello ,
> I have a necessity to delete a jar file which is in the CLASSPATH.
> But JVM locks it after a class.forName() call, even though the class
> loaded is NOT in the JAR file I want to delete. ( I cannot remove the
> JAR file from the CLASSPATH )
>
> First of all is it possible?
>

I think this is because of the aggressive caching strategy adopted by the
classes in the java.util.jar (and java.util.zip) package. And the caching
code is in the native part of the library - so you can't even create a
custom classloader by simply extending the jar classes - you probably
have to rewrite the ZIP classes :-(

There are several side effects of this if you're trying to use the zip/jar
library code even in applications other than classloading. For example, if you
open a ZIP file, add some more files to it, *and close it*, reopening it a
second time will not even show the new entries !! (Even though the zip file does
have the new data in it) - There were several open bug reports about this at
Sun. (Haven't checked if this is fixed in the 1.5 betas)

BK

java-programmer >> Class.forname() Phoneix wrote:
>
> Yes, We have an application which acts as a launcher for many other
> applications. One of the applications which gets launched is an Value
> Objects generation tool which regenerates the jar file if the customer
> makes changes to the value objects. Trouble is this jar is in the
> class path of the launcher which is required for other tools.
> To complicate matters we are not using Class.forname() actually. We
> are using JNI's equivalent of jinenv->findClass() . ( since our apps
> has both C++ and Java parts ) Complicated enough ? :-) . WE donot
> know how to close the file handles for the JAR files opened during the
> findclass() search by the systemClassLoader. We though of writing a
> custom class loader but how to we hook up that to "jvm.dll" which is
> what we load from our C++ program.( And then do a create_JVM call etc
> ).
> Every text talks about how there 3 classloaders gets into action or
> what is heirarchy of search etc but no one talks how to release the
> handles opened during a search for class. Funny thing is even if you
> do a resolve or find for a non-existent class name , JVM locks the JAR
> files . I tried forcing GC hoping since there is no reference anywhere
> to the class and the lock will be released , nope the file locks are
> firm as ever .

I really doubt that you are going to be able to get the system classloader to loosen its
grip on jar files in the classpath. You're going to have to write your own classloader.
Give the system classloader a 'rump' classpath (that includes your classloader) without
those jar files. Your classloader can then provide the capability to release jar files
under its control. Your JNI won't be able to load things directly. It will need to go
through a Java wrapper (also on the rump classpath) to do the loading with your custom
classloader.

--
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)

java-programmer >> Class.forname() Babu Kalakrishnan <email***@***.com> wrote in message news:<email***@***.com>...
> Phoneix wrote:
> > Hello ,
> > I have a necessity to delete a jar file which is in the CLASSPATH.
> > But JVM locks it after a class.forName() call, even though the class
> > loaded is NOT in the JAR file I want to delete. ( I cannot remove the
> > JAR file from the CLASSPATH )
> >
> > First of all is it possible?
> >
>
> I think this is because of the aggressive caching strategy adopted by the
> classes in the java.util.jar (and java.util.zip) package. And the caching
> code is in the native part of the library - so you can't even create a
> custom classloader by simply extending the jar classes - you probably
> have to rewrite the ZIP classes :-(
>
>

thanks for the reply Babu ,
just curious, how do look at the source , decompiler or is the source
available somewhere ? thanks

java-programmer >> Class.forname() >
> I really doubt that you are going to be able to get the system classloader to loosen its
> grip on jar files in the classpath. You're going to have to write your own classloader.
> Give the system classloader a 'rump' classpath (that includes your classloader) without
> those jar files. Your classloader can then provide the capability to release jar files
> under its control. Your JNI won't be able to load things directly. It will need to go
> through a Java wrapper (also on the rump classpath) to do the loading with your custom
> classloader.

thanks Lee. I was thinking along the same lines except the "rump"
class path to the system loader. That was the key as even after the
custom class loader and java wrapper , to load the Java wrapper , JNI
will use the system class loader and if I give the "actual" class path
, files get lock again . So I was confused ! :-) Your idea of giving
a "fake" class path to system class loader will make it work !

java-programmer >> Class.forname() Phoneix wrote:
>
> thanks for the reply Babu ,
> just curious, how do look at the source , decompiler or is the source
> available somewhere ? thanks

The source code for the (public) Java portion is available in your JDK
distribution itself.

For the rest of the stuff - i.e sun private classes and the native code, you
can download them from java.sun.com after signing a licence agreement.

BK

java-programmer >> Class.forname() Phoneix wrote:
>
> thanks Lee. I was thinking along the same lines except the "rump"
> class path to the system loader. That was the key as even after the
> custom class loader and java wrapper , to load the Java wrapper , JNI
> will use the system class loader and if I give the "actual" class path
> , files get lock again . So I was confused ! :-) Your idea of giving
> a "fake" class path to system class loader will make it work !

To clarify: using a 'rump' classpath (that is, shortening the classpath used by the
system classloader to exclude the jar files of concern) is crucial because:

1) In general, the system classloader will 'lock' any jar files provided on the system
classpath.

2) A standard implementation of a custom classloader defers first to its parent
classloader (ultimately, the system classloader) when it needs to retrieve a previously
unloaded class. Thus, classes in the specific jar file will still get loaded by the
system classloader.

The second situation can be solved by writing a non-standard classloader which does not
defer first to its parent. It's slightly clumsy but possible. However, the first
situation cannot be resolved (except with the rump classpath) because there is no way to
change the functionality of the system classloader.

--
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)