Bug 198338 - Remove backdoor API between ActionProcessor and PathCompletions
Remove backdoor API between ActionProcessor and PathCompletions
Status: REOPENED
Product: apisupport
Classification: Unclassified
Component: Project
7.0
All All
: P4 (vote)
: 8.0
Assigned To: Martin Kozeny
issues@apisupport
:
Depends on:
Blocks: 189558
  Show dependency treegraph
 
Reported: 2011-05-05 11:18 UTC by Jesse Glick
Modified: 2013-08-15 14:37 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2011-05-05 11:18:04 UTC
openide.awt/src/org/netbeans/modules/openide/awt/ActionProcessor.java and apisupport.project/src/org/netbeans/modules/apisupport/project/layers/PathCompletions.java cooperate using a horrible backdoor API based on system properties and reflection, since the AP does not have enough context to offer very useful completions itself - it could only examine the classpath of the module, which will not include other modules expected to be loaded at runtime.

Better would be for ActionProcessor to simply offer no completions, and for PathCompletions to be rewritten to use whatever the appropriate NB API is for supplying code completion in a Java document.
Comment 1 Jaroslav Tulach 2011-05-05 11:53:08 UTC
I don't care if something is nice or horrible. If you want me write a test to make it work, I can do it.

Rather than removing the completions I'd like to improve them to offer hint for position and separatorXYZ attributes (as you suggested in an email to dev@platform.netbeans.org today).
Comment 2 Jesse Glick 2011-05-05 22:06:51 UTC
(In reply to comment #1)
> If you want me write a test to make it work

What does writing a test have to do with anything? There is an inappropriate dependency which should be cleaned up. Probably P3 is too high, though.

> Rather than removing the completions

Not sure what you mean; I did not suggest removing anything, just making the impl use the regular editor code completion infrastructure, since the AP cannot offer any useful information.

> I'd like to improve them to offer hint for position and separatorXYZ attributes

Sure, but that is orthogonal to this issue.
Comment 3 Jesse Glick 2011-05-05 22:07:38 UTC
Original summary was what I meant. There should be no API to polish.
Comment 4 Jaroslav Tulach 2011-05-06 12:47:08 UTC
In such case I disagree with the task completely. I wonder how your fingers can type "Better would be to offer no completions"!
Comment 5 Jesse Glick 2011-05-06 13:24:52 UTC
ActionProcessor should offer no completions; PathCompletions would do so on its own, without going through 269.
Comment 6 Jaroslav Tulach 2011-05-07 14:46:19 UTC
PathCompletions are not on classpath and they are not called. The suggestion is not valid.
Comment 7 Jesse Glick 2011-05-09 14:39:54 UTC
(In reply to comment #6)
> PathCompletions are not on classpath and they are not called

Currently PathCompletions is invoked reflectively from ActionProcessor.getCompletions. The task is to delete ActionProcessor.getCompletions, and rewrite PathCompletions to be a regular provider of editor code completion (not a quasi-implementation of Processor).
Comment 8 Jaroslav Tulach 2013-08-12 08:18:12 UTC
I still believe that rather than rewriting all our support to editor.completion APIs, we should find a simpler way for regular AnnotationProcessor to get info about structure of layers.

I still consider the task:
> The task is to delete ActionProcessor.getCompletions, and rewrite
> PathCompletions to be a regular provider of editor code completion
invalid.

At most we should have better API than reflection, but removing ActionProcessor is leading us the wrong way.
Comment 9 Jesse Glick 2013-08-15 14:37:32 UTC
Whether the solution is to use the regular editor completion APIs or not, it is still a valid request to get rid of the inappropriate API; there are other possibilities.

For example, ActionProcessor.getCompletions could check for an optional argument processingEnv.options['layers'] (a space-separated list of URLs), akin to the attribute defined in XMLFileSystem/BinaryFS/WritableXMLFileSystem. If defined, it would use a SAX parser to check for available paths in these layers. apisupport.project could arrange for this processor option to be defined on NBM-like projects, probably by defining an AnnotationProcessingQueryImplementation (which would require a LookupMerger on this SPI if one does not already exist). There is still then an API of sorts to ActionProcessor, but it is going through the proper channel defined by JSR 269 (Processor.getSupportedOptions), and would be amenable to unit testing.


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