Recent Mac Java update renders 0.7 useless

  • Nobody/Anonymous

    PasswordSafe no longer launches after the recent Mac java update.

    • David

      David - 2009-06-24

      Hi all,

      I guess this ( forum thread is about the same topic.
      Over there is a description of a workaround, which has been tested to work (thanks corvi42 for the test).

      Besides that I plan to build a V0.8 beta2 Version within the next few days, where this workaround could be included.

      BUT I am not sure what happens to Mac users on older Mac OS X versions...


      • Daniel Rosenstark

        That solution is absolute bunk. You do not need to switch the JVM (though you could). Here's my solution

        • David

          David - 2009-09-01

          The solution you describe is exactly the same as in the other thread, namely to replace the swt jar with a 64 bit version (though with a newer swt version).
          In order to provide mac users of 32bit <b>and</b> 64bit jvms with a version of java passwordsafe, there is still a need for two build targets in our deployment process.

          • Daniel Rosenstark

            Okay, my bad. I thought he/she proposed using a different JVM. Thanks!

    • Nobody/Anonymous

      I have encountered the same problem, and can no longer use PasswordSafe. Is there any workaround available? Is there a plan to resolve this? Thanks!

    • Nobody/Anonymous

      yea! I was the original poster and I'd been using password gorilla to get at my password file for a few days. glad to have passwordsafe back!

  • Nobody/Anonymous

    Here's what i did to render pws 0.7.105 useable on Leopard 1.5.8 (i'm still
    evaluating PasswordSafeSWT !):

    The problem: SWT wants to run 32-bit code, Leopard defaults to launching pws
    in a 64-bit environment, but the two don't party. Luckily, leopard seems to
    have a 32-bit java envionment available but it is not the default.
    Fortunately, you can tweak to 'request' a 32-bit java
    machine - thereby enabling pws and your Mac to 'get it on'.

    What I did: Go to /Applications and find Right mouse on
    it and select 'Show Package Contents'. The .app is really a directory and not
    a file, and doing what I just said will enable you to look into the
    subdirectories of ''. Now you need to do a 1 line edit of
    Info.plist. Doubleclick on it to edit it (you are about to do the mac
    equivalent of editing a .ini file on windows --- remember when!). Expand the
    right-pointy arrow next to "Java" at the bottom of the plist. You
    will see an attribute called 'JVMVersion' with property set to
    "1.5+". Leave this as it is. Now right-mouse on JVMVersion and
    select 'Add row' from your pop-up menu, and Add a new attribute called
    'JVMArchs'. Set the Value column of your new row to "i386". Hit the
    usual red 'Close' button on this mac window - at which point you'll be asked
    to save your changes. Save them.

    What you have just done is inserted an 'advisory' directive in your startup
    file for this application which will attempt to run with a 32-bit java-
    virtual-machine instead of the default (incompatible) 64 bit machine.

    My observations whilst testing this workaround are below - I cannot tell
    whether this workaround has manifested these bugs, or whether these bugs are
    just ... bugs in the code, but first impressions are that the sanity of the
    underlying password file seems intact when I run against a version-2 data file
    (I'd already created the latter by using the macports command-line version,
    called 'pwsafe' and was pleasantly surprised that PasswordSafeSWT could work
    with this data file ). Anyways, my list of bugs would be:

    • Preferences: anything to do with re-entering the password to unlock the database, doesn't work. It could just be that the 're-enter database password' dialog box is screwed. The good news is that your master password will still work when you launch the app, so best advice is not to 'enable' any of the Security preferences that will re-lock the database eg after inactivity, minimization etc.
    • Dont 'omit' to assign a Group to any entry, leastways when using a verision-2 database file format. Nothing bad will happen, but it makes your GUI listing of passwords look cosmetically strange if you dont enter a Group assignation (ie the integrity of the password database is not affected).

    So, in summary, I seemed to get an awful lot of program running, just for the
    want of adding a single line to a config file ! Happy so far!

  • David

    David - 2009-10-14

    Hi nobody,

    thanks for your detailed description, I included this key in the new 0.8 beta
    2 release fro macs.

    I am bit suprised about the effects with passphrase entry you describe while
    testing, they might be due to using a v2 database.

    Can you reproduce them with a new passwordsafe created with PasswordSafe SWT
    (defaults to v3 database)?

    I believe v2 does not support group entries, but that behaviour is still
    wrong. Could you file this as a bug, please?

  • Nobody/Anonymous

    ERROR! The markdown supplied could not be parsed correctly. Did you forget to surround a code snippet with "~~~~"?

    I got a Mac OS X 10.5.8 (Intel) and tried to upgrade passwordsafe v 6.0 to 7
    or the 8 beta. Thanks to exchanging the swt.jar () I managed to finally start
    the programm. However, I could not open my existing password file. My correct
    password is considered invalid and both new versions cannot import the files I
    exported previous to the update (neither text nor xml). Help would be much
    : [](
  • Nobody/Anonymous

    Actually, it crashes completely. Even if I want to create a new password file.


  • David

    David - 2009-11-12

    Stephan, exchanging the swt.jar shouldn't be necessary anymore with
    PasswordSafeSWT-0.8-beta2a.dmg download.

    Can you confirm this?

  • Daniel Rosenstark

    On Snow Leopard 10.6.2 with latest JVM (1.6.0_17), which has a 64-bit hotspot

    Just tried


    error message is

    java.lang.UnsatisfiedLinkError: Cannot load 64-bit SWT libraries on 32-bit JVM

    Then I tried


    and the DMG is not mountable.

    .7, just like .8, does not work correctly if you sub in the 32-bit SWT. This
    is the error

    org.eclipse.swt.SWTException: Failed to execute runnable

    at org.eclipse.swt.SWT.error(Unknown Source)

    at org.eclipse.swt.SWT.error(Unknown Source)

    at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Unknown Source)

    at org.eclipse.swt.widgets.Display.runAsyncMessages(Unknown Source)

    at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)

    at org.eclipse.jface.window.Window.runEventLoop(



    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)


    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp

    at java.lang.reflect.Method.invoke(


    at apple.launcher.LaunchRunner.callMain(


    Caused by: java.lang.NullPointerException

    at org.eclipse.swt.widgets.Shell.sendToolTipEvent(Unknown Source)

    at org.eclipse.swt.widgets.Shell.windowSendEvent(Unknown Source)

    at org.eclipse.swt.widgets.Display.windowDelegateProc(Unknown Source)

    at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)

    at org.eclipse.swt.widgets.Display.applicationSendEvent(Unknown Source)

    at org.eclipse.swt.widgets.Display.applicationProc(Unknown Source)

    at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)

    at org.eclipse.swt.internal.cocoa.NSApplication.sendEvent(Unknown Source)

    at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)

    at Source)

    at org.pwsafe.passwordsafeswt.PasswordSafeJFace.displayOpeningDialog(PasswordS

    at org.pwsafe.passwordsafeswt.PasswordSafeJFace.access$0(PasswordSafeJFace.jav


    at Source)

    ... 13 more

    Please help as if I didn't have my Sourceforge password in Firefox, I would've
    had to post as anonymous :)


  • Nobody/Anonymous

    Try to download again PasswordSafeSWT-0.8-beta3-carbon.dmg.

    On my side it is mountable and that's the version I installed. It works with
    10.6.2 1.6.0_17

  • Daniel Rosenstark

    @nobody, thanks! Indeed


    works perfectly now. Great news! Long live Password Safe!



Cancel  Add attachments

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks