One word of caution. It sounds like this approach would not work in a variety of classloading scenarios, such as J(2)EE or OSGi, since you make some assumptions about JAR files and the visibility of the application "classpath" etc.
I do a lot of work in OSGi and the proposal from John to get all classes in a package according to one classloader would probably work well, since OSGi strongly discourages "split packages", i.e. packages provided by more than one module and therefore classloader. Regards, Neil On Fri, Mar 20, 2009 at 1:35 PM, Frank Wierzbicki <[email protected]> wrote: > > I had a short exchange with John Rose about the lack of getClasses() > on java.lang.Package. Jython has a need for something like this, and > it has a somewhat awkward way of getting at this information. I > thought I'd flesh out the question and the use cases on this list, > since others here may have similar needs. > > To start with, I think I understand why getClasses isn't "just there" > on java.lang.Package. Even within one classloader, packages can come > from a whole host of places, and since packages have merging behavior > in Java, it is really hard to know that you have all of the classes > for a particular package. Python gets around this worry since it has > a "winner take all" package importing semantic (the downside is that > you can't really use the reverse url namespaces favored by Java). > > John asked if a getLoadedClasses isolated to one classloader would > work. Though this might help make things better (and I don't think > the single classloader is a problem), I don't think it will be enough > to replace Jython's current functionality. > > So here are the most important use cases from Jython: > > 1. A Java package can be imported and then the classes can be listed. > > 2. you can "import *" from a java package and drop all of the classes > from that package into the root namespace (though this is considered > poor style from both the Python and Jython communities) > >>>> from java import nio >>>> dir(nio) > ['Buffer', 'BufferOverflowException', 'BufferUnderflowException', > 'ByteBuffer', 'ByteOrder', 'CharBuffer', 'DoubleBuffer', > 'FloatBuffer', 'IntBuffer', 'InvalidMarkException', 'LongBuffer', > 'MappedByteBuffer', 'ReadOnlyBufferException', 'ShortBuffer', > '__name__', 'channels', 'charset'] >>>> from java.util import * >>>> x = ArrayList([1,2,3]) > > So I suspect that getLoadedClasses() would only give you those classes > that had already been used in some way and so wouldn't be sufficient > for these use cases. To continue the conversation -- would it be > possible to get a list or array of Strings that would represent the > classes in packages that a Classloader already knows about? I can do > the rest from there. > > The method that Jython uses goes something like this: > > The first time Jython is started, it walks through all of the jars and > class directories on the filesystem that it knows about (including, > for example classes.jar, the jars in the ext dir, etc) and creates a > filesystem cache of all of the package names and corresponding class > names. Each time it starts up again it will check the filesystem > timestamps vs. the cache timestamps and adjust the caches as needed. > It also updates the caches when jars or Java classes are added to > Jython's path at runtime. If it doesn't find a particular package it > will also check java.lang.Package.getPackages(). > > For those that are interested, I do plan to get this mechanism in > shape for use outside of Jython -- there is a start to this extraction > here: > https://jvm-language-runtime.googlecode.com/svn/trunk/packagecache but > it will need lots of work yet to become a general solution usable > outside of Jython. Hopefully in the next couple of months > I'll have time to help get this code in shape for use by JRuby. > Hopefully getting this mechanism usable across two projects will be > enough to get it nicely isolated from language specifics. I started > this extraction at Charlie Nutter's request (the request is sadly > going on two years now). > > -Frank > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
