Community
Participate
Working Groups
Don't know how to reproduce, occured once. eclipse.buildId=4.21.0.I20210608-2130 java.version=11.0.10 java.vendor=Red Hat, Inc. BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US Command-line arguments: -data /data/4x_platform_workspace -os linux -ws gtk -arch x86_64 org.eclipse.ui.workbench Error Wed Jun 09 08:58:58 CEST 2021 Problems occurred when invoking code from plug-in: "org.eclipse.ui.workbench". java.lang.UnsupportedOperationException: IClassFile#getType() cannot be used on an IModularClassFile at org.eclipse.jdt.internal.core.ModularClassFile.getType(ModularClassFile.java:114) at org.eclipse.jdt.internal.ui.InterfaceIndicatorLabelDecorator.addOverlays(InterfaceIndicatorLabelDecorator.java:147) at org.eclipse.jdt.internal.ui.InterfaceIndicatorLabelDecorator.decorate(InterfaceIndicatorLabelDecorator.java:125) at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:251) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:105) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:360) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:346) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:386) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:362) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
(In reply to Andrey Loskutov from comment #0) > Don't know how to reproduce Easy one after looking into the code. Just browse a library containing module-info.class from Package Explorer. I have a patch.
This is a recent regression. Also opening module-info.class in an editor fails and results in a bunch of similar errors - nothing we see in 4.20. java.lang.UnsupportedOperationException: IClassFile#getType() cannot be used on an IModularClassFile at org.eclipse.jdt.internal.core.ModularClassFile.getType(ModularClassFile.java:114) at org.eclipse.jdt.ui.actions.FindAction.getTypeIfPossible(FindAction.java:156) at org.eclipse.jdt.ui.actions.FindAction.getJavaElements(FindAction.java:173) at org.eclipse.jdt.ui.actions.FindAction.canOperateOn(FindAction.java:115) at org.eclipse.jdt.ui.actions.FindAction.selectionChanged(FindAction.java:278) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchSelectionChanged(SelectionDispatchAction.java:262) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.selectionChanged(SelectionDispatchAction.java:257) at org.eclipse.jface.viewers.Viewer$1.run(Viewer.java:151) java.lang.UnsupportedOperationException: IClassFile#getType() cannot be used on an IModularClassFile at org.eclipse.jdt.internal.core.ModularClassFile.getType(ModularClassFile.java:114) at org.eclipse.jdt.ui.actions.FindAction.getTypeIfPossible(FindAction.java:156) at org.eclipse.jdt.ui.actions.FindAction.getJavaElements(FindAction.java:173) at org.eclipse.jdt.ui.actions.FindAction.canOperateOn(FindAction.java:115) at org.eclipse.jdt.ui.actions.FindAction.selectionChanged(FindAction.java:278) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchSelectionChanged(SelectionDispatchAction.java:262) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.selectionChanged(SelectionDispatchAction.java:257) at org.eclipse.jface.viewers.Viewer$1.run(Viewer.java:151)
This is a regression from bug 571252 / https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/176407. Reverting commit https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=e272418664889ea9c3e0b165831872cc96e6eb69 fixes all errors. The problem is that the hierarchy of AbstractClassFile was changed - it implements now IOrdinaryClassFile which is wrong, because ModularClassFile is NOT an IOrdinaryClassFile and never will be, but it is a subclass of AbstractClassFile. I would revert the parts of the commit in question as it clearly breaks the type hierarchy design.
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/181748
(In reply to Andrey Loskutov from comment #3) > This is a regression from bug 571252 / > https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/176407. > > Reverting commit > https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=e272418664889ea9c3e0b165831872cc96e6eb69 fixes all errors. > > The problem is that the hierarchy of AbstractClassFile was changed - it > implements now IOrdinaryClassFile which is wrong, because ModularClassFile > is NOT an IOrdinaryClassFile and never will be, but it is a subclass of > AbstractClassFile. > > I would revert the parts of the commit in question as it clearly breaks the > type hierarchy design. For these performance issues, there must be some sort of quantification of how much performance has been improved.
(In reply to Vikas Chandra from comment #5) > For these performance issues, there must be some sort of quantification of > how much performance has been improved. See bug 571252 comments. It is not bad in general to change code for whatever useful reason it could be, and it is usual that changes cause regressions, and it is clear that such a big codebase like JDT has not a 100% test coverage that allows those regressions to happen without any test failure. What I personally would find very useful, if the contributors that caused regressions would afterwards add missing regression tests that check code in question. That would *really* help everyone here.
(In reply to Andrey Loskutov from comment #6) > What I personally would find very useful, if the contributors that caused > regressions would afterwards add missing regression tests that check code in > question. That would *really* help everyone here. Its hard to write a test for a workflow someone is unfamiliar with. While i also ask for regression tests it's too much to expect from every developer being able to write such a test. Nevertheless i will give it a try for this one.
(In reply to Andrey Loskutov from comment #6) > What I personally would find very useful, if the contributors that caused > regressions would afterwards add missing regression tests that check code in > question. That would *really* help everyone here. Thanks Andrey for fixing this - and also mentioning the above. @Joerg: "All Code fixes should have test cases that test the fix. " - This is from the JDT Charter - https://wiki.eclipse.org/JDT/Charter - under Lifecycle of Bug Section - Please read this. (In reply to Jörg Kubitz from comment #7) > also ask for regression tests it's too much to expect from every developer > being able to write such a test. @Joerg: Point blank: If the developer is not wanting to write regression test for the code he/she wrote, then that developer *should* not contribute to JDT.Core.
(In reply to Manoj Palat from comment #8) > @Joerg: Point blank: If the developer is not wanting to write regression > test for the code he/she wrote, then that developer *should* not contribute > to JDT.Core. I totally agree. But "wanting" and "being able to" is still a difference. Are you able to write tests for arbitrary workflows in a fair amount of time? As far as i understand the root reason that i did not see the error in advance is that the deprecated IClassFile.getType() was never removed. It's not used anymore except in the IOrdinaryClassFile.getType() @Override annotation. What is the suggested way to get rid of the deprecated API methods? Are there plans todo so?
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/181766
(In reply to Jörg Kubitz from comment #9) > > As far as i understand the root reason that i did not see the error in > advance is that the deprecated IClassFile.getType() was never removed. It's > not used anymore except in the IOrdinaryClassFile.getType() @Override > annotation. @Joerg: Don't worry about not seeing the error here - That happens to all of us even after working with the code for years. No one expects to write an error-free fix all the time. My point was about your statement on expectation of writing the tests - every fix in jdt.core is expected to have regression tests. If it is not possible to do so, then its better to call it out in the bug and ask for exception/help - help may depend on the bandwidth of people. Generally, whenever we review, this is a point checked but sometimes for very simple/straightforward cases the reviewer may choose to opt out. JDT.core being at the base of the layers, one can never be too careful. > What is the suggested way to get rid of the deprecated API methods? Are > there plans todo so? There is a process for the same. You can read about it here: https://wiki.eclipse.org/Eclipse/API_Central/Deprecation_Policy https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process @Vikas: As the PDE owner, do you want to add anything on the API part from the api analysis tool point of view?
>>Vikas: As the PDE owner, do you want to add anything on the API part Nothing to add. See Bug 569394 and Bug 541068 as an example to remove an API (IModelProvider)
> @Joerg: Don't worry about not seeing the error here - That happens to all of I still feel so dumb. Thanks for encouragement. > > What is the suggested way to get rid of the deprecated API methods? Are > > there plans todo so? > There is a process for the same. You can read about it here: > https://wiki.eclipse.org/Eclipse/API_Central/Deprecation_Policy > https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process I do not feel confident to start such a process. a) It requires a significant time to pass. I can not guarantee i am still here in 2 years. b) I still don't know how to inform adopters. For JDT there are so many 3rd parties and the recognition of and feedback on the eclipse mailing lists seems to be poor. c) No chance to mark for removal without java.lang.Deprecated.forRemoval becuase its JDK 9 - which JDT does not support. So i leave it up for the core team. BTW: How to install eclipse so that i am using always the latest build (without running it inside the debugger)? My 4.19 does not even update to 4.20.
(In reply to Jörg Kubitz from comment #13) > > @Joerg: Don't worry about not seeing the error here - That happens to all of > > I still feel so dumb. You are not alone :-) > BTW: How to install eclipse so that i am using always the latest build > (without running it inside the debugger)? My 4.19 does not even update to > 4.20. https://wiki.eclipse.org/Platform/How_to_Contribute#.5B1.5D_Get_an_Eclipse_SDK I do this procedure every work day: 1) Download nightly SDK build from https://download.eclipse.org/eclipse/downloads/, extract, start with empty workspace. 2) Import the plugins via "File>Import...>Install>Install Software Items from File" from http://git.eclipse.org/c/platform/eclipse.platform.ui.git/plain/releng/org.eclipse.ui.releng/platformUiTools.p2f 3) Restart & switch to the main workspace Except for the download, the rest takes usually less than 3 minutes and I have the latest build every day in use. Others may use Oomph, but that's not my personal preference, so can't say much here.
Gerrit change https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/181748 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=1184ecf4227c74965e28b8095bee599284112027
Gerrit change https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/181766 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=97dcb461cc60f8bcedb72b954b9606e78f355363
Works in I20210610-1850
.
