Eclipse code error marks does not auto-refresh - eclipse

I am working with Eclipse Photon 4.8.0 and I'm facing a weird behaviour when I'm working with Java files.
When I make a change in a file, usually Eclipse refresh the code reviewer automatically, marking errors and warnings on the fly in the code. This is not happening to me. The code marks appears or disappears only when I save the file.
I suppose there is some preference option to allow auto-refresh for this code checks, but I can't find it.

In Window > Preferences: Java > Editor check the checkbox Report problems as you type.

I think that actually it's not a fix for the problem, but I delete this Eclipse and downloaded Eclipse Oxygen. Now it works. I suppose it's a bug for the new Eclipse Photon.

Related

Eclipse IDE - Open Call Hierarchy is empty/broken

What should I do, if the "Open Call Hierarchy" is broken (empty for every method in a project)? It only shows the name of the method I wanted to see the call hierarchy for. This happens for all methods I try, even though they are all called by other methods.
It is very useful for code navigation. I do not know how to work without it!
I've tried:
Opening eclipse.exe -clean -refresh
Restarting Eclipse
Closing and reopening the project
Updating the project
Renaming the .metadata file
I've checked that it searches the whole workspace, and there are no filters on.
The following may help:
Calling eclipse with eclipse.exe -clean -refresh forces Eclipse to rebuild the index. After that the feature worked again.
Closing and re-opening the project.
I also tried the suggestions above, as well as the hint given here: http://mschrag.blogspot.co.at/2009/01/open-type-cant-find-your-class.html
Nothing worked until today when I found out that I am a donkey...
I once configured a filter in the "Call Hierarchy" view and so no entries were shown because filtered out. Once I removed / disabled the filter everything worked fine again.
When you go to the eclipse bug report for this issue, somebody says, you should install over the Market place the Java 12 support.
When I installed it, it was working properly again
Also, you can try to delete the workspace and get it recreated. Make sure all your projects are backed up.
For Kepler and PDT (PHP IDE) it is broken in at least PDT 3.2.0 and 3.3.0 (tried them both). The fix is in 3.3.1 and updating to that was all I had to do get the call hierarchy working again.
(apologies, I'm not yet allowed to add comments, however this should prove handy to many)
In my case it seemed my workspace was contaminated.
Opening/closing projects and starting with clean did not fix. I had to start off a new workspace.
Fedora 20, Eclipse Kepler.
I have the same behavior with eclipse Kepler (4.3.2).
I found out, that there is a bug with methods with signature of:
void get(Object o)
Object get(Object o)
In the eclipse Error Log view I find the following exception:
java.lang.NullPointerException
at org.eclipse.jdt.internal.core.search.matching.ClasspathSourceDirectory.directoryTable(ClasspathSourceDirectory.java:52)
at org.eclipse.jdt.internal.core.search.matching.ClasspathSourceDirectory.findClass(ClasspathSourceDirectory.java:109)
at org.eclipse.jdt.internal.core.search.matching.JavaSearchNameEnvironment.findClass(JavaSearchNameEnvironment.java:146)
at org.eclipse.jdt.internal.core.search.matching.JavaSearchNameEnvironment.findType(JavaSearchNameEnvironment.java:185)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:145)
at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:197)
at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage(Scope.java:2799)
at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2556)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.getType(MatchLocator.java:899)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.getMethodBinding0(MatchLocator.java:955)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.getMethodBinding(MatchLocator.java:907)
at org.eclipse.jdt.internal.core.search.matching.MethodLocator.matchMethod(MethodLocator.java:327)
at org.eclipse.jdt.internal.core.search.matching.MethodLocator.resolveLevel(MethodLocator.java:664)
at org.eclipse.jdt.internal.core.search.matching.ClassFileMatchLocator.locateMatches(ClassFileMatchLocator.java:209)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:1699)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1143)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1184)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1301)
at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:95)
at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:231)
at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:515)
at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:584)
at org.eclipse.jdt.internal.corext.callhierarchy.CallerMethodWrapper.findChildren(CallerMethodWrapper.java:155)
at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.performSearch(MethodWrapper.java:301)
at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.doFindChildren(MethodWrapper.java:232)
at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.getCalls(MethodWrapper.java:84)
at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.getCalls(DeferredMethodWrapper.java:65)
at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.fetchDeferredChildren(DeferredMethodWrapper.java:79)
at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:235)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
In the end, it looks like a bug in this version:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=401272
I assume, that upgrading at least to version 4.4 (Luna) will solve this problem.
In my case I was trying to get the call hierarchy of a method in the derived class of an abstract class. The requested method was declared abstract in the base class.
When I opened the call hierarchy directly on the abstract method instead of the implemented one, everything worked well. (Eclipse Neon).
My problem was that Open Call Hierarchy was searching only the project not the entire Workspace.
So I had to click on the small down arrow (in the Call Hierarchy view window on the right; it is the "View Menu" arrow -- a triangle pointing down) in Call Hierarchy view, set the Search Scope > Workspace.
Tried everything in all the answers here, but none of them worked for me. Later I figured out that this was a bug in Eclipse 2019-03 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=545293). Try to upgrade your eclipse or install a newer version.
For me installing a newer version(latest version Eclipse 2019-09) solved the problem.
I tried many answers all were great, it helped many except few and I was in few.
My eclipse version is 2019-03(4.11.0). This is which has a bug. Which can be fixed by add-ons.
Go to the Eclipse Marketplace and search for plugin java 12 Support for Eclipse 2019-03(4.11)… and install it. On completion of installation restart the eclipse. Hopefully this will fix the problem. Have a nice day.
If the call Hierarchy is not opening, it might be because of the project is not imported as a java project, rather it would be displayed in the file stucture. You may want to enable the project facet through:
right click on the project -> project facet.
If you dont see anything listed, you need
configure the project facet -> Apply -> ok.

Failed to create the part's controls in Eclipse with Salesforce

I have Eclipse Juno and Force.com IDE. When I try to create new classes they always show: failed to create the part's controls. It worked for the first time, but now they always show this. Same happens if I create them inside the force.com platform.
Error details:
org.eclipse.core.runtime.AssertionFailedException: assertion failed:
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
etc ...
I would appreciate all help.
I had the same error. I fixed it by switching the eclipse workspace. Go to menu File->Switch Workspace->Other, and then select the same workspace you were working with. Eclipse will restart and you should not get the error.
I faced the same issue my default editor for JSP was Web page editor. Which I changed to JSP editor and everything is fine.
PS: To change to JSP editor
Right click on JSP page -->open with jsp .
I got the "failed to create the part's controls" error one day when I opened Eclipse and tried to view a java file I had been working on. When I opened the file I needed, it showed a red X and NullPointerException instead of the code. The error log mentioned "event loop exception" for some reason.
I restarted Eclipse, and the error was still there. I cleaned the project, updated the project, deleted and re-imported the project, deleted and re-imported the file, and the error still was there. As a last resort, I restarted Eclipse again and then the file was fine. So one of the clean/update/delete/import steps worked but I don't know which one.
Use eclipse -clean from command prompt to solve this problem.
I solved my problem like this:
This problem occur because of in eclipse default editor is not able to identify extension of that file. If you right click on file and open it with respective text editor ,problem will be solved
In ecllipse, every file types has some associated default formats and one of the default format set to the particular file type.
You can see this in General -> Editors -> File Associations-
This issue generally occurs when we open any file in the format which is not the default format of the particular types.
I got same issue when I opened one of the Java file in text format in ecllipse and then I started getting the same issue. After research, I observed that AspectJ/Java Editor was setting as default. After reset it to Java Editor, the problem got resolved.
Steps :
1. General -> Editors -> File Associations-
2. Select the content type and choose the default format for it.
3. Restart the ecllipse.
In general, it is some default file format that set in ecllipse causing the same issue.
in my case problem was that the server was resin and I didn't have the resin server extension installed
I solved the problem.
(1)Open the filed with TXT.
(2)Search and Delete the underline between number like:
int a = 10_000;
It works when i compile and run as others used, but it will fail if i save and open again.
I also had for the same problem and fixed it by updating eclipse. Help > Check for Updates.
This worked for me---->
Right click on pom.xml-->open with-->xml editor
Had a similar stacktrace on failed to create the part's controls while trying to open Git repositories view in Git perspective.
My case (cause) is different since I was migrating an Eclipse workspace from an Ubuntu VM to Windows.
Many thing were copied like projects, .git folders, or also .metadata Eclipse folder.
Tried with no success:
uninstall all egit component (installation details, then, install new software
restart eclipse -clean
reset Git repository perspective
I searched and found this invalid UNIX : separator in .metadata\.plugins\org.eclipse.core.runtime\.settings\org.eclipse.egit.core.prefs file.
GitRepositoriesView.GitDirectories=/path1/.git\:/path2/.git
Here, the : is invalid path separator on Windows.
I simply removed the value in this line, saved file, and restarted Eclipse:
GitRepositoriesView.GitDirectories=
(alternative: if needed, try to migrate those linux paths to their Windows equivalent too)
Git repositories view is back.

Eclipse warning: "problems during content assist"

Every time I start Eclipse and press Ctrl + Space I get the following 3 warning popups.
http://imgur.com/a/2pKdm
They are only appearing the first time I press Ctrl + Space.
I get these warnings since i reinstalled the jdk.
I already tried to re-install eclipse, but as soon as I import my old projects the warnings seems to reappear. I currently have the following java versions installed:
JVE 7_u7 32bit;
JVE 7_u7 64bit;
JDK 7_u7 64bit;
JDK 7_u7 32bit.
I added all of them in the PATH variable in the same order as listed above.
I also have eclipse set to use the JDK 7_u7 64bit (btw I'm using eclipse 64bit).
I hope somebody knows a solution for my problem and excuse me for my bad english, I am not an native English speaker. ;)
You can resolve this issue by turning off Subwords-Completion in:
Window > Preferences > Code Recommenders > Completions: ==> incheck(Subwords-Completion)
I got the similar type of warning is eclipse spring tool suite(sts) .I unchecked CodeRecommendors Proposals(addons) which is present 2 times in the above list and below list and it worked.To do it go to window-->preferences-->java-->editor-->Content Assist-->advanced.see the screenshot.
You can configure content assist and disable the triggers in content assist. This link provides information on setting content assist preference.
I would like to share my experience for those who have this problem in the future. If you changed the theme of your editor recently, first change it back to the classic theme and then restart Eclipse. Then switch back to the theme(maybe dark theme) you want to use and restart Eclipse again. This is how my problem was solved.

Eclipse Europa search references feature stopped working

I'm working with Eclipse Version 3.2.1 Build M20060921-0945 on a MS-Windows 2000 SP4 using a JDK 1.5.0-12.
I takes my locale that is es-AR and sets all menu and context in Spanish which I don't like. So I had included in eclipse.ini file one parameter "-nl en".
Since that, "References..." feature in both "Search" and contextual menu stopped working. I removed parameter and ran eclipse with "-clean" but still not working. I don't have any other clue about what is happening. Thank you all in advance.
Beto
Delete all the files in you eclipse data, eg:
<WORKSPACE>/.metadata/.plugins/org.eclipse.jdt.core
This should force eclipse to rebuild its index
Had the same trouble with the latest Indigo release of Eclipse, searching for references of a method or class I selected invariably gave 0 results.
Stopping Eclipse, deleting all files in folder <WORKSPACE>/.metadata/.plugins/org.eclipse.jdt.core, and restarting Eclipse afterwards has solved it.
I see a similar problem where search for references (Ctrl + Shift + G) stops working. It works again if I restart Eclipse, but it's still pretty annoying. I'm thinking maybe there's some keyboard shortcut that I hit sometimes by accident that messes up the search.
Go to {workspace}.metadata.plugins\org.eclipse.search and clear the History section of dialog_settings.xml , worked for me.
After trying all of the above and nothing working, I took another look at the file name pattern I was using for file search:
*.java *.properties, *.vm, *.xml, *.xsd
I was missing the comma after .java, so Eclipse wasn't searching my .java files, it was looking for files that matched the pattern ".java *.properties".
Wow did I feel dumb dumb dumb... adding the comma fixed it! Passing along my simplistic solution in case it does anybody else some good...
Strange as it sounds, it does seem that the keyboard mapping affects this. I had mapped -H to Search in Files, and the Java search started bringing up everything, rather then actual references to the method I was searching for. ~Nothing~ fix this, including the solution above. But remapping the key to Open Search Dialog DID fix it.
I've just come to experience this behaviour with Eclipse Mars 1 Release 4.5.1.
In an specific class only. Clean and build entire workspace does not work but I've updated Maven Project containing that class [Right-click on project -> Maven -> Update Project ...] and it works now.
Hope it helps someone.
I've just come to experience this behavior with Eclipse Mars 1 Release 4.5.1.
I tried everything mentioned above but it did not help.
So I created new workspace, and imported the project and search started working again.
I was facing a similar issue in Eclipse 2019-09 R (4.13.0) on Linux Mint
One thing that worked for me (besides closing and opening Eclipse again) was to click on the search icon and then in the Show Previous Search icon on the tab and then Open in New :
Trash your install.
Then reinstall it.

In Eclipse, why does "Build Automatically" get mysteriously disabled?

I'm running Eclipse Europa (3.3). I leave the "Build Automatically" setting, under the Project menu, on all the time. Once in awhile my code isn't compiling, and I puzzle over it and then pull down the Project menu ... lo and behold, it's not set anymore. What gives? Is this a bug, or is there something else I'm doing that could cause it?
Edit: I am running the regular Java developer installation, plus Subversive and its connectors, Jetty Launcher, and I believe no other plugins. Other people at my workplace have had the same problem.
Edit: I am still having this problem once in a blue moon, only now I'm using Eclipse Galileo (3.5) for Windows. I haven't had this problem in Galileo for OS X, neither in Cocoa nor Carbon, but I have not used that for as long.
With Eclipise Mars.1 (4.5.1), Oomph may be the culprit. Eclipse Oomph supports automatically disabling Build Automatically with entries in
On Windows
%USERPROFILE%\.eclipse\org.eclipse.oomph.setup\setups\user.setup
If you want to disable this Oomph behavior try deleting the following setting
"Eclipse->Navigate Menu-> Open Setup menu entry-> Open User menu entry", a Preference Task under "User Preferences -> org.eclipse.core.resources -> description.autobuilding"
I learned about this setting by posting to the Oomph Eclipse Community Forum on Feb 8th, 2016. I posted a question titled "Oomph Defect? Build Automatically Keeps Getting Disabled". Ed Marks replied the same day with details about Oomph's support for managing the Eclipse "Build Automatically" setting.
https://www.eclipse.org/forums/index.php/m/1722751/#msg_1722751
I don't have eclipse right here to test and make sure but here is an idea.
Is any of the project or even workspace file in SVN ? if they are and they were uploaded with auto build disabled that might explain it
You update and overwrite your settings. This doesn't become apparent until you restart eclipse. this would also explain why other people at your workplace experienc this. it would even explain why some don't : thay are the ones who are careful what they update and don't allow eclipse to overwrite their own settings plus the ones who actually prefer to have autobuild disabled :)
I had the same problem and when I looked at the Source tab under Java Build Path (under the menu Project > Properties ) there were some source directories that didn't exist anymore (marked with a red X). After I deleted them, compilation worked fine and all new .class files are under the bin folder.
Strange. Is there perhaps a plugin installed that turns this off without your knowledge?
Maybe there is some conflicting shortcut. For example, some duplicated shortcut may be toggling it.
I am running 3.4 and I also have this mysterious behavior. I had it in 3.3 as well. I use CVS not SVN. Does not seem to follow a pattern just once in a while it gets switched off and then weird confusing stuff happens until I remember to check it and switch it back on. I am almost to the point where I want to write a plugin to always turn it on when eclipse loads.
When installing Google Plugin for Eclipse, 'Google App Engine for Android' is also installed.
For me, I uninstalled 'Google App Engine for Android', which I didn't need, and solved this problem.