> From: Berin Loritsch [mailto:[EMAIL PROTECTED]
>
> I noticed you used XDoclet instead of QDox. Any particular
> reason why?
XDoclet isn't really used - I only use the XJavadoc part of it.
The reason is simply that I wasn't aware of QDox at the time I
wrote the code.
I started with XDoclet, because I though it would be the best
thing to use - but then I realized that the functionality I
wanted was in XJavadoc and switched to it.
What I miss (both in XJavadoc and QDox) is the ability to easily
get the line number and file a tag is in. See, when generating
classes, suppose you have an attribute whose constructor takes
and integer:
public class MyAttribute {
public MyAttribute (int i) { ... }
}
And then you make a slight error, giving it a String instead:
/**
* @MyAttribute ("hello?")
*/
or misspell the name:
/**
* @MyAtribut (2)
*/
Since the attribute compiler doesn't check this, it will insert a
comment in the generated java source that will help the programmer
find the source of the error that Javac will spew out:
c:\mydir\MyClass$Attributes.java:30: Class MyAtribut not found
new MyAtribut (2) // Taken from MyClass.java, line 4
Instead of having to dig into the generated class and try to figure out
what caused the error, you can see that it was in MyClass.java, line 4.
XJavadoc 1.0 had this ability, but it seems to have been lost in 1.2b2.
> It doesn't really matter in the end. Nice work.
Thanks.
> I will like to play with it, and move toward something like this.
>
> Now the next major question is this:
>
> We currently have a need to discover the components that are
> available, so that we can match up the services with the
> implementations. It seems that this will require some sort
> of extension to the classloader so that we can find the
> classes that have attributes attached to them.
I saw this in a Sun forum:
import java.lang.reflect.*;
public class Test1 {
public Test1() {
try {
Class.forName("java.lang.String", true,
ClassLoader.getSystemClassLoader());
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
System.out.println(Test1.class.getClassLoader() ==
ClassLoader.getSystemClassLoader());
displayLoadedClasses(Test1.class.getClassLoader());
}
public static void main (String[] args) {
new Test1();
}
private void displayLoadedClasses(ClassLoader loader) {
try {
Field _classes = ClassLoader.class.getDeclaredField
("classes");
_classes.setAccessible (true);
java.util.Vector _classesVector = (java.util.Vector)
_classes.get (loader);
Class[] result = new Class[_classesVector.size ()];
_classesVector.copyInto (result);
System.out.println(_classesVector);
} catch(Exception ex) {
ex.printStackTrace();
}
}
}
The thing is that there may be no way to get at the classes
that *haven't been loaded yet*:
http://developer.java.sun.com/developer/bugParade/bugs/4061452.html
Bug Id 4061452
Votes 25
Synopsis (reflect) Should provide API for reflection of packages
Category java:classes_lang
Reported Against 1.2, 1.2beta3, 1.1, kestrel-rc1
Release Fixed
State In progress, request for enhancement
Related Bugs 4215635, 4221402, 4295718
Submit Date Jun 25, 1997
Description There is a notable omission in the current reflection
API: packages.
There should be a class java.lang.reflect.Package with methods to
access a named package, and to iterate over the contents of a
package.
This would be particularly useful inside JCK, where we are trying to
verify the
contents of the standard Java packages, making sure that misguided
licencees
do not try and add extra classes into the Java hierarchy.
Another request from [EMAIL PROTECTED]
Is there any way to get a list of classes in a package?
If not, what is the point of the Package class?
A natural new package method would be:
Class[] Package.getClasses()
which would return a list of all the classes registered
in the Package.
[EMAIL PROTECTED] 1998-05-08
Evaluation Too late for 1.2, so making this a P5.
[EMAIL PROTECTED] 1998-06-17
I agree the existing java.lang.Package class is rather lame. It
would make
sense to add a getClasses method to a Package, returning all classes
currently
loaded within the package. Related API changes might be a
getSubPackages method,
a getpackage() method in Class etc.
However, this will not work the miracles that some of the requestors
expect.
In particular, we can only find classes that are loaded; we cannot
plausibly
search the universe (or even the disk, if there is a disk) for
classes within
the package. So I doubt if it addresses JCK needs.
We should consider adding this functionality; but its utility is
limited, so
this must be balanced against the added bloat and run time cost.
[EMAIL PROTECTED] 2000-03-09
> It is pretty messy to have to iterate over classes, but
> doable if necessary. I would prefer a way to discover
> components that are already loaded on the classpath. That
> may not be possible.
>
> I would be satisfied with a special classloader that had the
> extra method:
>
> Class[] findClasses( Class attribute );
>
> or something like that for class attributes.
OK, how about this:
/**
* Gets a list of all classes with a specific attribute.
* The requirements are:
*
* + The URLClassLoader must either point to...
* ...a local JAR file or
* ...a local directory or
* ...a remote JAR file that will be downloaded in its entirety
and examined
*/
Class[] findClassesWithAttributeType ( URLClassLoader loader, Class
attributeClass );
You can get the URLs used the an URLClassLoader via the getURLs method,
and we can
get all the ugly iteration stuff in one place.
Idea:
How about this. We include in the MANIFEST.mf a list of all classes in
the JAR.
That's it. Just one big list. That is the only packaging requirement.
Then we solve everything else at runtime.
Then we can load classes and index them and so on as needed, but the
packaging
requirements are fixed and dead simple.
> Automatic discovery of components and such will enable things
> like IDE plugins and ANT tools to assist the developer as
> they create and deploy the system.
Just a big list of classes would probably do it. What you
then do with that big list can be left to the application.
It depends on how stable and sophisticated we want the packaging
requirements
to be.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
