This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
We would like to make the following improvements to the Java JMI API: - extend ErrorInfo by errorId and arguments properties - this will allow to represent javac errors and warnings in a convenient way for the clients to process them - instead of parsing the error messages, clients will be able to rely on the unique errorId and will be able to extract error message arguments from the arguments list - add getElementByOffset(int offset) to Resource - this will enable clients to get JMI element at a given offset in the source code - add getMain() method to Resource - this method will return all classes defined in a given resource that have "main" method - i.e. can be run - add UnresolvedAnnotationType class to represent unresolved annotation types - will be used in Annotation.getType() - add isRead() and isWrite() methods to VariableAccess - will enable clients to easily find out whether a given variable access does modifications and/or reads the variable value
Created attachment 22344 [details] Diff of the changes.
Adding methods or modifying signatures is OK here as we declare that clients should not implement it. I am fine with this. Can you add a real content to javadoc? Your comment in this IZ entry contains much more details than your patch. re getMain(): would it be usefull to add also hasMain()? It can be faster and the users can get better performance. I am not sure now where we will use getMain() so it is rather a question than a request. BTW: what tasks/rfes depends on this? do we track them.
Agreed that more descriptive Javadoc is needed (this is true in general). How is someone reading the Javadoc supposed to know what ErrorInfo.errorId means? (Is the Javadoc generated from comments in the UML model? If so, please try to make those more descriptive.) Re. Resource.getMain - what is the intended usage? As I understand it, this would check for a main method in a .java file. (Also including nonprivate static nested classes?) Is this intended to be used by JavaNode when badging? Or by code like that in j2seproject's "Main Class" chooser which scans a project for viable main classes? What is the advantage of the proposed method over whatever the current idiom is - more convenient for the caller? amenable to caching in MDR storage or otherwise optimized impl? BTW: how is a potential caller supposed to know what the element types of these List's are? The published Javadoc seems to be using the "quasi-generics" style patch I put in some time ago, but the diff doesn't show it, and the published Javadoc is missing it on e.g. Resource.getErrors for some reason.
> re getMain(): would it be usefull to add also hasMain()? It can be faster and > the users can get better performance. hasMain() will hardly be faster. The only chance how can you decide whether class has main method is to find it.
I also agree with the javadoc. We will add it. >re getMain(): would it be usefull to add also hasMain()? It can be faster and >the users can get better performance. I am not sure now where we will use >getMain() so it is rather a question than a request getMain() can easily be optimized to be as fast as hasMain() for calling getMain().isEmpty() if it works as a lazy collection. First we had hasMain() but then we realized that there can be more than one main class. The code is used at several places in the IDE and currently it is copy-pasted. Thus it is desirable to create an API for it. The main advantage is that there will be a single instance of this code to be maintained. Currently there are several copies and each of them has different imperfections/bugs. >BTW: how is a potential caller supposed to know what the element types of these >List's are? The published Javadoc seems to be using the "quasi-generics" style >patch I put in some time ago, but the diff doesn't show it, and the published >Javadoc is missing it on e.g. Resource.getErrors for some reason. Your patch did not cover all cases (collection types, etc. - I need to improve it, but it is a bit harder than what you already did...)
getMain().isEmpty() is as fast as hasMain() in all cases where there is only one class with main method. This covers 99% of usages.
getMain()/hasMain() - I am OK with your explanation. Code reuse is obviously what we were missing here with several occurecnes of the same code throughoutthe IDE.
Done in trunk. New methods documented in Javadoc. Checking in external/gjast.jar.scrambled; /cvs/java/external/gjast.jar.scrambled,v <-- gjast.jar.scrambled new revision: 1.108; previous revision: 1.107 done Checking in javamodel/manifest.mf; /cvs/java/javamodel/manifest.mf,v <-- manifest.mf new revision: 1.21; previous revision: 1.20 done Checking in javamodel/src/org/netbeans/jmi/javamodel/ErrorInfo.java; /cvs/java/javamodel/src/org/netbeans/jmi/javamodel/ErrorInfo.java,v <-- ErrorInfo.java new revision: 1.5; previous revision: 1.4 done Checking in javamodel/src/org/netbeans/jmi/javamodel/JavaClass.java; /cvs/java/javamodel/src/org/netbeans/jmi/javamodel/JavaClass.java,v <-- JavaClass.java new revision: 1.10; previous revision: 1.9 done Checking in javamodel/src/org/netbeans/jmi/javamodel/JavaModelPackage.java; /cvs/java/javamodel/src/org/netbeans/jmi/javamodel/JavaModelPackage.java,v <-- JavaModelPackage.java new revision: 1.8; previous revision: 1.7 done Checking in javamodel/src/org/netbeans/jmi/javamodel/JavaPackage.java; /cvs/java/javamodel/src/org/netbeans/jmi/javamodel/JavaPackage.java,v <-- JavaPackage.java new revision: 1.10; previous revision: 1.9 done Checking in javamodel/src/org/netbeans/jmi/javamodel/ParameterizedType.java; /cvs/java/javamodel/src/org/netbeans/jmi/javamodel/ParameterizedType.java,v <-- ParameterizedType.java new revision: 1.13; previous revision: 1.12 done Checking in javamodel/src/org/netbeans/jmi/javamodel/Resource.java; /cvs/java/javamodel/src/org/netbeans/jmi/javamodel/Resource.java,v <-- Resource.java new revision: 1.6; previous revision: 1.5 done RCS file: /cvs/java/javamodel/src/org/netbeans/jmi/javamodel/UnresolvedAnnotationType.java,v done Checking in javamodel/src/org/netbeans/jmi/javamodel/UnresolvedAnnotationType.java; /cvs/java/javamodel/src/org/netbeans/jmi/javamodel/UnresolvedAnnotationType.java,v <-- UnresolvedAnnotationType.java initial revision: 1.1 done RCS file: /cvs/java/javamodel/src/org/netbeans/jmi/javamodel/UnresolvedAnnotationTypeClass.java,v done Checking in javamodel/src/org/netbeans/jmi/javamodel/UnresolvedAnnotationTypeClass.java; /cvs/java/javamodel/src/org/netbeans/jmi/javamodel/UnresolvedAnnotationTypeClass.java,v <-- UnresolvedAnnotationTypeClass.java initial revision: 1.1 done Checking in javamodel/src/org/netbeans/jmi/javamodel/VariableAccess.java; /cvs/java/javamodel/src/org/netbeans/jmi/javamodel/VariableAccess.java,v <-- VariableAccess.java new revision: 1.6; previous revision: 1.5 done Checking in javamodel/src/org/netbeans/jmi/javamodel/resources/java-model.xml; /cvs/java/javamodel/src/org/netbeans/jmi/javamodel/resources/java-model.xml,v <-- java- model.xml new revision: 1.15; previous revision: 1.14 done Checking in javacore/nbproject/project.xml; /cvs/java/javacore/nbproject/project.xml,v <-- project.xml new revision: 1.12; previous revision: 1.11 done Checking in javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/ AnnotationTypeClassImpl.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/ AnnotationTypeClassImpl.java,v <-- AnnotationTypeClassImpl.java new revision: 1.6; previous revision: 1.5 done Checking in javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/ResourceImpl.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/ResourceImpl.java,v <-- ResourceImpl.java new revision: 1.86; previous revision: 1.85 done RCS file: /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/ UnresolvedAnnotationTypeClassImpl.java,v done Checking in javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/ UnresolvedAnnotationTypeClassImpl.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/ UnresolvedAnnotationTypeClassImpl.java,v <-- UnresolvedAnnotationTypeClassImpl.java initial revision: 1.1 done RCS file: /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/ UnresolvedAnnotationTypeImpl.java,v done Checking in javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/ UnresolvedAnnotationTypeImpl.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/ UnresolvedAnnotationTypeImpl.java,v <-- UnresolvedAnnotationTypeImpl.java initial revision: 1.1 done Checking in javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/VariableAccessImpl.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/VariableAccessImpl.java,v <-- VariableAccessImpl.java new revision: 1.7; previous revision: 1.6 done
One more file: Checking in src/org/netbeans/lib/java/parser/ErrConsumer.java; /cvs/java/parser/src/org/netbeans/lib/java/parser/ErrConsumer.java,v <-- ErrConsumer.java new revision: 1.3; previous revision: 1.2 done
Reorganization of java component