Community
Participate
Working Groups
The Eclipse Neon M7 provides KeywordCompletionProposalComputer & IdentifierCompletionProposalComputer classes which doesn't use "instanceof" to check that the given ContentAssistInvocationContext is a JavaContentAssistInvocationContext: ``` public class IdentifierCompletionProposalComputer implements IJavaCompletionProposalComputer { public List computeCompletionProposals(ContentAssistInvocationContext context, IProgressMonitor monitor) { JavaContentAssistInvocationContext javaContext = (JavaContentAssistInvocationContext) context; ``` It's a big problem for typescript.java which is based on JSDT and which defines TypeScriptContentAssistInvocationContext (see issue at https://github.com/angelozerr/typescript.java/issues/56) So with oEclipse Neon M7, when I do completion with my TypeScriptEditor based on JSDT Edit, I have a popup error with this error ``` java.lang.ClassCastException: ts.eclipse.ide.jsdt.internal.ui.editor.contentassist.TypeScriptContentAssistInvocationContext cannot be cast to org.eclipse.wst.jsdt.ui.text.java.JavaContentAssistInvocationContext at org.eclipse.wst.jsdt.internal.ui.text.java.KeywordCompletionProposalComputer.computeCompletionProposals(KeywordCompletionProposalComputer.java:45) ``` and ``` java.lang.ClassCastException: ts.eclipse.ide.jsdt.internal.ui.editor.contentassist.TypeScriptContentAssistInvocationContext cannot be cast to org.eclipse.wst.jsdt.ui.text.java.JavaContentAssistInvocationContext at org.eclipse.wst.jsdt.internal.ui.text.java.IdentifierCompletionProposalComputer.computeCompletionProposals(IdentifierCompletionProposalComputer.java:49) ``` It should b every cool if you could check that ContentAssistInvocationContext is an instanceof JavaContentAssistInvocationContext: ``` public class IdentifierCompletionProposalComputer implements IJavaCompletionProposalComputer { public List computeCompletionProposals(ContentAssistInvocationContext context, IProgressMonitor monitor) { if (context instanceof JavaContentAssistInvocationContext) { JavaContentAssistInvocationContext javaContext = (JavaContentAssistInvocationContext) context; ``` for : * http://git.eclipse.org/c/jsdt/webtools.jsdt.git/tree/bundles/org.eclipse.wst.jsdt.ui/src/org/eclipse/wst/jsdt/internal/ui/text/java/IdentifierCompletionProposalComputer.java * http://git.eclipse.org/c/jsdt/webtools.jsdt.git/tree/bundles/org.eclipse.wst.jsdt.ui/src/org/eclipse/wst/jsdt/internal/ui/text/java/KeywordCompletionProposalComputer.java For your infomration, I have created my own TypeScriptContentAssistInvocationContext, because I need IResource and I don't use IJavaCompilationUnit. If http://git.eclipse.org/c/jsdt/webtools.jsdt.git/tree/bundles/org.eclipse.wst.jsdt.ui/src/org/eclipse/wst/jsdt/ui/text/java/JavaContentAssistInvocationContext.java could just define a getter for the Editor, I think I could use directly JavaContentAssistInvocationContext to retrieve my IResource from the getEditor getter. Hope this issue will be able to fixed for Neon release, otherwise typescript.java will not work with Eclipse Neon release -( (we must desactivate the whole JSDT completions to avoid having those 2 popup errors) Many thanks for your help!
@Angelo JavaContentAssistInvocationContext defines method getCompilationUnit() that returns a CompilationUnit for you. You can use its getResource() method to get the underlined resource.
New Gerrit change created: https://git.eclipse.org/r/73523
Information for PMC Defect Review: * Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. The fix adds the required "instanceof" checks to Completion Proposal Computers and two new methods required by adopters. * Is there a work-around? If so, why do you believe the work-around is insufficient? No. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Tested manually. * Give a brief technical overview. Who has reviewed this fix? The fix is reviewed by Victor Rubezhny * What is the risk associated with this fix? There is no risk.
Thanks @Victor for the fix! > JavaContentAssistInvocationContext defines method getCompilationUnit() that returns a CompilationUnit for you. You can use its getResource() method to get the underlined resource. Yes I know, I do that inside tern.java. But in typescript.java context (and tern.java too), I don't need this compilation unit (I would like to avoid 2 parsing (one for ICompilationUnit although I don't need it, and one parse done with TypeScript tsserver) More with JSDT 2.0.0, teh compute of ICompilationUnit is slow because of esprima parser. With typescript.java I have redefined my own editor which uses JSDT features like completion, syntax coloration, etc and I don't compute an ICompilationUnit (it's very fast). That's why it should be very cool if we could retrieve the editor (just by adding a getter for the editor) from JavaContentAssistInvocationContext (after that I could retrieve the resource)
@Angelo, I have added two new methods to the context: - getResource() - getEditor(), but you have not to use getResource() because it uses ICompilationUnit to find the resource - so it wouldn't work for you. Instead of this, use getEditor() method to get the editor then follow your plan to retrieve a resource from that editor.
Very cool @Victor, many thanks!
looks good thanks
Gerrit change https://git.eclipse.org/r/73523 was merged to [master]. Commit: http://git.eclipse.org/c/jsdt/webtools.jsdt.git/commit/?id=cb93c04d2141213ca19a1ba8ca638119aca22fb9
Works like a charm, thank's Victor!
