ECD incompatible to Eclipse 2024-03 - NoSuchMethodError: 'java.lang.Object org.eclipse.jdt.internal.core.BinaryType.getElementInfo()' #103
Comments
|
@jochenw Is there a simply way to get this beta version so I could look at it myself? |
|
@jpstotz First of all, thanks for your response. It's good to see the plugin not abandoned. I have just used the following procedure to reproduce the issue: 1.) Download the Eclipse distribution: 2.) Extract the distribution, and launch Eclipse 4.31RC2: 3.) Switch to a new, empty workspace. |
|
Thanks for the detailed explanation. Unfortunately testing the ecd release version is not what I want to do, instead I am using the latest development version, as it doesn't make sense to fix bugs in a version that may have been already fixed (or just do not occur) in the development version. Unfortunately using ecd dev version I am not able to reproduce the NoSuchMethodError: BinaryType.getElementInfo(). Using the beta version of Eclipse as target platform to compile the ecd code also does not show any errors regarding getElementInfo() in DecompilerSourceMapper.findSource(..). Therefore I can not confirm an API change at this point. However CFR has other problems, may be what you have encountered was a follow-up error if the CFR problem. Or the problem is related to the org.sf.feeling.decompiler.source.attach plugin/feature. I can not run this at the moment because the beta version misses the package |
|
@jpstotz Could you, please, clarify, what the "latest development version" means, exactly? I am askin, because I can reproduce the same error with the latest nightly build (I20240311-1800). Besides, the problem is not related to CFR. I get the same error with JD-Core, or Fernflower. |
|
@jochenw Sorry this is a misunderstanding, I was talking about the latest development version of ecd, not Eclipse. |
|
@jpstotz Okay. Are there any instructions for building from source? |
|
Silly me. Found the README.md. Doesn't work, though: |
|
I installed Eclipse 2024-03 today. The ECD-plugin fails with the reported exception in the first comment. |
|
Hi, same here. |
jpstotz
changed the title
|
@jochenw I use My latest code updates can be found in branch https://github.com/ecd-plugin/ecd/tree/develop341 My main problem at the moment is that the error only occurs when the plugin is actually installed from an update site as jar. In development mode where I can debug everything works fine. After building the JAR files, installing and running them I also get the BTW: I am planning to delete the source.attach plugin as it would be a lot of work to adapt it to Eclipse 2023-04. Any dissenting votes? |
|
I don't personally use that plugin if my vote counts at all. 🙂 Definitely appreciate you looking into the cause of this even though the code seems to be fighting back at you with this Eclipse upgrade. |
|
Hi all, I was following this thread having the same issue. @jpstotz Regarding your last request regarding "source.attach plugin", which feature does it provide ? My personal use of the ECD plugin is as follows :
Would it still be working if you delete the source.attach plugin ? |
|
@OlivierJaquemet From what I have seen in the code sources.attach.plugin searches for source code in various online sources like Maven repos, grepcode.com, Java 6/7 JDK HG repos, some FTP servers. The idea seemed to be to better use actual source code if available than decompiling Java byte code class files. In my understanding Eclipse can already retrieve sources from most of the providers itself, so this plugin is no longer necessary. I already removed some of the online sources that were down for years. The full list of source can be seen in the source code: Note that I have joined ecd project some years ago, long after this plugin was coded (my guess is that this plugin was mainly developed between 2000 and 2010). So none of the code in sources.attach has been written by me. So everything I know about this plugin is what I learned by reading the source code. |
|
I have the same issue... It looks like that method was removed in the latest update ? It worked before the update. Looks like the last Eclipse update changed preferences for File Associations for *.class from 'Java Editor' to ;Class Decompiler'. So every class fiel view results in this error. Changing it back fixes the issue when source is attached. I'm not an Eclipse developer, just a user, I really don't want to rebuild ecd. Is there an easy way to download a fix jar version and add it to the Eclipse installation manually ? |
|
Now I understand better what the problem is: The Eclipse developers have changed for some methods the return type. This changes the method signature as
becomes
This means the method Looks like I have to change those method calls to use reflection. As they are called very infrequent this should not cause any performance problem. |
|
I managed to make the necessary code changes and built a new beta version. Please give the attached version a try. It seems to work at least partially. Edit 2024-03-16: Outdated 3.4.1.beta1 removed. Please use the latest beta (see below). |
Just tried it out and it seems to work for me with a few classes I attempted opening using JD-Core, Procyon, and Vineflower. I am getting this though when opening using CFR: |
|
@miller79 It seems like the CFR problem is related to #87. Until Eclipse 2024-03, when the user selected to decompile a class with CFR then ECD did not even try to decompile the class with CFR but internally used FernFlower (seems to be some sort of automatic fallback that is totally defect). I think the ECD code to use CFR as decompiler was never working. But as FernFlower was used instead of CFR nobody ever realized this (and it even lies about the used decompiler in the decompiler report). What I don't understand at the moment is why ECD never tried to use CFR until now. I would somehow understand if it tries to use CFR, gets an exception and then performs a fallback to FernFlower, but it never tries. Only on Eclipse 2024-03 suddenly it uses CFR as decompiler and then gets this exception as the code to use CFR doesn't work. |
|
@miller79 The new version should fix the CFR problem. Also the decompilation report now shows the really used decompiler. |
|
@jpstotz I have just tried out the beta2 with the situations I typically use it for and it appears to be working for everything so consider it a checkmark from me at least! Thanks for putting in the weekend oil on this! |
|
Hi, latest beta (2) seems to be working fine for me. |
|
Hi, I just tried beta 2, on two different Eclipse workspace, and unfortunately got the same two errors on both.
Are you aware of a common mistake I could have made during the installation of the beta that would lead to the errors below ?
|
@OlivierJaquemet Is it possible that you use an Eclipse version that still has the old JAD has been removed in ECD 3.3.0, therefore this plugin should no longer be active. Not sure how Eclipse handles this when you upgrade to a new ECD version but one plugin/feature does no longer exist. Please check your installed feature list in Help -> About Eclipse if you have this outdated feature installed and uninstall it. Anyway thanks for the stack trace. I will try to enhance ECD to only log such errors or ignore the outdated plugins. |
|
Hi, |
|
Thanks for all the feedback. Looks like ECD on Eclipse 2024-03 is now working stable. In the end I decided to rename the version to 3.5.0. ECD 3.5.0 has been published and the software update site has been updated. |
Hi, |
|
@pmorange
|
|
Thanks. |
|
I am happy to report, that the following procedure works for me with Eclipse 4.31: 1.) Remove all folders with org.sf.feeling.decompiler from the Eclipse "features" folder. If possible, I'd hope for an upcoming formal release. Thanks very much for your efforts, @jpstotz! |
The official version 3.5.0 is the one from the project's update site: https://ecd-plugin.github.io/update/ In difference to 3.4.1 beta 2 a bug was corrected that caused Fernflower not to be available. Eclipse Marketplace in the end also uses this update site but the description and shown version is stored in their database, thus I wouldn't call it an official release. Yesterday evening I simply did not had the time to update the Eclipse Marketplace database. |
|
I missed that thread.
I disagree with this. There was a NPE in the code calling CFR that was causing the fallback. You fixed it in this commit 6c3710c by adding : classFileSource.informAnalysisRelativePathDetail(null, null);For the source attach plugin, I called the method |
When attempting to use the plugin in Eclipse 4.31M2, I get the stacktrace below. My understanding is, that this indicates a change in the plugin API, which requires corresponding changes in the plugin.
The text was updated successfully, but these errors were encountered: