Cyberduck Mountain Duck CLI

#5586 closed defect (worksforme)

Run on unsupported Java installations

Reported by: https://www.google.com/accounts/o8/id?id=aitoawmzjwsjlt1dqmrmsn6ss6yutv2n5wdixhw Owned by:
Priority: low Milestone: 4.0
Component: core Version: 3.8.1
Severity: normal Keywords: launch
Cc: Architecture: Intel
Platform: Mac OS X 10.6

Description (last modified by dkocher)

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

Change History (24)

comment:1 Changed on Dec 21, 2010 at 7:32:04 PM by dkocher

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

comment:2 Changed on Dec 22, 2010 at 12:18:30 PM by dkocher

  • Resolution set to worksforme
  • Status changed from new to closed

comment:3 Changed on Dec 22, 2010 at 3:31:08 PM by https://www.google.com/accounts/o8/id?id=aitoawmzjwsjlt1dqmrmsn6ss6yutv2n5wdixhw

[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
Last edited on Dec 22, 2010 at 3:42:21 PM by dkocher (previous) (diff)

comment:4 Changed on Dec 22, 2010 at 3:44:57 PM by dkocher

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.

comment:5 follow-up: Changed on Dec 23, 2010 at 12:48:37 AM by jnd

  • Resolution worksforme deleted
  • Status changed from closed to reopened

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.

Last edited on Dec 23, 2010 at 9:30:18 AM by dkocher (previous) (diff)

comment:6 Changed on Dec 23, 2010 at 9:37:47 AM by dkocher

  • Description modified (diff)
  • Summary changed from Won't launch in Mac 10.6.5 with v 3.8.1 to UnsupportedClassVersionError

comment:7 in reply to: ↑ 5 Changed on Dec 23, 2010 at 9:42:28 AM by dkocher

Replying to jnd:

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

comment:8 follow-up: Changed on Dec 23, 2010 at 10:44:57 AM by 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:

  • 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?

Last edited on Dec 23, 2010 at 1:40:38 PM by dkocher (previous) (diff)

comment:9 in reply to: ↑ 8 Changed on Dec 23, 2010 at 11:55:35 AM by dkocher

Replying to 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.

comment:10 Changed on Dec 23, 2010 at 12:48:19 PM by jnd

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!

comment:11 Changed on Dec 23, 2010 at 1:01:56 PM by dkocher

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

comment:12 Changed on Dec 23, 2010 at 1:16:01 PM by dkocher

The same issue was first reported in #5433.

comment:13 Changed on Dec 23, 2010 at 1:17:22 PM by dkocher

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

comment:14 follow-up: Changed on Dec 23, 2010 at 1:23:06 PM by jnd

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.

Last edited on Dec 23, 2010 at 1:42:37 PM by dkocher (previous) (diff)

comment:15 in reply to: ↑ 14 Changed on Dec 23, 2010 at 1:46:33 PM by dkocher

Replying to 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.

comment:16 Changed on Dec 23, 2010 at 1:50:21 PM by dkocher

  • Summary changed from UnsupportedClassVersionError to Run on unsupported Java installations

comment:17 follow-up: Changed on Dec 23, 2010 at 2:01:06 PM by 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

comment:18 in reply to: ↑ 17 ; follow-up: Changed on Dec 23, 2010 at 2:34:40 PM by dkocher

Replying to 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.

comment:19 in reply to: ↑ 18 Changed on Dec 23, 2010 at 2:36:28 PM by dkocher

Replying to dkocher:

Replying to 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.

comment:20 Changed on Dec 23, 2010 at 5:48:20 PM by dkocher

As of r8153 no Rendezvous classes are loaded if disabled.

comment:21 Changed on Dec 27, 2010 at 12:47:22 PM by dkocher

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

comment:22 Changed on Dec 28, 2010 at 9:07:36 AM by dkocher

  • Priority changed from high to low

comment:23 Changed on Dec 28, 2010 at 4:24:43 PM by dkocher

  • Milestone set to 4.0
  • Resolution set to worksforme
  • Status changed from reopened to closed

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

comment:24 Changed on Jan 31, 2011 at 2:11:27 PM by dkocher

Should work with Bonjour enabled as of r8257.

Note: See TracTickets for help on using tickets.
swiss made software