ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <>
Subject Re: Initial impressions of ant...
Date Tue, 24 Jul 2001 11:39:39 GMT
Conor MacNeill wrote:
> [snip]
> I'm currently mulling over classloader caching. One concern I have is that,
> certainly on Windows, the classloader will retain read locks on the jar
> files in the classpath. These can be the cause of mysterious "access denied"
> errors when people try to delete these jar files. So caching can be a
> problem too. One possibility would be to create a classloader data type
> [snip]

Following this point only: classloader caching is potentially powerful but I
would be skeptical of it working without explicit user control, via a
classloader data type or similar. Only the user can know for sure whether a
JAR included in the path might be deleted (and even recreated) during the
build, thus whether its loader should be cached or recreated. Of course
exposing classloaders to a user is not especially friendly, but better to be
cumbersome and predictable than slick and occasionally broken.

One trick I found helpful working on NetBeans's JAR-based module system:
create a copy of the JAR as a temporary delete-on-exit file and load from
that. Then you have no problems with locks or corrupted archives. (On Windows
the JAR loaded from cannot be deleted or overwritten; on Unix it can but you
will get random errors if any attempt is made to use the classloader later.)
Of course there is some overhead to make the copy and it can leave garbage
files lying around in the /tmp directory.

Also note that under current JDKs, if you ever load anything from a JAR using
ResourceBundle.getBundle, chances are the classloader will never be collected
and any locks held on the JAR will stay there. Anyway you would have to do a
System.gc to release unused JAR locks, assuming no Class's remain from the
classloader you made. And even this does not work at all on 1.2.2 on Windows
at least, you need to use 1.3 to have a chance at releasing the lock.


Jesse Glick        <>
NetBeans, Open APIs  <>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR

View raw message