Reflection: Instantiate All Classes in a Package?

Discussion in 'Java' started by Jason Cavett, Mar 23, 2007.

  1. Jason Cavett

    Jason Cavett Guest

    I was wondering...

    Is it possible, by using Java reflection, to instantiate all classes
    existing in a package without knowing the names of those classes. I'm
    envisioning something like this (pseudocode):

    Start my class
    Class goes to package x
    Package x contanis all the classes I need to instantiate
    Using a (loop/something?) I loop through all the classes and
    instantiate each one

    To clarify what I'm trying to do, I am creatnig an error checking
    application that relies on a series of rules that groups of developers
    will code in Java (yeah, I realize I could have it in XML or something
    that makes more sense, but I am the third or fourth developer to work
    on this project). All the (compiled) classes are placed in a specific
    package, but I never will know exactly which classes are there. I was
    hoping for some way to discover and initialize them at runtime. (They
    all implement the same interface, so that part is easy.)

    Is this even possible? Is there a better solution? Thanks for any
    clarification.
    Jason Cavett, Mar 23, 2007
    #1
    1. Advertising

  2. Jason Cavett wrote:
    > I was wondering...
    >
    > Is it possible, by using Java reflection, to instantiate all classes
    > existing in a package without knowing the names of those classes. I'm
    > envisioning something like this (pseudocode):
    >
    > Start my class
    > Class goes to package x
    > Package x contanis all the classes I need to instantiate
    > Using a (loop/something?) I loop through all the classes and
    > instantiate each one
    >
    > To clarify what I'm trying to do, I am creatnig an error checking
    > application that relies on a series of rules that groups of developers
    > will code in Java (yeah, I realize I could have it in XML or something
    > that makes more sense, but I am the third or fourth developer to work
    > on this project). All the (compiled) classes are placed in a specific
    > package, but I never will know exactly which classes are there. I was
    > hoping for some way to discover and initialize them at runtime. (They
    > all implement the same interface, so that part is easy.)
    >
    > Is this even possible? Is there a better solution? Thanks for any
    > clarification.
    >


    Using Java reflection, the answer is NO. For more information, check the
    message thread "Getting a list of classes in a package"; there is a nice
    long discussion on class/package/reflection.

    P.S. it generally helps to search recent posts on Usenet before asking a
    question.
    Joshua Cranmer, Mar 23, 2007
    #2
    1. Advertising

  3. Jason Cavett

    Jason Cavett Guest

    On Mar 23, 5:23 pm, Joshua Cranmer <> wrote:
    > Jason Cavett wrote:
    > > I was wondering...

    >
    > > Is it possible, by using Java reflection, to instantiate all classes
    > > existing in a package without knowing the names of those classes. I'm
    > > envisioning something like this (pseudocode):

    >
    > > Start my class
    > > Class goes to package x
    > > Package x contanis all the classes I need to instantiate
    > > Using a (loop/something?) I loop through all the classes and
    > > instantiate each one

    >
    > > To clarify what I'm trying to do, I am creatnig an error checking
    > > application that relies on a series of rules that groups of developers
    > > will code in Java (yeah, I realize I could have it in XML or something
    > > that makes more sense, but I am the third or fourth developer to work
    > > on this project). All the (compiled) classes are placed in a specific
    > > package, but I never will know exactly which classes are there. I was
    > > hoping for some way to discover and initialize them at runtime. (They
    > > all implement the same interface, so that part is easy.)

    >
    > > Is this even possible? Is there a better solution? Thanks for any
    > > clarification.

    >
    > Using Java reflection, the answer is NO. For more information, check the
    > message thread "Getting a list of classes in a package"; there is a nice
    > long discussion on class/package/reflection.
    >
    > P.S. it generally helps to search recent posts on Usenet before asking a
    > question.- Hide quoted text -
    >
    > - Show quoted text -


    My mistake. Thanks for pointing me to that thread.
    Jason Cavett, Mar 23, 2007
    #3
  4. Jason Cavett

    Oliver Wong Guest

    "Joshua Cranmer" <> wrote in message
    news:lzXMh.493$Ht2.302@trnddc06...
    > Jason Cavett wrote:
    >> I was wondering...
    >>
    >> Is it possible, by using Java reflection, to instantiate all classes
    >> existing in a package without knowing the names of those classes.

    [...]
    >
    > Using Java reflection, the answer is NO. For more information, check the
    > message thread "Getting a list of classes in a package"; there is a nice
    > long discussion on class/package/reflection.


    Actually, the answer turned out to be "yes" (though I can't find the
    thread where we concluded this), but you would probably never want to
    instantiate all the classes existing in a package anyway, because there
    are an infinite number of such classes.

    OP, instead of instantiating all classes in a package, how about
    instantiating all classes located within a specific directory on the local
    harddrive?

    - Oliver
    Oliver Wong, Mar 23, 2007
    #4
  5. Jason Cavett

    Oliver Wong Guest

    "Oliver Wong" <> wrote in message
    news:GmZMh.23233$...
    >
    > "Joshua Cranmer" <> wrote in message
    > news:lzXMh.493$Ht2.302@trnddc06...
    >> Jason Cavett wrote:
    >>> I was wondering...
    >>>
    >>> Is it possible, by using Java reflection, to instantiate all classes
    >>> existing in a package without knowing the names of those classes.

    > [...]
    >>
    >> Using Java reflection, the answer is NO. For more information, check
    >> the message thread "Getting a list of classes in a package"; there is a
    >> nice long discussion on class/package/reflection.

    >
    > Actually, the answer turned out to be "yes" (though I can't find the
    > thread where we concluded this),


    Found it:
    http://groups.google.ca/group/comp...._frm/thread/4017ee8e8edf3690/e7ca74ec29d74031

    - Oliver
    Oliver Wong, Mar 23, 2007
    #5
  6. Jason Cavett

    Mark Rafn Guest

    >>> Is it possible, by using Java reflection, to instantiate all classes
    >>> existing in a package without knowing the names of those classes.

    >[...]
    >> Using Java reflection, the answer is NO. For more information, check the
    >> message thread "Getting a list of classes in a package"; there is a nice
    >> long discussion on class/package/reflection.


    Oliver Wong <> wrote:
    > Actually, the answer turned out to be "yes" (though I can't find the
    >thread where we concluded this)


    Um, no. The answer turned out to be "No, but if you define your problem more
    clearly, we can suggest alternatatives that are possible, like enumerating
    classes in certain known locations and instantiating those that implement a
    given interface."

    > OP, instead of instantiating all classes in a package, how about
    >instantiating all classes located within a specific directory on the local
    >harddrive?


    Indeed!
    --
    Mark Rafn <http://www.dagon.net/>
    Mark Rafn, Mar 23, 2007
    #6
  7. Jason Cavett

    Chris Uppal Guest

    Mark Rafn wrote:

    > Oliver Wong <> wrote:
    > > Actually, the answer turned out to be "yes" (though I can't find the
    > > thread where we concluded this)

    >
    > Um, no. The answer turned out to be "No"


    No, /that/ conversation concluded -- correctly -- that the answer is "yes".
    It is trivial, albeit a little slow, to probe a classloader for all the
    possible potential names of classes -- see the link in Oliver's follow-up post
    for details and further speculation.

    -- chris
    Chris Uppal, Mar 24, 2007
    #7
  8. Chris Uppal wrote:
    > Mark Rafn wrote:
    >
    >> Oliver Wong <> wrote:
    >>> Actually, the answer turned out to be "yes" (though I can't find the
    >>> thread where we concluded this)

    >> Um, no. The answer turned out to be "No"

    >
    > No, /that/ conversation concluded -- correctly -- that the answer is "yes".
    > It is trivial, albeit a little slow, to probe a classloader for all the
    > possible potential names of classes -- see the link in Oliver's follow-up post
    > for details and further speculation.
    >
    > -- chris
    >
    >
    >


    When I said that the answer is "no", I meant that purely using
    reflection, i.e. stock java.lang.reflect.*/ClassLoader, this could not
    be done. Through writing custom ClassLoaders or (my preference), parsing
    the class path/bootstrap path/extensions directory, one can obtain the
    needed classes.

    The OP originally asked for the answer using /reflection/ -- he was more
    or less asking if the answer could there was a method along the lines of
    getAllClasses(String package).

    In summary: Yes, one can get a list of classes in a certain package
    through various means, but no, it cannot be done through /pure/
    reflection. Happy now?
    Joshua Cranmer, Mar 24, 2007
    #8
  9. Jason Cavett

    Chris Uppal Guest

    Joshua Cranmer wrote:

    > In summary: Yes, one can get a list of classes in a certain package
    > through various means, but no, it cannot be done through /pure/
    > reflection. Happy now?


    No, It can be done through nothing more than pure reflection (using only
    ClassLoader.findClass() as exposed via Class.forName(String, ClassLoader))
    Read the thread that Olver referenced. I was going to post code but, what with
    the difficulties of handling Unicode in Java, and the absence of standard
    combinatorial generators in the library, it's a bit more effort to do properly
    than it's worth.

    -- chris
    Chris Uppal, Mar 25, 2007
    #9
  10. Chris Uppal wrote:
    > Joshua Cranmer wrote:
    >
    >> In summary: Yes, one can get a list of classes in a certain package
    >> through various means, but no, it cannot be done through /pure/
    >> reflection. Happy now?

    >
    > No, It can be done through nothing more than pure reflection (using only
    > ClassLoader.findClass() as exposed via Class.forName(String, ClassLoader))
    > Read the thread that Olver referenced. I was going to post code but, what with
    > the difficulties of handling Unicode in Java, and the absence of standard
    > combinatorial generators in the library, it's a bit more effort to do properly
    > than it's worth.
    >
    > -- chris
    >
    >


    Should I append 'feasibly' to my list? To use ClassLoader.findClass()
    would require checking more than 64K^64K ~ 10^1M combinations to find
    every class and probably on the order of 10^22 for more reasonable
    assumptions (100 possible characters, 20-character lengths). It would be
    much more efficient to open the Jar-files, find the package directory,
    and load the classes.
    Joshua Cranmer, Mar 25, 2007
    #10
  11. Jason Cavett

    Chris Uppal Guest

    Joshua Cranmer wrote:

    > > > In summary: Yes, one can get a list of classes in a certain package
    > > > through various means, but no, it cannot be done through /pure/
    > > > reflection. Happy now?

    > >
    > > No, It can be done through nothing more than pure reflection (using
    > > only ClassLoader.findClass() as exposed via Class.forName(String,
    > > ClassLoader))


    > Should I append 'feasibly' to my list?


    Please feel free ;-)


    > To use ClassLoader.findClass()
    > would require checking more than 64K^64K ~ 10^1M combinations to find
    > every class


    I did warn that the technique was a little slow...

    -- chris
    Chris Uppal, Mar 26, 2007
    #11
  12. Jason Cavett

    Jason Cavett Guest

    On Mar 23, 7:12 pm, (Mark Rafn) wrote:
    > >>> Is it possible, by using Java reflection, to instantiate all classes
    > >>> existing in a package without knowing the names of those classes.

    > >[...]
    > >> Using Java reflection, the answer is NO. For more information, check the
    > >> message thread "Getting a list of classes in a package"; there is a nice
    > >> long discussion on class/package/reflection.

    > Oliver Wong <> wrote:
    > > Actually, the answer turned out to be "yes" (though I can't find the
    > >thread where we concluded this)

    >
    > Um, no. The answer turned out to be "No, but if you define your problem more
    > clearly, we can suggest alternatatives that are possible, like enumerating
    > classes in certain known locations and instantiating those that implement a
    > given interface."
    >
    > > OP, instead of instantiating all classes in a package, how about
    > >instantiating all classes located within a specific directory on the local
    > >harddrive?

    >
    > Indeed!
    > --
    > Mark Rafn <http://www.dagon.net/>


    > Um, no. The answer turned out to be "No, but if you define your problem more
    > clearly, we can suggest alternatatives that are possible, like enumerating
    > classes in certain known locations and instantiating those that implement a
    > given interface."


    Sorry...I've been away for a bit.

    Each class will implement the same interface.
    Each class will exist in the same package.

    I want a way (without knowing the actual names of the classes in
    package X) to instantiate those classes. This way, developers can
    continuously add new rules (errors and warnings) and the JAR can
    easily be redistributed just by packaging it up and pushing it out to
    the main system.

    Any additional suggestions on how to do this?

    P.S. Another alternative I thought of is have some sort of
    configuration file where a developer adds the name of his class to the
    config file every time he adds a new class. The major problem with
    this is, 1, it will have to be read every time the error checker is
    run and, 2, it is prone to error if a developer types the class name
    incorrectly.

    Thanks
    Jason Cavett, Mar 26, 2007
    #12
  13. On Mar 27, 2:55 am, "Jason Cavett" <> wrote:
    ...
    > I want a way (without knowing the actual names of the classes in
    > package X) to instantiate those classes. This way, developers can
    > continuously add new rules (errors and warnings) and the JAR can
    > easily be redistributed just by packaging it up and pushing it out to
    > the main system.


    1) Menu item (button or D'n'D funtionality) to
    'add new rules archive'. Once the app. knows
    of the jar..
    2) Copy the jar to a known location,
    3) Iterate the ZipEntry's looking for classes
    in the right package,
    4) do the biz to determine if they implement
    the interface, then..
    5) add them to a single list of class names
    that can be serialised for later loading.

    (That's how I would approach it, failing
    better suggestions from the design gurus.)

    Andrew T.
    Andrew Thompson, Mar 26, 2007
    #13
  14. Jason Cavett

    Oliver Wong Guest

    "Joshua Cranmer" <> wrote in message
    news:z9BNh.2213$Qi2.1850@trndny07...
    >
    > It would be much more efficient to open the Jar-files, find the package
    > directory, and load the classes.


    It sounds like you haven't read the thread that I linked to. I don't
    know why you might want to avoid reading that thread, but this post will
    mainly be a regurgitation of what was written in that thread, since I'm
    assuming you haven't read it. Your solution does not solve the problem
    that the OP originally *stated* (though it probably solves the problem
    that the OP originally *intended*).

    There is not a one-to-one correspondence between packages and
    directories on computers. So for example, if you were using the "scan
    directories" approach and were interested in all classes in package "foo",
    it is not sufficient to merely scan directories named "foo" on your
    computer. You'd also have to scan directories named "foo" on my computer,
    and on computers which I may have thrown into black holes. (This is where
    we initially, and incorrectly, concluded that it was completely
    impossible).

    Later, it was decided that two classes are the same if they have the
    same bytecode, even if they reside on different computers. E.g. if I write
    a class on a computer, and then throw that computer into a black hole, and
    you also write a class, and that class has the same bytecode as the class
    that I wrote, then they are by definition the same class. (This is
    philosophically comparable to the idea that if I write "3" on a piece of
    paper, and you write "3" on a different piece of paper, we are both wrote
    down the same number, the number itself being an abstract concept which is
    not directly associated to either of our pieces of paper.)

    So one could write an iterator which returns every possible sequence
    bytecode, much like you can iterate through every possible integer, and
    turn the bytecode sequence into a Java class. Some of these bytecode
    sequences might declare names that conflict with each other (e.g. there's
    more than one class in package "foo" with the name "Bar", but they are
    distinct classes, having different bytecode), and so you'd need to
    separate these classes into different classloaders.

    Note that classes may "exist" in the "foo" package, even if they are
    not stored on any local harddrive. This is philosophically comparable to
    the idea that numbers "exists", conceptually, even if no one has ever
    bothered to write them down yet.

    This is also why I suspect that the OP doesn't really want to load all
    classes from a given package, but instead, wants to load all classes
    located in a given local directory (perhaps with certain additional
    conditions).

    - Oliver
    Oliver Wong, Mar 26, 2007
    #14
  15. Oliver Wong wrote:
    > "Joshua Cranmer" <> wrote in message
    > news:z9BNh.2213$Qi2.1850@trndny07...
    >
    > This is also why I suspect that the OP doesn't really want to load all
    > classes from a given package, but instead, wants to load all classes
    > located in a given local directory (perhaps with certain additional
    > conditions).
    >


    In which case you shouldn't add such a method to ClassLoader (because
    not all class loaders can reasonably implement the method), but rather
    to some sub class of ClassLoader (or an interface which ClassLoaders
    might optionally implement).
    Alternatively if you do put the method on ClassLoader you have to
    document that implementation is optional or might only return classes
    that had already been loaded. Perhaps add another method which returned
    a value specifying the degree of enumeration that was possible.

    Mark Thornton
    Mark Thornton, Mar 26, 2007
    #15
  16. Jason Cavett

    Wojtek Guest

    Jason Cavett wrote :
    > They all implement the same interface, so that part is easy.


    Even if they implement the same interface does not guarantee that they
    have a constructor which you can easily use. If the class does not have
    a parameter-less constructor, then you need to do some creative work to
    find all the primitives/classes which the available constructors do
    use.

    And of course if those class's constructors need parameters....

    --
    Wojtek :)
    Wojtek, Mar 26, 2007
    #16
  17. Jason Cavett

    Mark Rafn Guest

    >On Mar 23, 7:12 pm, (Mark Rafn) wrote:
    >> > OP, instead of instantiating all classes in a package, how about
    >> >instantiating all classes located within a specific directory on the local
    >> >harddrive?


    Jason Cavett <> wrote:
    >Each class will implement the same interface.
    >Each class will exist in the same package.


    As stated, it's impossible. s/package/searchable location/ and you're golden.

    >I want a way (without knowing the actual names of the classes in
    >package X) to instantiate those classes. This way, developers can
    >continuously add new rules (errors and warnings) and the JAR can
    >easily be redistributed just by packaging it up and pushing it out to
    >the main system.


    Great. A jar is a searchable location. It's nearly trivial to list all
    class files in a given subdirectory of a jar, and you don't even need
    reflection to access them.
    Use the java.util.jar.JarFile#entries method to list files in the jar,
    translate them to classnames, and call
    Class.forName(className).isAssignableTo(yourInterface)
    to see if it's the right interface.

    >Any additional suggestions on how to do this?


    The above is very easy to write.

    >P.S. Another alternative I thought of is have some sort of
    >configuration file where a developer adds the name of his class to the
    >config file every time he adds a new class. The major problem with
    >this is, 1, it will have to be read every time the error checker is
    >run and, 2, it is prone to error if a developer types the class name
    >incorrectly.


    The config file will be faster than scanning the jar, and is a much more
    direct reflection of developer intent than trying to discover things by magic.
    It also allows the implementation to be in a different jar (or non-jar
    classpath location) and still be found by your app.

    I'd HIGHLY recommend using the config file.

    --
    Mark Rafn <http://www.dagon.net/>
    Mark Rafn, Mar 26, 2007
    #17
  18. Jason Cavett

    Daniel Pitts Guest

    On Mar 26, 1:50 pm, (Mark Rafn) wrote:
    > >On Mar 23, 7:12 pm, (Mark Rafn) wrote:
    > >> > OP, instead of instantiating all classes in a package, how about
    > >> >instantiating all classes located within a specific directory on the local
    > >> >harddrive?

    > Jason Cavett <> wrote:
    > >Each class will implement the same interface.
    > >Each class will exist in the same package.

    >
    > As stated, it's impossible. s/package/searchable location/ and you're golden.
    >
    > >I want a way (without knowing the actual names of the classes in
    > >package X) to instantiate those classes. This way, developers can
    > >continuously add new rules (errors and warnings) and the JAR can
    > >easily be redistributed just by packaging it up and pushing it out to
    > >the main system.

    >
    > Great. A jar is a searchable location. It's nearly trivial to list all
    > class files in a given subdirectory of a jar, and you don't even need
    > reflection to access them.
    > Use the java.util.jar.JarFile#entries method to list files in the jar,
    > translate them to classnames, and call
    > Class.forName(className).isAssignableTo(yourInterface)
    > to see if it's the right interface.
    >
    > >Any additional suggestions on how to do this?

    >
    > The above is very easy to write.
    >
    > >P.S. Another alternative I thought of is have some sort of
    > >configuration file where a developer adds the name of his class to the
    > >config file every time he adds a new class. The major problem with
    > >this is, 1, it will have to be read every time the error checker is
    > >run and, 2, it is prone to error if a developer types the class name
    > >incorrectly.

    >
    > The config file will be faster than scanning the jar, and is a much more
    > direct reflection of developer intent than trying to discover things by magic.
    > It also allows the implementation to be in a different jar (or non-jar
    > classpath location) and still be found by your app.
    >
    > I'd HIGHLY recommend using the config file.
    >
    > --
    > Mark Rafn <http://www.dagon.net/>

    Indeed. This is called Inversion of Control, and is a great boon to
    complex, extensible designs.
    Spring Framework does this quite well, with a intuitive XML
    configuration.
    Daniel Pitts, Mar 26, 2007
    #18
  19. Jason Cavett

    Jason Cavett Guest

    On Mar 26, 5:03 pm, "Daniel Pitts" <>
    wrote:
    > On Mar 26, 1:50 pm, (Mark Rafn) wrote:
    >
    >
    >
    > > >On Mar 23, 7:12 pm, (Mark Rafn) wrote:
    > > >> > OP, instead of instantiating all classes in a package, how about
    > > >> >instantiating all classes located within a specific directory on the local
    > > >> >harddrive?

    > > Jason Cavett <> wrote:
    > > >Each class will implement the same interface.
    > > >Each class will exist in the same package.

    >
    > > As stated, it's impossible. s/package/searchable location/ and you're golden.

    >
    > > >I want a way (without knowing the actual names of the classes in
    > > >package X) to instantiate those classes. This way, developers can
    > > >continuously add new rules (errors and warnings) and the JAR can
    > > >easily be redistributed just by packaging it up and pushing it out to
    > > >the main system.

    >
    > > Great. A jar is a searchable location. It's nearly trivial to list all
    > > class files in a given subdirectory of a jar, and you don't even need
    > > reflection to access them.
    > > Use the java.util.jar.JarFile#entries method to list files in the jar,
    > > translate them to classnames, and call
    > > Class.forName(className).isAssignableTo(yourInterface)
    > > to see if it's the right interface.

    >
    > > >Any additional suggestions on how to do this?

    >
    > > The above is very easy to write.

    >
    > > >P.S. Another alternative I thought of is have some sort of
    > > >configuration file where a developer adds the name of his class to the
    > > >config file every time he adds a new class. The major problem with
    > > >this is, 1, it will have to be read every time the error checker is
    > > >run and, 2, it is prone to error if a developer types the class name
    > > >incorrectly.

    >
    > > The config file will be faster than scanning the jar, and is a much more
    > > direct reflection of developer intent than trying to discover things by magic.
    > > It also allows the implementation to be in a different jar (or non-jar
    > > classpath location) and still be found by your app.

    >
    > > I'd HIGHLY recommend using the config file.

    >
    > > --
    > > Mark Rafn <http://www.dagon.net/>

    >
    > Indeed. This is called Inversion of Control, and is a great boon to
    > complex, extensible designs.
    > Spring Framework does this quite well, with a intuitive XML
    > configuration.- Hide quoted text -
    >
    > - Show quoted text -


    Okay, thank you both, Mark and Daniel (and others). I guess I always
    got the impression through schooling/reading/whatever that a config
    file in this type of situation would *not* be a good thing (not even
    sure why I thought that). Glad to hear otherwise - especailly because
    it seems like such a good and simple solution.

    Thanks again.
    Jason Cavett, Mar 26, 2007
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?TnVubw==?=

    Instantiate webform classes ....

    =?Utf-8?B?TnVubw==?=, Feb 14, 2006, in forum: ASP .Net
    Replies:
    3
    Views:
    669
    Scott Allen
    Feb 15, 2006
  2. guava
    Replies:
    1
    Views:
    2,684
    Joseph Millar
    Aug 8, 2003
  3. Jeffy
    Replies:
    2
    Views:
    2,671
    Thomas Weidenfeller
    Sep 10, 2003
  4. Carfield Yim
    Replies:
    1
    Views:
    1,418
    Andrew Thompson
    May 31, 2004
  5. Julian
    Replies:
    3
    Views:
    4,523
    Thomas Schodt
    Apr 30, 2005
Loading...

Share This Page