overwriting jars currently executing

[visionset]

Whilst messing about with some update code I found I could overwrite all the
jars that constitute my app whilst it was running. It carried on operating
just fine. I was expecting to have to stick the new jars in a temp folder
and copy them from there on next start.
I'm sure the new jars won't actually be used at runtime, so all the classes
must be loaded at startup.
I seem to remember a class is loaded when any access to it occurs static or
otherwise. So I guess I could run into trouble doing this. Is that so? I'd
be amazed if I didn't need to go the temp folder route.

 

[Knute Johnson]

Whilst messing about with some update code I found I could overwrite all the
jars that constitute my app whilst it was running. It carried on operating
just fine. I was expecting to have to stick the new jars in a temp folder
and copy them from there on next start.
I'm sure the new jars won't actually be used at runtime, so all the classes
must be loaded at startup.
I seem to remember a class is loaded when any access to it occurs static or
otherwise. So I guess I could run into trouble doing this. Is that so? I'd
be amazed if I didn't need to go the temp folder route.

I don't know about the loading of classes from jar files but I do know
that you couldn't do that with earlier versions of the run time. I
think it was 1.4 and XP would not let you write the files. But it could
have been 98 too. I've not tried it with Linux.

 

[visionset]

I don't know about the loading of classes from jar files but I do know
that you couldn't do that with earlier versions of the run time. I think
it was 1.4 and XP would not let you write the files. But it could have
been 98 too. I've not tried it with Linux.

This is XP SP2 JDKv1.6.0
I have to decide if it is safer to go the temp route.
What I have concluded is that keeping File operations to a minimum is likely
to reduce bugs.
Either the File class needs more documentation or it really is call and
hope!
I ended up with a few cases where I just tell the user 'well that didn't
work, do it yourself!'
It's not exactly platform independent but I guess it'd be hard to be.

 

[Chris Uppal]

Whilst messing about with some update code I found I could overwrite all
the jars that constitute my app whilst it was running. It carried on
operating just fine. I was expecting to have to stick the new jars in a
temp folder and copy them from there on next start.
I'm sure the new jars won't actually be used at runtime, so all the
classes must be loaded at startup.
I seem to remember a class is loaded when any access to it occurs static
or otherwise. So I guess I could run into trouble doing this. Is that so?

I don't see any way you could be /guaranteed/ safety if you modify/replace a
JAR file which is already in use.

Exactly what will happen will depend on a combination of the OS semantics,
unpublished implementation details of the JAR/ZIP file reader, and the exact
operation you use to replace the JAR. The result could (at least in theory) be
anything from "everything just works, no problems at all", through reading
invalid data from the JAR file (which would at least cause a runtime error), or
crashing the JVM, right up to /seeming/ to work, but running with an invalid
combination of classes from different versions of the JAR.

Not something I'd be willing to risk in production, unless there was a very
good reason /and/ I had direct personal control over every aspect of the
installation and code.

-- chris

 

[Tor Iver Wilhelmsen]

So I guess I could run into trouble doing this. Is that so? I'd
be amazed if I didn't need to go the temp folder route.

Probably, but it depends on the ClassLoader responsible for reading from
the jars. Generally a classloader would open the file in read mode, and
operating systems often let you write to files that are open for reading:
Either the ClassLoader will get an exception at the next read attempt (and
maybe reopen and continue) or it keeps reading from the existing file
descriptor while the file name now points to a different set of blocks.