>> Would it be so hard to release an official reflection class that
>> transparently discovers all the *available* classes from a specific
[quoted text clipped - 9 lines]
> asked for -- again generating classes on the fly (and probably randomly). In
> either case your question has no meaning at all.
Why? As the JVM loads such dynamic classes, couldn't it keep track of
their in-memory presence for on-the-fly reflection-at-package-level
purposes?
As I said, I intended to discover "all the *available* classes from a
specific package": AVAILABLE doesn't mean POSSIBLE. It's self-evident
that I didn't want to discover the whole universe of the possible
imaginative package: I simply did NOT want that. I wanted all the
reachable classes from a specific package within the classpath scope: is
it SO insane?
In fact, as the context of my question should have implied, I was
referring to the most common, real-life case: non-dynamically-generated
classes. *Possible* doesn't mean *practical*: I think that the typical
scenario is NOT randomly-generated classes, but well-established,
non-volatile classes.
> If you want to restrict yourself to less dynamic ideas of what a package is,
YOU are restricting yourself to the limits of a platform.
> and what sorts of classloader you are going to use, then the question may
> become feasible to answer -- for instance, you could simply include a list of
> classes (maybe indexed by interfaces) as a readable text resource in the same
> JAR.
Awkward.
> Alternatively, you could discover the location from which the classloader
> was loading .class files (if there was any concept of "location") and use
> location-specific code to discover what .class files are available there. E.g.
> reading the table-of-contents of a JAR file considered as a ZIP file, or
> listing (recursively) the contents of a directory. Note that this may not be
> possible; for instance if the "location" is an HTTP base-URL.
OK.
As many people have asked for such a functionality, maybe just ignoring
the problem (as no official practise seems to exist) is somewhat an
exercise for snob theorists. ;-)
Lothar Kimmeringer - 10 Oct 2006 19:58 GMT
> As many people have asked for such a functionality, maybe just ignoring
> the problem (as no official practise seems to exist) is somewhat an
> exercise for snob theorists. ;-)
Fot this the most easy way is to implement your own ClassLoader
that is used at the beginning of your application that is
collecting this kind of information within a map you can access
without the need of Reflection (at the point of time you need it).
Of course this adds more overhead to the loading of classes, but
that's something you have to accept in your special case. No
need to slow down all the other applications (I assume about
99.999%) that doesn't.
Easy (just a method-call), smooth (fast, reliable) and also
cool (adding ClassLoaders) with so little effort. SUN thought
of everything ;-)
Your attempt of using Reflection for this kind of thing is
simply the wrong one, so there is no need to start a discussion,
why something like Mono (AKA .NET) or any other system that
has been created many years after Java, has got some specific
feature, Java doesn't.
Regards, Lothar

Signature
Lothar Kimmeringer E-Mail: spamfang@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)
Always remember: The answer is forty-two, there can only be wrong
questions!
Chris Uppal - 11 Oct 2006 10:16 GMT
> Why? As the JVM loads such dynamic classes, couldn't it keep track of
> their in-memory presence for on-the-fly reflection-at-package-level
> purposes?
Of course it could. It does so internally. But why /should/ it ? All that
would happen is that people would misuse it[*]: the collection of classes which
/have/ been loaded is not the same as the collection of classes which are
/available/ to be loaded (even in a completely static situation).
If you need that functionality (but what for ??) then it's simple to add it.
If you need to be able to ask what classes /could/ be loaded then there is no
general solution -- so you should expect to be forced to create special-purpose
code to handle your own specific situation, taking advantage of whatever
situation-specific factors you can.
-- chris
([*] Maybe /you/ wouldn't misuse it, but the majority of the people who ask
this, or closely related questions, here would)