Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Won't Fix
-
Affects Version/s: 2.0
-
Fix Version/s: None
-
Component/s: Java API
-
Labels:None
-
Number of attachments :
Description
Type does have a field name. As far as I understand that would be the Simple Name of the type. There is no getter for that field.
My use case is this:
I do have a java class and want to check if there is an annotation like javax.persistence.Entity. The class file has the import:
import javax.persistence.*;
qdox is thus not able to resolve the fully qualified name, since it does not have access to that sources.
Now I know that the full class name is javax.persistence.Entity, and I assume the class to have no compile errors. So I can check the imports myself. However if I do getValue, it first tries to resolve it which always fails and takes something like 16 ms. Its by far the slowest part (it tries to load the class?) in a performance critical part of my project.
With getSimpleName though I could check the imports myself and save some time.
Activity
Yes, I did think about that, and of course that would be much cleaner. In my case it is not that easy, but it could work. I am working on an eclipse plugin which uses qdox. To include those sources, I would probably include them as a jar inside my bundle, I do have to test how well that works though.
And I still stand by it, given my assumptions are true it is easy to resolve it myself, and it's just about 10 lines of code.
Anyway, my use case aside, you still agree it would be useful.
Stefan Ackermann
added a comment - Yes, I did think about that, and of course that would be much cleaner. In my case it is not that easy, but it could work. I am working on an eclipse plugin which uses qdox. To include those sources, I would probably include them as a jar inside my bundle, I do have to test how well that works though.
And I still stand by it, given my assumptions are true it is easy to resolve it myself, and it's just about 10 lines of code.
Anyway, my use case aside, you still agree it would be useful. Even if it's that hard to locate these resources, this might be the start of trouble. I would strongly advise you to let QDox resolve the classes. A more acceptable solution is to add the name of the class to the ClassLibrary (ClassLibrary.add(String)). QDox won't fail if the real class isn't there, but it can use it while building it's model.
Robert Scholte
added a comment - Even if it's that hard to locate these resources, this might be the start of trouble. I would strongly advise you to let QDox resolve the classes. A more acceptable solution is to add the name of the class to the ClassLibrary ( ClassLibrary.add(String) ). QDox won't fail if the real class isn't there, but it can use it while building it's model. That is a cleaner solution that I did not know, thank you.
However it is still slower than my workaround, since I only defined the class names that I absolutely need.
So for example if there is a javax.persistence.OneToOne annotation it still tries to resolve it and fails. But I could easily dismiss it when I am looking for a javax.persistence.Column annotation just by looking at the simple name.
Stefan Ackermann
added a comment - That is a cleaner solution that I did not know, thank you.
However it is still slower than my workaround, since I only defined the class names that I absolutely need.
So for example if there is a javax.persistence.OneToOne annotation it still tries to resolve it and fails. But I could easily dismiss it when I am looking for a javax.persistence.Column annotation just by looking at the simple name. QDox-2.0 will have getValue() which will return the value as used in the code.
If you use java.util.Date getDate() the java.util.* doesn't have to be part of the imports. By using getValue() you will always be safe.
Robert Scholte
added a comment - QDox-2.0 will have getValue() which will return the value as used in the code.
If you use java.util.Date getDate() the java.util.* doesn't have to be part of the imports. By using getValue() you will always be safe. Robert Scholte
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Status | Open [ 1 ] | Closed [ 6 ] |
| Assignee | Robert Scholte [ rfscholte ] | |
| Resolution | Won't Fix [ 2 ] |
This means you have to add this jar/dependency to the classLibrary of the JavaDocBuilder. That's by far more solid than trying to resolve it yourself. QDox follows the same strategy as java in resolving the fully qualified name of the class.
I agree we should add more java.lang.Class-methods, but not for the reason you mentioned.