On Fri, Mar 20, 2009 at 12:46 PM, Neil Bartlett <[email protected]> wrote: > > 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. Agreed -- I know well that Jython's method has some powerful limitations.
> 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. I think John's method could work well for us. Given that the name is "getLoadedClasses" I worry about classes that could be reached by the class loader but have not yet been loaded. I am on shaky ground here I must admit, but my understanding is that classes are not guaranteed to be loaded until they are used -- I presume that this means some code somewhere has triggered a ClassLoader#loadClass -- so would looking for them in this manner kick them into being loaded? The javadoc for java.lang.ClassLoader#loadClass gives me hope: Returns the class with the given name if this loader has been recorded by the Java virtual machine as an initiating loader of a class with that name. -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 -~----------~----~----~----~------~----~------~--~---
