>> From the context of what you're saying, I'm guessing that you're running a
>> Java application and not an applet on the client. What I can suggest is
>> that you write a custom ClassLoader that uses java.net.URL to connect to a
>> given web server, check dates (against the .jar in your local path),
>> download the .jar if necessary, then proceed with normal class loading
>> (which is probably your "SmartUpdate" idea in a nutshell).
>
>I've been looking for a way to provide users of my software with a
>"SmartUpdate" feature. Your idea sounds great, the only problem is when
>your want to save the new JAR in place of the old one: under Unix it
>should work, but under windows the original JAR is locked and it is
>impossible to squash it with the new one.
>
>Would you have any idea on how to replace a JAR in-place and circumvent
>file locking under some platforms? This problem has been bugging me for
>more than a year.
>
Hmm.... Are you willing to go to native code for your client bootstrap app?
You can use JNI Invocation to create the java VM, inside the Java app drop
the .jar into a new directory (call it "incoming" or something), then copy
the .jar over to the Java directory when the java VM exits.
Beyond that, I'm not sure--it really depends on how the Win32 JNI code is
opening the file for use--if they're using exclusive locking, then I think
you're SOL unless somebody knows of a Win32 API call that can work around
or break an exclusive lock. Give me a bit (can't at the moment--busy), and
I'll see if I can't figure out how they're doing it under the hood. Send me
a reminder in a day or two if you don't hear from me first.
>Conscience is what hurts when everything else feels so good.
>
I LIKE this line!
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
