I was trying to compile the kernel classes set from DRLVM independently
from the classlib and found it difficult because kernel classes set
currently have a dependence on the internal classlib API, e.g.
org.apache.harmony.luni.internal.net.www.protocol.jar.JarURLConnection
and org.apache.harmony.luni.util.DeleteOnExit classes.
I've found the spec for kernel class org.apache.harmony.kernel.vm.VM
(l'm looking at
classlib\trunk\modules\luni-kernel\src\main\java\org\apache\harmony\kernel\vm\VM.java)
assumes that VM is calling excplicitly JarURLConnection.closeCachedFiles()
and DeleteOnExit.deleteOnExit() during VM shutdown.
On the other hand, there is standard API in J2SE called
java.lang.Runtime.addShutdownHook(Thread) which can be used to specify
the
tasks that have to be done during VM shutdown.
BTW, this is exactly how DRLVM implements these methods in it's
VM.java. For example, for VM.closeJars() it currently does like:
public static void closeJars() {
class CloseJarsHook implements Runnable {
public void run() {
JarURLConnection.closeCachedFiles();
}
}
...
Runtime.getRuntime().addShutdownHook(new Thread(new CloseJarsHook()));
}
Are there any problems with this approach, should the DRLVM (or other
Vm's) implement these methods differently?
May be it makes sense just to move VM.closeJars() and
VM.deleteOnExit() methods and their drlvm implementation to the luni
classlib component, under assumption that they do not really contain
any VM-specific code?
I guess it will simplify a bit the org.apache.harmony.kernel.vm.VM
interface as well as would allow to avoid extra dependencies between
VM and classlib.
--
Andrey Chernyshev
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
