Andrey Chernyshev wrote:
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?
There is a potential problem with this approach. The code that is run by the
shutdown hooks is not restricted in its behaviour and the order that the
shutdown hooks are executed in is not guaranteed. If the deleteOnExit()
and/or closeCachedFiles are not the last hooks to be executed, it is quite
possible that a subsequent shutdown hook could try to access files that
have already been deleted. The only way to guarantee that this will
never happen is to make sure that deleteOnExit() and closeCachedFiles()
are called after all shutdown hooks have completed.
Of course, how this is implemented is down to the VM developer - but
I would strongly recommend not using shutdown hooks for this purpose.
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?
The version of VM.java currently under luni-kernel does not contain
any VM specific code either, as all its methods simply return null :)
It does, however, give hints as to how to implement the methods
in the javadoc comments (perhaps it should clarify the reason
for not using shutdown hooks).
As described above, I think there is a problem with this implementation,
so I would not like to see it used as an example for other VM
developers.
I have noticed that the Javadoc comments for the DRLVM implementation
of deleteOnExit() and closeJars() both say:
/**
* 1) This is temporary implementation
* 2) We've proposed another approach to perform shutdown actions.
*/
Have I missed the proposal of this other approach, or are the comments
inaccurate?
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.
IMHO there is no problem for kernel classes to have dependencies on
classlib - they are, after all, just another part of the class library that
happens to get developed separately due to their nature.
Regards,
Oliver
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
