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.
| Summary: | Create java.queries - abstraction for working with Java without JavaC | ||
|---|---|---|---|
| Product: | java | Reporter: | Jaroslav Tulach <jtulach> |
| Component: | Source | Assignee: | Tomas Zezula <tzezula> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | tpavek |
| Priority: | P3 | Keywords: | PLAN |
| Version: | 7.1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | TASK | Exception Reporter: | |
|
Description
Jaroslav Tulach
2011-06-01 15:24:17 UTC
Seems that you are proposing a public stable API that mirrors parts of the current Java infrastructure that is to be used by general clients (as opposed to used by a very limited specific set of clients, see [1]). First a meta-meta comment: if this is intended to be vendor neutral, why this is not formed as a vendor neutral specification body that would produce a specification and a TCK that would all the IDE implement? The members of the specification body should of course be the IDE and compiler vendors (I believe that you forgot at least one significant IDE in your list). One less meta: what will we suggest to contributors/plugin developers that they should use? Having two Java infrastructures each of them doing very similar, but not exactly the same stuff will almost surely be extremelly confusing to the contributions/plugin developers. Are we really able to ensure that this API is implemented properly in other IDEs and *maintained*[2] in long-term? Otherwise, I do not see it generally usefull (see [1] again). No metas: I am afraid that this can quickly become a maintanence and performance nightmare. For example, I first though that we could use javax.lang.** as the language model. But, in NetBeans we do not use the JDK6 language model, we use the JDK7 language model, and we may use the preliminary JDK8 model in forseeable future (and we will almost surely use the JDK8 once JDK8 comes out). We cannot do much about this unless we want to drop early support for upcoming JDK versions, which is one of our strongest competitive advantages. So the possible solutions are: -mirror our model to the JDK6 model: this obviously has performance implications and it is pretty much maintanence work, IMO. -pass the JDK7/8/... model to our poor clients: while this is relativelly simple approach (although I am not sure if this can be achieved in the NB's module system without wilful help from the clients), I hardly can see it as a correct one. Will clients written agains this NB infra work against infra from other IDE vendors? -create a brand new Java model, unrelated to javax.lang.**: this would be extreme work and extremelly hard to do correctly - note that the javax.lang.** model is de-facto part of the language and is designed by the language designers. How we would evolve this model for future versions of the language? Will the positive outcomes of such a general API outweight the disadvantages for NetBeans? Some of the disadvantages I see are confusing API and a lot of manpower invested in creating and maintaining[2] this API, which cannot be invested in improving the IDE performance and features. Until the above are resolved, I do not see value in commenting more on this. [1] If this is intended to support a specific limited set of modules, than I suggest that the work needed is properly evaluated and strictly minimal work performed: e.g. if it would be easier to create bridges from e.g. form to NB java, then do the bridges, otherwise do a *friend* or even better *private* API supporting exactly the needed usecases - I believe that there is no need for someone from the Java team to work on this, anyone can. [2] Maintain in this context does not only mean keep binary compatibility. It means fix bugs and *evolve* the model to cope with the evolving language. I.e. continuous work. From a meeting with Jarda and Tomas P. the conclusion is to create a friend module (friend to imlp and form) providing String base queries (updates) on java files. The form requirements are: Use cases: - find out if given file represents a JavaBean (either as .java file or .class file) (BeanInstaller) - plus get the class' FQN if it does - check if "java support" is available for given file (JavaSource.forFileObject(fobj) != null) (InstallToPaletteAction) - conditionally add "SuppressWarnings" annotation to initComponents method (only if available - maybe could be just hardcoded, it's since 1.5) (FormEditor) - get all fields of the form's class (FormJavaSource) - get all methods of the form's class returning certain type (Class) - for the "method picker" property editor (FormJavaSource) - obtain annotation of an event handler method (looks like only for undo support, maybe could be avoided) (FormJavaSource) - resolve FQN to simple names (adding impoerts as needed) in the generated code (i.e. not in the whole class) (FQNImporter) - determine declared superclass of the form's class (GandalfPersistenceManager) - set the user specified superclass for a newly created form (one type of template) (TemplateWizardIterator) - change the form's class declaration to implement certain listeners (JavaCodeGenerator) - add a method to java class - needed by test utils (LayoutTestUtils), could possibly be avoided - determine the binary name of the form's class (not sure why it needs to be so special) (MetaComponentCreator) - rename a private field (all occurrences) in the form's file - silent, not invoking refactoring (RADComponentRenameRefactoringSupport) *** This bug has been marked as a duplicate of bug 199405 *** |