java.lang.NoSuchMethodError with java-1.7.0-openjdk-1.7.0.25-2.3.10

Question

I'm using yEd on Fedora 17 Linux with the OpenJDK. Since updating to java-1.7.0-openjdk-1.7.0.25-2.3.10.3.fc17.x86_64, yEd does not start anymore. When running the previous version java-1.7.0-openjdk-1.7.0.19-2.3.9.6.fc17 everything works fine.

This is the error message I get:

B.A.A.F.A @ jar:file:/opt/yed/yed.jar!/B/A/A/yed-layer.xml[413:34]: B.A.A.a.N: java.lang.NoSuchMethodError: sun.reflect.Reflection.getCallerClass(I)Ljava/lang/Class;
    at B.A.A.F.Q.ā(Unknown Source)
    at B.A.A.F.S$B.ā(Unknown Source)
    at B.A.A.F.S$B.ā(Unknown Source)
    at B.A.A.F.S$B.ā(Unknown Source)
    at B.A.A.F.S$B.endDocument(Unknown Source)
    at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endDocument(AbstractSAXParser.java:742)
    at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.endDocument(XMLDTDValidator.java:928)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:494)
    at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:835)
    at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
    at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123)
    at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1210)
    at B.A.A.F.S.ā(Unknown Source)
    at B.A.A.Z.G$1.ā(Unknown Source)
    at B.A.A.Z.G.Ƙ(Unknown Source)
    at B.A.A.Z.G.Ă(Unknown Source)
    at B.A.A.Z.C.run(Unknown Source)
    at B.A.A.F.ā(Unknown Source)
    at B.A.A.F.Ă(Unknown Source)
    at B.A.A.F.ā(Unknown Source)
    at B.A.A.B.ā(Unknown Source)
    at B.A.A.B.main(Unknown Source)
Caused by: B.A.A.a.N: java.lang.NoSuchMethodError: sun.reflect.Reflection.getCallerClass(I)Ljava/lang/Class;
    at B.A.A.a.Q.ā(Unknown Source)
    at B.A.A.a.Q.ă(Unknown Source)
    at B.A.A.F.O.ā(Unknown Source)
    at B.A.A.F.R.ā(Unknown Source)
    ... 22 more
Caused by: java.lang.NoSuchMethodError: sun.reflect.Reflection.getCallerClass(I)Ljava/lang/Class;
    at com.jidesoft.plaf.UIDefaultsLookup.getCallerClassLoader(Unknown Source)
    at com.jidesoft.plaf.UIDefaultsLookup.get(Unknown Source)
    at com.jidesoft.pane.CollapsiblePanes.updateUI(Unknown Source)
    at javax.swing.JPanel.<init>(JPanel.java:86)
    at javax.swing.JPanel.<init>(JPanel.java:109)
    at javax.swing.JPanel.<init>(JPanel.java:117)
    at com.jidesoft.pane.CollapsiblePanes.<init>(Unknown Source)
    at B.A.A.P.X.<init>(Unknown Source)
    at B.A.A.P.B.<init>(Unknown Source)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
    ... 26 more
 

I guess that it has to do with the Jide docking library. Would you mind to update it to a newer version compatible with newer OpenJDK versions?

I do really want to use OpenJDK as this is the only Java which is automatically updated by Fedora. This is also why I do not want to use an embedded java - there are no security updates for it.

 

Comments

Same error for me (yEd 3.11) using OpenJDK 1.7.0.25 (same version) but for FC18 x86_64 -- the work I have to submit today won't be finished :/

Answer 1

1. yEd officially supports only Oracle Java.
2. You do not need security updates for embedded Java runtimes that come with yEd. These runtimes do not register any browser plugins and therefore cannot be exploitet from the web.

That said, would you mind telling us which exact version of yEd you are using? This does not look like a Jide specific problem - more like a general bug in OpenJDK's implementation of reflection. Knowing the exact version will help investigating this problem.

Comments

This is with yEd 3.11.

We had a very similar problem with another program (OxygenXML). This was related to Jide. Jide was using a non-standard interface which happens to be available in Oracle Java but is not in the official interface description (which is implemented by OpenJDK).

When I saw Jide mentioned in the trace, I guessed that this is the same problem.

Embedded Java is not used by browser plugins. But it is still available on the system. I do not want programs with known security problems on my system and I do not want redundant programs and libraries on my system. This is what linux packaging guidelines are all about. So I very much prefer to have everything running with OpenJDK.

---

Thank you very much for the version information.

Your statements are a bit like saying "To protect my property from thieves, I'd rather have a new, open, and unlockable door than an old, closed, and locked door."  Personally, I prefer the locked door.
OpenJDK's browser plugin still has known security problems which are exploitable. I am afraid your system is much more vulnerable by using a default OpenJDK installation than it ever would be by using an embedded runtime. But of course, it is your system and your decision.

---

Dangerous statement (just saw it because I'm facing the same issue):
>> I'd rather have a new, open, and unlockable door than an old, closed, and locked door."  
>>Personally, I prefer the locked door.
1) unlockable is wrong. OpenJDK is stricter on implementing security standards (set by Oracle!) than Oracle itself. The new settings 'ask about anything not signed' - why yes, OpenJDK has been doing it ...
2) locked door. Yes, with closed source you see a locked door, but can't really check if the hinges are all in prime condition and thus cannot be used to break it open
3) locked door. Yes. But you also don't know who the hell has extra keys for *that* locked door.

---

Sorry, but you did not understand what I was saying at all. The "open door" is  the browser plugin that is installed (in your browser) by default. It is not a matter of Oracle Java vs OpenJDK (or closed source vs open source) but a matter of default (global) installation (no matter which distribution) vs embedded JRE. With an embedded JRE, the browser plugin is not installed (in your browser) and thus it is not possible to leverage its security problems to break into your system. (It just happened that in OP's case, the default installation is an OpenJDK installation.)

---

Did you make any progress with this?

I'm now pretty sure that this issue is indeed related to some components from Jide.

So please do me a favor and release a proper yed with an updated Jide version. I'm pretty sure that this will fix this issue.

---

I have edited your comment because what you did is a violation of the yEd Software License Agreement. Please don't do that.

That said, we are planning to upgrade to JIDE 3.5.6 with the next yEd release. However, we have not yet decided on a release date for the next version.

---

JIDE updated to version 3.5.6 as of yEd 3.11.1.

Answer 2

So I am facing the same issue,

and used the linux-alternatives system to point javaws to my Oracle-Java Installation.

Thus I downloaded the yed.jnlp (from todays version), and ran a

javaws yed.jnlp

Java-Oracle starts up (build 1.7.0_25-b15), the 'Starting applications...' dialog/window popps up, Oracle is asking me if I am sure I want to run this software (I do *not* set the 'do not show this again' field), I choose "run"

And the Webstart terminates.

No error-Messages, no error-output on the commandline from where I started the javaws, nothing.

 

Next I decided, maybe a flaky jnlp. Is known to happen now and then.

So I got the yed-experts-version since I really don't need another jre on my system(s) -

java -version tells me:

[me@mybox yed-3.11]$ java -version
java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)

BUT if I run 'java -jar yed.jar' or similar (see below) it just exits, once more, without any message anywhere. It does not complain about missing dependencies, or other stuff, just exits. Near Instantly. Below is the timed- output of a call including all jars and stuff.

[me@mybox yed-3.11]$ date && time java -cp .:vectorgraphics.jar:yed.jar -jar yed.jar && date
Wed Jul  3 11:15:46 CEST 2013

real    0m0.356s
user    0m0.503s
sys    0m0.018s
Wed Jul  3 11:15:46 CEST 2013
[me@mybox yed-3.11]$

Any ideas anyone?

Comments

Have you had yEd running successfully on your machine before or is this the first time you try yEd? In the latter case, what desktop environment/window manager are you using? Java works quite reliably on Gnome and KDE, but seems to have problems on many of the less wide-spread ones.

Moreover, when you were trying to start yEd from command line, did you make sure that the webstart yEd process was no longer alive? On startup, yEd checks if there is already another yEd process and if that is the case, it does not start. If you are not completely sure whether the webstart process is/was still alive or not, I suggest rebooting your machine and trying the command line approach once again.

Finally, java -cp .:vectorgraphics.jar:yed.jar -jar yed.jar is not a correct way to start a java application. When using the -jar option you cannot use -cp. Always start yEd with java -jar /path/to/yed.jar.

---

I have tried to launch yEd on systems where it did run before - thought it might have been a previous version of Fedora.

We are using GNOME here (gnome 3.4);

Concerning the other possibility of a webstart still running:
That was the issue - two webstarts were silently running in the background,
after terminating those,
yEd did just run....