|
Replies:
8
-
Last Post:
Aug 29, 2005 1:59 AM
by: jwenting
|
|
|
|
|
|
|
URLClassLoader changes
Posted:
Aug 25, 2005 2:31 AM
|
|
|
It would be really helpful to be able to selectively remove entries from the jar: protocol scheme used by URLClassLoader - having a URL -> jar cache is okay except when you want to indicate that a new version has been deployed and you want to update it in the cache. Currently, to get the new version you have to restart your app. This is really important for RMI applications, etc.
|
|
|
|
|
|
|
Re: URLClassLoader changes
Posted:
Aug 25, 2005 3:03 AM
in response to: calum
|
|
|
uh, you want to change classloading so you can load only part of a jarfile?
Dangerous, very dangerous...
|
|
|
|
|
|
|
|
|
Re: URLClassLoader changes
Posted:
Aug 25, 2005 5:33 AM
in response to: jwenting
|
|
|
> uh, you want to change classloading so you can load
> only part of a jarfile?
No. If you send a remote object to a service. or client, and the ClassLoader has already downloaded a jar from this URL, it will use the locally cached version. If, however, I update this codebase file, I would have to restart the application to allow the new jar to be downloaded because there is no way of invalidating the URL in ClassLoader URL cache. What I want to do is be able to deploy new remote objects with the same java.rmi.server.codebase but be able to say to the URLClassLoader, remove this URL from your cache because it is updated, so when the new object is sent across the wire, the new jar will be downloaded and
re-cached
|
|
|
|
|
|
|
|
|
Re: URLClassLoader changes
Posted:
Aug 25, 2005 11:08 AM
in response to: calum
|
|
|
Being able to dynamically change a classloader is dangrous since live classes may already exist.
Just create new URLClassLoaders if you know that code at a given place could be updated, then just use the URLClassLoader to load in the speficied updated jars, creating new ones when an update occurs.
|
|
|
|
|
|
|
|
|
Re: URLClassLoader changes
Posted:
Aug 25, 2005 12:31 PM
in response to: subanark
|
|
|
I believe this makes a bit of a better explanation of the problem
http://archives.java.sun.com/cgi-bin/wa?A2=ind0202&L=jini-users&P=R24352&I=-3
...so I don't think that just creating a new ClassLoader actually helps. See passing the URLs to URLClassLoader is all well and good, but unless the URLs themselves are different (irrespective of the contents), the jar will not be downloaded (in retrospect this is an issue to do with both URLClassLoader and JarUrlConnection.
This caching scenario, makes informing a VM of new versions of a JAR extremely hard
--Calum
--Calum
|
|
|
|
|
|
|
|
|
Re: URLClassLoader changes
Posted:
Aug 26, 2005 10:23 PM
in response to: calum
|
|
|
Peter's comment about reimplementing URLClassLoader to avoid its caching makes sense from a systems perspective since he is a system engineer. However, the described app doesn't need all the complexity the URLClassLoader provides, since all it wants to do is fetch classes from its own list of jar files. Instead of trying to force URLClassLoader to work, write a custom ClassLoader; when it needs a classfile, just use the java.util.zip API directly (no jar: URLs). Nothing says you have to use a URLClassLoader, and a custom ClassLoader is only a little harder to write (plus, you have the full source to URLClassLoader for inspiration).
Tom
|
|
|
|
|
|
|
|
|
Re: URLClassLoader changes
Posted:
Aug 27, 2005 12:04 AM
in response to: tball
|
|
|
I can see the utility of this request but this would appear to be something that I'd want as a developer. I don't think that I'd want this behavior in a production system.
Fortunately one can extend URLClassloader or create a new one and then replace the default system classloader.
Selective loading a classes is a very difficult problem to solve. We used to do this in Smalltalk. In that environment, it was called stripping the image. Stripping an image was difficult, error prone and offered dubious benefits. Much better to properly care for you jar composition and classpath.
|
|
|
|
|
|
|
|
|
Re: URLClassLoader changes
Posted:
Aug 29, 2005 1:59 AM
in response to: subanark
|
|
|
> Being able to dynamically change a classloader is
> dangrous since live classes may already exist.
Excellent point. ClassLoaders (and indeed the entire VM) would have to either take the possibility of multiple mutually incompatible implementations of a class being active inside the JVM into account or would have to have some mechanism of swapping out those old implementations for new ones on the fly (meaning a new and rather cumbersome API being added to Object as well to facilitate this by providing a hook for converting between versions of classes on the fly).
Sounds relatively easy when you're considering only 2 versions existing at once, but a generic API would have to take any number of coexisting implementations into account and be able to convert between any possible combination of these.
|
|
|
|
|
|
|
|
|
Re: URLClassLoader changes
Posted:
Aug 25, 2005 5:39 AM
in response to: jwenting
|
|
|
I never really had issue with URLClassLoader myself, but to avoid compatiblity changes, how about adding a few methods to interrogate the date/version of a file or something?
|
|
|
|
|
java.net RSS
