Project: JDT
Bug 145138 [content assist] IJavaCompletionProposalComputer corecontext only initialized 'by chance'
Reported: 2006-06-02 15:04:50 | Status: resolved fixed

I have been successfully using the org.eclipse.jdt.ui.javaCompletionProposalComputer extension point in a plugin (lets call it plugin A). This plugin have the following code: public List computeCompletionProposals(ContentAssistInvocationContext context, IProgressMonitor monitor) { JavaContentAssistInvocationContext ctx = (JavaContentAssistInvocationContext)context; CompletionContext coreContext = ctx.getCoreContext(); try { if(coreContext!=null) { int kind = coreContext.getTokenKind(); if(kind==CompletionContext.TOKEN_KIND_STRING_LITERAL) { ... So it uses the public API JavaContentAssitInvocationContext and its coreContext to decide if a completion is being performed inside a String literal. This works beautifull. Now for modularity sake I wanted to seperate this functionallity out to another plugin. Thus I copied the extension point and code into plugin B which then depends on plugin A. The proposal computer is indeed called, but now the core context is null. Enabling the code in Plugin A together with the new thing in Plugin B showed that for some reason Plugin A had a non-null core context and Plugin B still had null. After some time I found that the reason is that the core context is only intialized IFF one of the builtin JDT provided proposalcomputers is called first. This is because they internall call the non-public: JavaCompletionProposalComputer.createCollector(context) which in turn call ExperimentalResultCollector which initializes the corecontext. Thus the capabilities exposed to a custom proposalcomputer is 'by chance'. If the above is expected behavior then it would be interesting to find out one of the following: A) how can I ensure that my completion proposal collector is called *after* the corecontext is initialized ? B) can I create the context somehow from within my custom propsal collector with public API that does not interfere with the builtin JDT completion ? C) Is there a more public (and just as efficient) API to detect where a codecompletion is actually performed ? (e.g. to see if it is on a string)

Files changed in fix:
org.eclipse.jdt.ui/ui/org/eclipse/jdt/ui/text/java/JavaContentAssistInvocationContext.java