ECD is suddenly failing to present decompiled classes

[davidmichaelkarr]

I've been using ECD pretty regularly for a long time now. I've been using 2025-09 since it came out, and I've used ECD in it numerous times. A few days ago I had to create a new workspace because of an unrelated problem, and then I reimported my saved preferences from a few months ago. I'm now seeing that instead of the decompiled class, I'm getting the "Class File Editor" and "Source not found".

In "File Associations", I have both ".class" and ".class without source". They both have both the "Class File Viewer" and "Class Decompiler Viewer", but ".class" has what I believe is the correct order, with the "Class Decompiler Viewer" being first, and the other being second, and when I first looked at this, I'm fairly certain that ".class without source" also had the same order, but in trying to get this working, I tried to delete the ".class without source" file association, and I realized I didn't know how to recreate it properly, so I just created a new one and entered ".class without source", and I thought it had the correct values, but I now see that the "Class Decompiler Viewer" is second in the list. Do I have to uninstall and reinstall the plugin to resolve this?

[jpstotz]

Have you checked the log files Eclipse creates inside your project workspace .metadata folder for ECD related errors?

If there are no ECD errors and just the file associations are wrong and you don't have many other file associations you could try to reset them to default by deleting it's preferences entry.

It seems that deleting the editors line from .metadata/.plugins/org.eclipse.core.runtime/.settings\org.eclipse.ui.workbench.prefs should so this.

[davidmichaelkarr]

It occurs to me that the classes it does not decompile fit a particular category. They correspond to a class corresponding to Java source in a project in my workspace, but for a different version of the maven artifact than is open in my workspace. For instance, if my current project specifies version 1.0.1 of artifact "foo" in the project's pom.xml file, and I have the "foo" project open in my workspace, but the pom.xml specifies version 1.0.0, and I attempt to debug a test that has a breakpoint in a class in the "foo" artifact, it will not show the decompiled source. However, if I instead check out the branch of "foo" for version "1.0.1" and then rerun the test, it doesn't decompiled source, it just shows the source. I can walk up the callstack to look at classes that do not reside in an artifact that I have open in my workspace, and those are all properly showing the decompiled source.

This is sort of like "workspace resolution" that the m2e plugin can set. I always turn off workspace resolution, but it doesn't seem to make any difference. I want Eclipse to look at the artifacts in my local maven repo, not in my workspace. I imagine your plugin isn't able to see or use that setting, just mentioning the similarities.

[jpstotz]

That is the way Eclipse works. If you have a Maven dependency that matches on open project in your current workspace then this project will be used instead of the Maven dependency. This is IMHO a very powerful and useful feature and allows selective modification and debugging on large projects. I don't think you can change that behavior. If you want to use a JAR dependency from the local Maven repo you should open the "foo" project 1.0.1 in a different Eclipse Workspace.