Is there any way to get all the Classes that are in a Package? I know I could peek inside the jar file, but is there an API way to do it. It seems there should be a way to do this via reflection, but I do not see it. I am using J2SE 5
Originally posted by Barry Andrews: Is there any way to get all the Classes that are in a Package? I know I could peek inside the jar file, but is there an API way to do it. It seems there should be a way to do this via reflection, but I do not see it. I am using J2SE 5
No, there isn't and there cannot be. Not only a .jar cand have classes from a package. You need to understand the architecture of Java ClassLoader technology: the source for the bytecode of a class can be anything: file system, web, even you can generate it dynamically.
I don't like the phrase, "and there cannot be." With computers, anything is possible if you know how to do it. In the end it's just a bunch of 0's and 1's anyway
"the source for the bytecode of a class can be anything: file system, web, even you can generate it dynamically."
Yes I understand that, but I don't understand how this relates to my question. You can get the Package from the Class, so why not the reverse if you know the Package? It seems like a design flaw to me.
It doesn't seem to be a design flaw to me. I understand what you are asking and what Marian wanted to convey.
I guess what Marian meant was-- it is possible that one package can be spreaded across Jar files and other sources of CLASSPATH. E.g. If I write a package com.mycompany.mypkg then I 'could' have classes belonging to that package across different jar files and in other classpath folders or they belong to remote machine and needs to be downloaded via network..(this may be belonging to RMI I guess)..So in this case it is difficult to acruately predict classes for a given package.
Now, having said that, I don't really agree that a package is spreaded across various resources. That doesn't sound like manageable thing to me but if it happens to be that way we have to look for that because otherwise we would not really be getting results we should...
Now, to find the classes in the same package, we would have to get list of "all" classes and see if they belong to a package we are referring to and build the list of matching classes.
So essentially we have to do following, 1. We would have to read all Jar files in the classpath (I am not sure how to get this list of all jar files in CLASSPATH just by Java API) using Zip/Jar java api and get all other CLASSPATH entries
2. Identify to which CLASSPATH entry the current class belongs and then look for other packaged classes in that entry ...
BUT First step would be to document all possible ways of loading classes (as Marian suggested to understand class loading..) and then tackle each of them one by one.
May be this is in some direction..but at the end it sounds like long excercise..
[ December 02, 2004: Message edited by: Maulin Vasavada ] [ December 06, 2004: Message edited by: Maulin Vasavada ]
If you are not familiar with XStream, it's a library for serializing objects in XML. You can define an alias for each class you want serialized. So instead of getting a long name like "com.javaranch.example.Test" you can get a name like "Example_Test" in the XML file.
Well I have a flexible model with many classes ( about 15 right now ) that need to be serialized, and I want to use this alias feature. But classes can be added at any time and I don't want myself or someone else to have to remember to add a new class to this alias list every time a new class is added. The classes all go in 1 single package. So, since I know the package the classes go in, it would be nice to just get all these classes in the package and have a naming scheme in place to create the aliases dynamically.
This is just one example. I have needed this feature in the past too for other reasons.
"The classes others may add to your framework don't have to be in your package"
Yes, actually they do. That is the requirement!
Joined: Dec 02, 2004
Definitely you might find solutions for your problem if all your classes lie in the CLASSPATH. But still, for a general Java application, you may encounter problems. The most problematic maybe is a WebClassLoader, in which classes are loaded from a web server, which is probably non-listable (you don't have the option to list the files on it, you only can request a file).
Joined: Dec 02, 2004
Well I have a flexible model with many classes ( about 15 right now ) that need to be serialized, and I want to use this alias feature. But classes can be added at any time and I don't want myself or someone else to have to remember to add a new class to this alias list every time a new class is added. The classes all go in 1 single package.
Why don't you alias your classes with the name of the class without the package? This way, you don't need to know in advance what are the classes in the package and you can compute back the name of the class including package extremely easy.
The main question is how are classes added to your application? Are they dropped into a specific directory, or can the users just drop in additional .jar files into the classpath? A solution to the latter is a little bit more involved -- it involves obtaining the CLASSPATH from the ClassLoader and then walking each entry in the CLASSPATH, looking for files that match your package (even peeking inside .jar files....) In this case, you probably want a method signature like:
If the case is the former, then you simply define the directory where these classes are installed in a .properties file. Use a java.io.File to scan that directory and pick up all of the .class files. Since you know the name of the .class file (Test.class), and you know what package they are supposed to be in (com.javaranch.example), then you know the name of the class (com.javaranch.example.Test).
You could write a scanner that analyzes that directory every 5 minutes or so, looking for new classes. Or you could just scan it once on application start -- whichever makes more sense for your application. [ December 03, 2004: Message edited by: Joel McNary ]
Piscis Babelis est parvus, flavus, et hiridicus, et est probabiliter insolitissima raritas in toto mundo.
Joined: Nov 04, 2001
As Marian says "Why don't you alias your classes with the name of the class without the package?", I am wondering the same thing. Can't you just use the class name without the package as you only have one package name defined by you..?
Hmm, rather than talking in absolutes and and saying it can't be done, here's something which may work, with some hoops you may need to jump through on the way...
ClassLoaders support 'findResources(String name)', which may work with directories. Previously I've seeded this with a known Class to find the locations it is loaded from. Handy to discover when another Class definition if being loaded in preference to the one you want.
Before you do this, you need to turn the fully qualified class name into a directory and file, but that's not hard.
Once you've done this, you may have to do special things depending on each URL returned. If it's a file:// you can get a directory list, if it's a jar you'll have to open it up. Other protocols may be trickier, but file and jars should be 99% or more, I'm guessing.
Going back to your original question, I don't believe there is a 'direct API' way to do it, you're going to have to flex some muscles.
Joined: Oct 12, 2000
Originally posted by Barry Andrews: "The classes others may add to your framework don't have to be in your package"
Yes, actually they do. That is the requirement!
In that case you have a seriously flawed requirement...