Sun Java's jar loading on windows

[Aquila Deus]

Hi all!

I'm wondering why sun java doesn't use file-mapping to load .jar files?
Because on windows file opening always locks the file, while
file-mapping allows you to rename or move the file to other place
(trash can). It's especially important for jars put under web-apps'
\lib, because those jars, once loaded in some container ("resin"),
can't be replaced unless you restart the whole JVM. Besides,
file-mapping an uncompressed zip/jar file can let you access the zipped
..class directly, without extracting it at all!
Just a thought, any comment?

 

[Andrey Kuznetsov]

I'm wondering why sun java doesn't use file-mapping to load .jar files?

Because on windows file opening always locks the file, while
file-mapping allows you to rename or move the file to other place
(trash can). It's especially important for jars put under web-apps'
\lib, because those jars, once loaded in some container ("resin"),
can't be replaced unless you restart the whole JVM. Besides,
file-mapping an uncompressed zip/jar file can let you access the zipped
.class directly, without extracting it at all!
Just a thought, any comment?

Sun makes only OS-independend things.
If you want you can write your own classloader which do it using nio.

 

[Aquila Deus]

Sun makes only OS-independend things.

Yep, that's why Sun should use file mapping - it's more consistent with
POSIX's behavior of file handling, otherwise Java could copy all jars
needed to a temp folder and load them from there, just like what
ASP.NET Host does.

If you want you can write your own classloader which do it using nio.

I'm going to do that, and I'll post the patch steps later

 

[Jon Caldwell]

Hi all!

I'm wondering why sun java doesn't use file-mapping to load .jar files?
Because on windows file opening always locks the file, while
file-mapping allows you to rename or move the file to other place
(trash can). It's especially important for jars put under web-apps'
\lib, because those jars, once loaded in some container ("resin"),
can't be replaced unless you restart the whole JVM. Besides,
file-mapping an uncompressed zip/jar file can let you access the zipped
.class directly, without extracting it at all!
Just a thought, any comment?

That sounds like it would make an unstable system. When does the
classloader know to reload the classes?

 

[Aquila Deus]

That sounds like it would make an unstable system. When does the
classloader know to reload the classes?

It can do so when restarting the whole web app. The current problem is
that on windows you can't replace old jars until the web app is
stopped, but usually there is no command to "stop", only restart (stop
-> pause 100ms -> start!)

 

[Aquila Deus]

I can't map the zip because it involves some dirty native methods, so I
use shadow copy instead (asp.net's method

The full instruction and code:
http://developer.berlios.de/docman/display_doc.php?docid=691&group_id=2899
Cheers!

 

[Chris Uppal]

I can't map the zip because it involves some dirty native methods, so I
use shadow copy instead (asp.net's method

The full instruction and code:
http://developer.berlios.de/docman/display_doc.php?docid=691&group_id=2899

Check the licence before you distribute or deploy any application that depends
on modifications to a vendor's class library.

IIRC, Sun's JRE/JDK licences forbid any modification.

-- chris

 

[Aquila Deus]

I can't map the zip because it involves some dirty native methods, so I
use shadow copy instead (asp.net's method

The full instruction and code:
http://developer.berlios.de/docman/display_doc.php?docid=691&group_id=2899
Cheers!

I forgot to post to c.l.j.help

And I just found that in the native code mmap is only enabled on unix,
there is no impl to file-map zip for win32... But the file-map in
java.nio has been working for years!

 

[Aquila Deus]

http://developer.berlios.de/docman/display_doc.php?docid=691&group_id=2899

Check the licence before you distribute or deploy any application that depends
on modifications to a vendor's class library.

IIRC, Sun's JRE/JDK licences forbid any modification.

Ahhh.. Is it legal if I deploy my app with a patcher, instead of the
modified JRE?

 

[Chris Uppal]

Ahhh.. Is it legal if I deploy my app with a patcher, instead of the
modified JRE?

No idea. I am not lawyer....

My /guess/ would be no.

Also, I don't think that replacing a .jar file without the cooperation of any
classloader that used it would be a good idea -- either it wouldn't "see" the
new version at all, or it would risk loading inconsistent data. But if you
/do/ have the cooperating of the classloader, then you don't need the feature.
For instance you could write the classloader to check for the existence of a
replacement JAR /before/ it opens the "standard" one.

-- chris

 

[Aquila Deus]

No idea. I am not lawyer....

My /guess/ would be no.

Also, I don't think that replacing a .jar file without the cooperation of any
classloader that used it would be a good idea -- either it wouldn't "see" the
new version at all, or it would risk loading inconsistent data. But if you
/do/ have the cooperating of the classloader, then you don't need the feature.
For instance you could write the classloader to check for the existence of a
replacement JAR /before/ it opens the "standard" one.

It checks new or incompatiable version everytime. And it's not in
classloader, but in the ZipFile (bcuz I can't hack the constructor in
JarFile), so it works for custom classloaders as well

The whole process is very simple:

0.You create a new ZipFile (parent of JarFile), and in the constructor:
1.First of all it checks whether the file should be shadowed by env
var,
2.Check the existence and the size and the last modification time of
its shadow copy in a temp dir
3.Copy and override the shadow copy if it's invalid.
4.Give following code (original code) a new File which points to the
shadow copy