Community
Participate
Working Groups
(This is reproduced in a fresh install of Eclipse 4.4 Luna, in a fresh project.) In a new Java project, create a file in the default namespace named "foo-bar.java". In that file, insert the following code: class Wrong { String first; void test() { return this.first. } } Place the cursor after "first.", and press Ctrl+Space to bring up the autocomplete menu. If you select a method with zero parameters (e.g., toLowerCase()) and press Enter, it'll autocomplete just fine. If you select a method with more than zero parameters (e.g. compareTo(String anotherString)) and press Enter, it'll fail to autocomplete. The error log shows this stack trace: java.lang.IllegalArgumentException at org.eclipse.jdt.core.Signature.appendTypeSignature(Signature.java:952) at org.eclipse.jdt.core.Signature.appendTypeSignature(Signature.java:855) at org.eclipse.jdt.core.Signature.toCharArray(Signature.java:2637) at org.eclipse.jdt.core.Signature.toString(Signature.java:2848) at org.eclipse.jdt.internal.ui.text.java.ParameterGuesser.createVariable(ParameterGuesser.java:219) at org.eclipse.jdt.internal.ui.text.java.ParameterGuesser.evaluateVisibleMatches(ParameterGuesser.java:133) at org.eclipse.jdt.internal.ui.text.java.ParameterGuesser.parameterProposals(ParameterGuesser.java:298) at org.eclipse.jdt.internal.ui.text.java.ParameterGuessingProposal.guessParameters(ParameterGuessingProposal.java:329) at org.eclipse.jdt.internal.ui.text.java.ParameterGuessingProposal.computeGuessingCompletion(ParameterGuessingProposal.java:254) at org.eclipse.jdt.internal.ui.text.java.ParameterGuessingProposal.computeReplacementString(ParameterGuessingProposal.java:220) at org.eclipse.jdt.internal.ui.text.java.LazyJavaCompletionProposal.getReplacementString(LazyJavaCompletionProposal.java:331) at org.eclipse.jdt.internal.ui.text.java.AbstractJavaCompletionProposal.apply(AbstractJavaCompletionProposal.java:365) at org.eclipse.jdt.internal.ui.text.java.JavaMethodCompletionProposal.apply(JavaMethodCompletionProposal.java:58) at org.eclipse.jdt.internal.ui.text.java.ParameterGuessingProposal.apply(ParameterGuessingProposal.java:124) at org.eclipse.jdt.internal.ui.text.java.AbstractJavaCompletionProposal.apply(AbstractJavaCompletionProposal.java:495) at org.eclipse.jdt.internal.ui.text.java.LazyJavaCompletionProposal.apply(LazyJavaCompletionProposal.java:489) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.insertProposal(CompletionProposalPopup.java:940) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.verifyKey(CompletionProposalPopup.java:1339) at org.eclipse.jface.text.contentassist.ContentAssistant$InternalListener.verifyKey(ContentAssistant.java:808) at org.eclipse.jface.text.TextViewer$VerifyKeyListenersManager.verifyKey(TextViewer.java:491) at org.eclipse.swt.custom.StyledTextListener.handleEvent(StyledTextListener.java:65) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1057) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1081) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1066) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:778) at org.eclipse.swt.custom.StyledText.handleKeyDown(StyledText.java:5954) at org.eclipse.swt.custom.StyledText$7.handleEvent(StyledText.java:5636) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1057) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1081) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1066) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1108) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1104) at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1525) at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:4723) at org.eclipse.swt.widgets.Canvas.WM_CHAR(Canvas.java:344) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4611) at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:340) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4977) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2549) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3757) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1113) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:997) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:138) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:610) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:567) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591) at org.eclipse.equinox.launcher.Main.run(Main.java:1450) at org.eclipse.equinox.launcher.Main.main(Main.java:1426) Bizarrely, if you rename "foo-bar.java" to "foo_bar.java", or "foobar.java" -- i.e., anything without a dash in the name -- then the autocompletion will work just fine.
(In reply to Benjamin Lerner from comment #0) > Bizarrely, if you rename "foo-bar.java" to "foo_bar.java", or "foobar.java" > -- i.e., anything without a dash in the name -- then the autocompletion will > work just fine. It is a problem, but it is not bizarre :) Binding key parser is not prepared for - being a part of the signature. This also means in that in package info this problem can (and does) show up. I would think the best course is to avoid '-' in file names. I can imagine that there could be other scenarios that break too. This is not likely to get worked on in a hurry. If someone will provide a fix, we will consider.
I'm glad you can confirm that dashes are the actual cause of this bug; I was very confused when I tried the exact same code in another file (named dummy.java) and it worked, and thought maybe I was having some strange interaction with other plugins or stale state or almost anything else. For now, I can work around the file naming issue. I'd been using file name patterns of "hw###-p###-tests.java" and "hw###-p###-soln.java" for the particular homeworks I've been developing, and I can relatively straightforwardly change to using underscores instead. (Obviously, this isn't following the typical Java file name convention, and it's not one I'd use in any non-trivial project, but it works perfectly for the assignments in my course.) But I'm curious: nothing in the stack trace below looks to me like it depends on filenames, so where does that particular interaction arise from? (I'm not at all familiar with the Eclipse code base, but can follow links to particular source files well enough.) And why does it only manifest when trying to enter methods with more than zero parameters?
(In reply to Benjamin Lerner from comment #2) > But I'm curious: nothing in the stack trace below looks to me like it > depends on filenames, so where does that particular interaction arise from? > (I'm not at all familiar with the Eclipse code base, but can follow links to > particular source files well enough.) And why does it only manifest when > trying to enter methods with more than zero parameters? This frame: org.eclipse.jdt.internal.ui.text.java.ParameterGuessingProposal.guessParameters(ParameterGuessingProposal.java:329) would explain the latter question. For the former, somewhere in BindingKey parser there is a call to isValidJavaIdentifier() as components of the binding key are being scanned and parsed. A binding key is an internal abstraction somewhat akin to manged names in C++. It is a unique textual encoding of each symbol in the program. To achieve unique encoding, we likely encode the file name for secondary types.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
I still see this error in Eclipse 2019-03, with JDT 3.17.0.v20190307-0500. (I don't have a more recent Eclipse installed at the moment.) The stack trace nearly identical (especially the top of the stack about the ParameterGuesser), so this bug still exists. It doesn't always trigger with every non-nullary method, and I haven't figured out the pattern yet, but it does reproduce with several methods on the example code below. (Probably unrelatedly, trying to view this event triggers another NPE in a mouse-event handler in the Error Log view itself, which made finding this error a bit tricky...)
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This bug still reproduces in Eclipse 2022-03, which is the most recent version I have readily available. The autocomplete behavior is subtler than I expected: - it'll autocomplete `this.first.charAt` and fill in `(0)` as a completion - it'll autocomplete `this.first.codePointAt` and fill in `(0)` - it will *not* autocomplete `this.first.concat` or any other method expecting a string, and will give essentially the same stack trace as below - it *will* autocomplete `this.first.contentEquals`, and fill in `(null)` as a completion - it will complete `this.first.getBytes` and fill in `(null)` - it will complete `this.first.indexOf` if I pick the overload with only int arguments, but will *not* complete if I pick the overload with a string argument. All of the failures still go away if I rename the file to remove the dash in the filename. I can kinda figure that autocompletion works when the parameters are primitive types. But I'm surprised that autocompletion fails *inconsistently* when the parameters are reference types -- it only seems to fail on Strings, but not other nullable types.
