From: "Peter Donald" <[EMAIL PROTECTED]> > > > > > > The JVM does not implement that. Go read the Optional Package spec - it > > > is up to developer to do it. The new servlet and EJB APIs require > > > container implement it IIRC so we should see more vendors using it. > > > > I'm not quite sure what you mean here, Peter. The VM does use the > > ClassPath entries in the manifest without any developer intervention. > > Also, I presume you are taking about download optional packages as you > > don't seem to like installed optional packages aka extensions :-) > > Naah - I am talking about Extensions - they got renamed in jdk1.3 to > "Optional Packages" ;) However they don't have to be VM wide like old > extensions just define libraries that can be loaded and managed any way seend > fit. Currently the JVM does not do it magically for you though. >
To make things clear, in JDK1.3 there are two types of Optional packages: INSTALLED optional packages (what was called Extensions before) and DOWNLOAD optional packages which are the jars declared in the ClassPath entry of another jar. Such packages are not installed permanently but loaded relative to the location of the jar calling it every time is needed. Now, I do not think this is done by the JVM itself, but it must be done by the ClassLoader. And in JDK1.2 there are predefined public Classloaders that know how to do that. Take a look at java.net.URLClassLoader. It provides a Classloader implementation that one can create with the equivalent of a classpath. > > What I think is needed is mechanism where these classes upon which a > > task depends are loaded through the tasklib's classloader but whose > > location is not known when the tasklib jar is put together. > > Sounds like the Optional Packages/Extensions mechanism to me ;) > Yes, but the DOWLOADED one. For that, all what is needed is to set ClassPath entry on the manifest of the jar of the ant-library, and then put any additional jars in the correct location relative to that library. You could even have different libraries using diferent versions of optional packages. I know that URLClassLoader and such are 1.2 stuff, but I which we could rearchitect AntClassLoader as a sort of proxy and underneath use either URLClassLoader for 1.2 or something of our own in the case of 1.1. That would make JDK1.2+ installations to have the power of 1.2 available to them, even if in 1.1 not everything is as rosy. Jose Alberto
