Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Run on unsupported Java installations #5586

Closed
cyberduck opened this issue Dec 21, 2010 · 20 comments
Closed

Run on unsupported Java installations #5586

cyberduck opened this issue Dec 21, 2010 · 20 comments

Comments

@cyberduck
Copy link
Collaborator

@cyberduck cyberduck commented Dec 21, 2010

3b93b53 created the issue

I've tried the latest nightly build as well. I reverted to Version 3.3b1 (5185) where the ( similar ) problem was original fixed and it works.

Platform:
  Model Identifier:	MacBookPro5,2
  Processor Name:	Intel Core 2 Duo
  Processor Speed:	2.8 GHz
  L2 Cache:	6 MB
  Memory:	4 GB
System Version:	Mac OS X 10.6.5 (10H574)
Kernel Version:	Darwin 10.5.0
@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 21, 2010

@dkocher commented

What is the crash report and output in the system.log from Applications/Utilities/Console.app.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 22, 2010

3b93b53 commented

[LaunchRunner Error] ch.cyberduck.ui.cocoa.MainApplication.main(String[]) threw an exception:
Dec 22 09:28:05  .ch.sudo.cyberduck[24020]: java.lang.UnsupportedClassVersionError: Bad version number in .class file

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 22, 2010

@dkocher commented

Do you have any custom Java installation or configuration you are aware of? We should run just fine on either Java 5 or 6 that is installed by default from the OS X software update.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 23, 2010

078c58f commented

Hi, I've had the same problem and been able to work around it. I have Mac OS X 10.6.5 (build 10H574) with both Java 1.6.0_22-b04-307-10M3261 and 1.5.0_24-b02-357-10M3261. Java 6 (64-bit and 32-bit) is highest as my preferred VM for applications. However, I get the crash on java.lang.UnsupportedClassVersionError. I modified Cyberduck.app/Contents/Info.plist such that the JVMVersion is set to "1.6+" instead of "1.5+", and it works.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 23, 2010

@dkocher commented

Replying to [comment:5 jnd]:

This is strange and I cannot explain. From where do you have a the Java 5 build for 10.6?

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 23, 2010

078c58f commented

Hi David, there seem to be two or three issues beneath the surface. Either way, I think it's a bug with Apple's Java Application Launcher. FYI, my JVM preferences were:

  • Java 6 x86_64
  • Java 5 x86_64
  • Java 5 i386
  • Java 4 i386

All of them are Apple-supplied JVMs & JDKs. All of them work with Snow Leopard. (Although by default Apple, moves the pre-6 JVMs into a "disabled" folder or equivalent. I moved them out of the "disabled" folder because it was the easiest way to support legacy corporate software.)

Firstly, I tried to find out what JVM my Mac was using to open Cyberduck. It was using Java 5. (I confirmed this by renaming my Java 5 runtime...and Cyberduck failed to launch because of "file not found". Then I restored my Java 5, and Cyberduck was once again affected by "UnsupportedClassVersionError".)

Secondly, I noticed that I was missing the 32-bit version of Java 6 (i386). I manually inserted it into my Host-specific preferences. That is, I edited "~/Library/Preferences/ByHost/com.apple.java.JavaPreferences.*.plist".

After editing my plist file, Cyberduck successfully launches with the Java 6 runtime. So my problem is solved.

This leaves two puzzles: why didn't Cyberduck originally launch with the 64-bit Java 6? and why was Java 5 not able to run the program? I can't solve either of these, but perhaps the original bug reporter should try editing his or her plist file?

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 23, 2010

@dkocher commented

Replying to [comment:8 jnd]:

Hi David, there seem to be two or three issues beneath the surface. Either way, I think it's a bug with Apple's Java Application Launcher. FYI, my JVM preferences were:

The combination of this list and the default setting 1.5+ for JVMVersion in Info.plist should select Java 6. Looks like a bug in the application launcher, yes.

Secondly, I noticed that I was missing the 32-bit version of Java 6 (i386). I manually inserted it into my Host-specific preferences. That is, I edited "~/Library/Preferences/ByHost/com.apple.java.JavaPreferences.*.plist".

Does it launch with JVMVersion set to 1.5+?. We do have a runtime architecture preference in the Info.plist for i386 before x86_64 which could have a bad influence here.

Nevertheless, it should work with either Java 5 x86_64 or Java 5 i386, too. The error message indicates that we have a class that is compiled for Java 6 only but I don't think that is the case as I run it successfully on a Java 5 VM/PPC and there would be many more bug reports.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 23, 2010

078c58f commented

Status of Cyberduck on my Intel Core 2 Duo Mac OS X 10.6.5 (build 10H574) with Java 1.6 and 1.5 both installed:

  • Won't launch with 1.6.0_22-b04-307 x86_64: Application Launcher skips over the 64-bit architecture.
  • Won't launch with 1.5.0_24 x86_64: Application Launcher skips over the 64-bit architecture.
  • Won't launch with 1.5.0_24 i386: java.lang.UnsupportedClassVersionError: Bad version number in .class file
  • Launches with 1.6.0_22-b04-307 i386: success.

Therefore, Cyberduck users must have Java 6 32-bit at a higher priority than Java 5 32-bit.

Early on, I changed LSArchitecturePriority to put x86_64 highest. But it didn't fix the problem because the Application Launcher skips past all 64-bit Java versions when launching Cyberduck.

At the moment, I've reverted to stock-standard Cyberduck 3.8.1 and it's working fine as long as Java 6 i386 has a higher priority than Java 5 in com.apple.java.JavaPreferences.*.plist

Maybe there's some architecture problem in the native loader, causing both the skipping of 64-bit and the UnsupportedClassVersionError? Some of Cyberduck's bundled Java libraries have class versions as low as 45.3. Maybe there is some dependency that is incompatible with the 64-bit runtime? But that still wouldn't explain the UnsupportedClassVersionError! Could it be an issue with Cyberduck's bundled Application Stub Cyberduck.app/Contents/MacOS/Cyberduck??

I run it successfully on a Java 5 VM/PPC

Interesting. I also checked the .class versions during my initial investigation, and there's nothing higher than 49.0 (Java 1.5). I remain mystified about the root cause of the UnsupportedClassVersionError!

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 23, 2010

@dkocher commented

One could check if it makes any difference when launching from the Terminal with arch -arch x86_64 Cyberduck.app/Contents/MacOS/Cyberduck.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 23, 2010

@dkocher commented

The same issue was first reported in #5433.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 23, 2010

@dkocher commented

Please also check that you don't have any jar libraries in /Library/Java/Extensions/ that might be compiled for Java 6.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 23, 2010

078c58f commented

Hi David, thanks for your prompt replies! I tried it using arch, and end up with the same UnsupportedClassVersionError. I also just discovered this ticket is nearly a duplicate of #5433! I removed all contents of /Library/Java/Extensions and it didn't solve the problem.

I did an experiment: I transplanted another Java product (1.5 compatible) into the Cyberduck bundle, and it executed flawlessly. So the UnsupportedClassVersionError is definitely triggered by Cyberduck code.

Forgive me for not having done this sooner, but I looked more closely at the middle of the stacktrace and realised the failure occurs within your MainApplication.java.

On line 88 of ch.cyberduck.ui.cocoa.MainApplication.main you call Rendezvous.register() which triggers the loading of a class that fails with UnsupportedClassVersionError. Do you think this is due to something you've bundled, or is it likely that our Java 5 installations are trying to load something from Java 6? I will investigate further but I'm not familiar with Bonjour implementations.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 23, 2010

@dkocher commented

Replying to [comment:14 jnd]:

On line 88 of ch.cyberduck.ui.cocoa.MainApplication.main you call Rendezvous.register() which triggers the loading of a class that fails with UnsupportedClassVersionError. Do you think this is due to something you've bundled, or is it likely that our Java 5 installations are trying to load something from Java 6? I will investigate further but I'm not familiar with Bonjour implementations.

That explains it. We ship a Rendezvous implementation compiled with Java 5 compatibility in dns_sd.jar inside the application bundle. However, the same classes are available by default in the Java installation by Apple and take precedence when loading the classes as they reside in /System/Library/Java/Extensions/dns_sd.jar.

Because Java 5 is not officially supported on your system (Mac OS X 10.6), this archive is compiled against Java 6 which comes bundled. You can either remove this archive (don't know of other side effects, though) or disable Bonjour support in Cyberduck.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 23, 2010

078c58f commented

Thanks David, that clarifies the situation. However neither of the Bonjour workarounds was effective for me. So for the time being, it's necessary for me to make sure that the 32-bit supported Java version ranks higher than the 32-bit unsupported version. But if you could catch the Exception within MainApplication.java and convert into something that end-users could understand, it would be marvelous. Otherwise a bit of a wild goose chase for everyone!

Well done - J

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 23, 2010

@dkocher commented

Replying to [comment:17 jnd]:

Thanks David, that clarifies the situation. However neither of the Bonjour workarounds was effective for me. So for the time being, it's necessary for me to make sure that the 32-bit supported Java version ranks higher than the 32-bit unsupported version. But if you could catch the Exception within MainApplication.java and convert into something that end-users could understand, it would be marvelous. Otherwise a bit of a wild goose chase for everyone!

Well done - J

I see, Rendezvous classes are loaded regardless of the property rendezvous.enable being set. I am puzzled, that removing the dns_sd.jar from the system classpath doesn't help.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 23, 2010

@dkocher commented

Replying to [comment:18 dkocher]:

Replying to [comment:17 jnd]:

But if you could catch the Exception within MainApplication.java and convert into something that end-users could understand, it would be marvelous. Otherwise a bit of a wild goose chase for everyone!

One cannot catch these errors as these are not exceptions. We would have to repackage the com.apple.*classes to make sure our versions in the application bundle is loaded.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 23, 2010

@dkocher commented

As of 3ab04f5 no Rendezvous classes are loaded if disabled.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 27, 2010

@dkocher commented

Do you have a Java 5 installation that is packaged in the new .jdk bundle format?

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 28, 2010

@dkocher commented

In a6c11f6 we provide an empty Rendezvous implementation if disabled. Available in the latest snapshot build. You must disable Bonjour.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Jan 31, 2011

@dkocher commented

Should work with Bonjour enabled as of e76db1e.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant