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.
I would like to ask for a devrev for "javamodel" module (formerly part of "javacore" module). Javamodel module provides JMI API for accessing the Java metadata. Since the module contains purely the JMI API, it is envisioned that an additional support API will be present in javacore module (that contains the implementation of the JMI API in javamodel) to provide convenient entry points to the JMI. This envisioned API is partly done but not public yet, since it needs to be tuned based on the experience we gain from using it. Thus I am not sure if there should be a review also for "javacore" (I am able to provide API answers in a day or two if necessary). I am filing this issue against refactoring module since javamodel is introduced together with the new refactoring functionality and it makes it easier to find this issue, since refactoring is a new module that contains only the issues related to the new Java language infrastructure.
Created attachment 15540 [details] Javadoc + API answers
Created attachment 15622 [details] Javadoc + API answers for JavaCore module
After talking to Yarda, I have created a tiny API also in the JavaCore module. I have attached the JavaDoc and API answers for it.
pb01 Improve (in fact create some :-) documentation of JavaModelPackage. This class has different role then most other classes and the concept may not be obvious for users of this API who are not familiar with MOF and JMI (IMHO usage of this API should not require any knoledge of these technologies). The example in use cases section is not clear enough.
Thanks for all comments at nbdev and in review meeting. I have summarized them in opinion document: http://openide.netbeans.org/tutorial/reviews/opinions_44492.html Martin, please resolve the blocking issues and come back for final review.
I've been told that the memory consumption is increasing with the amount of files in classpaths - e.g. opened projects - as the index of all identifiers is kept in memory. I am sure somebody else has already told you that, but it is not good design. You should store the index in a file on a disk and ocupy either constant or O(log (#files)) of memory.
I'm sure this is not the only thing within the whole IDE which grows approx. linearly with the number of classpath elements. The indexes that are kept in memory are essential - they are accessed many times during a single document attribution to resolve class names. Our assumption was that any additional de-/serialization logic will negatively affect performance of file attribution (which is done during file opening, code completion, etc.) and is not worth of implementing since e.g. for "refactoring" and all dependent projects open (which is about 30 projects) the indexes take less than 8MB and we are still working on improving their size.
Architecture Summary is available here: http://www.netbeans.org/download/dev/javadoc/javacoredoc/index.html
The final review will happen on Sep 9, 9am pacific time, 18pm CET
Architecture Summary and javadoc for Java Language Model API is at: http://www.netbeans.org/download/dev/javadoc/javamodeldoc/index.html