Bug 199089 - Create java.queries - abstraction for working with Java without JavaC
Create java.queries - abstraction for working with Java without JavaC
Status: RESOLVED DUPLICATE of bug 199405
Product: java
Classification: Unclassified
Component: Source
7.1
All All
: P3 (vote)
: 7.1
Assigned To: Tomas Zezula
issues@java
: PLAN
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-06-01 15:24 UTC by Jaroslav Tulach
Modified: 2011-06-21 18:29 UTC (History)
1 user (show)

See Also:
Issue Type: TASK
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2011-06-01 15:24:17 UTC
One of the tough challenges when writing code for multiple IDEs (NetBeans, Eclipse, JDev) is to deal with different model of Java sources. Each IDE has its unique solution (javac, ecj, jsr198) yet accessing and understanding of Java sources is essential for almost any Java technology.

One approach to deal with the problem is to split own code into IDE independent, and IDE dependent. Then implement the IDE dependent part three times.

The other approach is to start creating an abstraction of general "queries" about Java sources. This abstraction will be javac/ecj/jsr198 independent, it will be based only on existing interfaces in Java6. Over time it may grow, but for the beginning it should support some of the following usecases:

- 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)


These "Java queries" will then be implemented in NetBeans using standard JavaC. Other IDEs will implement them using their traditional means, if they want to reuse modules that depend and use the "queries".
Comment 1 Jan Lahoda 2011-06-02 09:30:02 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.
Comment 2 Tomas Zezula 2011-06-14 14:33:25 UTC
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)
Comment 3 Jaroslav Tulach 2011-06-20 14:31:53 UTC

*** This bug has been marked as a duplicate of bug 199405 ***


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo