Re: Getting a list of Classes in a Package
On Mar 21, 1:54 pm, "Omega" <atrau...@gmail.com> wrote:
I've been doing some research online about this subject and I've come
across a pretty even balance of "why I need to do it" and "why it
isn't possible".
I'm glad you have not only done that research, but
thought to mention it. This question often leads
to 'short sharp answers'. ;-)
I want to maybe get some discussion going, and maybe if there is
anyone out there to suggest some alternatives or the best method to
accomplish what I want.
(shrugs) Sure.
What I've read so far is that:
...
2. Classes are not fetched until they are requested/needed.
I would qualify that to say that classes are not
fetched until needed. A JVM would *not* need to
fetch a 'package' as such.
Point 1 seems really irrelevant ..
...Java
offers reflection upon Packages, so they can't
be totally redundant...
No, but see *.
A quicker way to find the classes in a *specific*
jar file is to use the Zip(LookItUp..) class methods
to get an enumeration of the zip entries, and simply
read through them.
Point 2 is a good point and it is certainly the biggest reason why
this is not possible or not done yet: flexibility. But what happens
when you import an entire package? For example "javax.swing.*". I'm
not having an easy time discerning the behaviour,
* 'Entire package' imports are resolved at
*compile* time. Java bytecodes only ever
have specific imports (fully qualified
class names) in them!
..but wouldn't the
classloader reach over and ask for every class in the package?
No.
At that point, even the functionality of getting the names of classes
only retrieved by the classloader within the package would suffice.
...hmm. That might be doable. I'll cede to the
better knowledge of others.
....
IDEs like NetBeans, Eclipse and others do all kinds of wicked
reflection when you think about it. To what degree they cheat, I
don't know, and would love to!
I think it is quite relevant to expect a
build, debugging or deployment tool to allow
or enable things that might not be appropriate
or needed for an "it's in production" application.
Reflection can (as I understand) be quite slow.
The real questions here, as I see them, are -
1) Why does the code *not* know what classes
are available at compile time?
2) If the code is to be told/discover them at
run-time, how is it expected to know what to
do with the class?
Andrew T.