a photo uploader for Linux, Mac and Windows

New version

I released jUploadr 1.1.2 tonight, it’s almost identical to 1.1.2beta1, except with a small tweak for mac users. If you have 1.1.2beta1, I’d say stick with it unless you *have* to have the latest.

I’ve been working on 1.2 a lot recently, and I have to say, it’s looking very swell indeed. Once I get geo support in there, I’ll put it out for beta.

17 Responses to “New version”

  1. Gandhi Says:

    The sourceforge link for the windows version is not working!
    Thanks for everything

  2. mcC Says:

    Once downloaded, cannot get the OSX version to open.
    Screenshots look great — can’t wait to get it working.

  3. daniel seyb Says:

    Hi.

    When I try to install jUploadr, it fails, with:

    C:\Documents and Settings\the Seyb Family comp\Desktop\My Downloads\Flickr uploa
    ds\jUploadr-1.1.1-win32_x86> jUploadr.bat
    ‘REG’ is not recognized as an internal or external command,
    operable program or batch file.
    == was unexpected at this time.
    C:\Documents and Settings\the Seyb Family comp\Desktop\My Downloads\Flickr uploa

    I am using Windows 2000, current on all patches so far as I know. The problem shows up quick enough I doubt any other tool gets involved.

    I just thought you might want to know about this.

    dan

  4. daniel seyb Says:

    To quote Emily Litella (Gilda Radner) “Never Mind”. I somehow managed not to see the FAQ up in the header.

    dan

  5. Zeno Davatz Says:

    Sorry but V-1.1.2 does not work for me on my Mac PPC 10.4.8. The software does not start but crashes instantly.

    Thank you for your Feedback.

  6. scohen Says:

    Hmmm… Do the past versions work?
    I downloaded the DMG and it works for me. I even re-tried it when I got the first comment.

    Can you do the following:
    open terminal (Applications=>utilities=>Terminal)

    type: cd /Applications/JUploadr.app/Contents/MacOS
    type: ./JavaApplicationStub

    post the error that ensues.

  7. Curtis Says:

    I also can not get it to run on my PowerBook.

    I get the following error:
    [JavaAppLauncher Error] CallStaticVoidMethod() threw an exception
    Exception in thread “main” java.lang.UnsupportedClassVersionError: org/scohen/juploadr/app/JUploadr (Unsupported major.minor version 49.0)
    at java.lang.ClassLoader.defineClass0(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:539)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
    at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:219)
    at apple.launcher.LaunchRunner.loadMainMethod(LaunchRunner.java:55)
    at apple.launcher.LaunchRunner.run(LaunchRunner.java:84)
    at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50)
    at apple.launcher.JavaApplicationLauncher.launch(JavaApplicationLauncher.java:52)

    I’m on Mac OS X 10.3.9.

    -=Curtis=-

  8. Curtis Says:

    >Hmmm… Do the past versions work?

    1.1.1 DOES indeed work.

    -=Curtis=-

  9. scohen Says:

    Thanks curtis, that gives me the error that I need.
    Looks like I compiled 1.1.2 with java 1.5. I’ll re-compile with 1.4 and re-release, but you do know that this will be the last version on 1.4.

  10. Zeno Davatz Says:

    Yeahh, 1.1.1 worked for me as well. I will try to give you my output tonight. Thank your for your great software.

  11. Gunnar Grimnes Says:

    It still crashes randomly, taking all my tagging/titling work with it for no reason. Not sure exactly what caused it this time, but the last version was just the same. Could you not have a top-level try-catch that tries to save the current state to recover on startup?

  12. ViStA user Says:

    Any chance there will be an update for Vista users? :)

  13. scohen Says:

    Does jUploadr not work in Vista? What version of Java are you using?

  14. Grodesh Says:

    I thought you’d like to know this:

    I’m not able to get 1.1.2 to work on Vista 64-bit, but I managed to get 1.1.1 to work, due to the fact that it’s easier to edit a batch file. :)

    I installed the 32-bit version of the Java 1.6 JRE and changed the 2 registry paths in the batch file from:

    HKLM\SOFTWARE\JavaSoft\Java Runtime Environment

    to

    HKLM\SOFTWARE\Wow6432Node\JavaSoft\Java Runtime Environment

    I suppose this is also good to get 1.1.1 to work on Vista 32-bit, and could be the solution to get 1.1.2 to work, but it’s harder for the end user since 1.1.2 now uses an executable file.

    I have tried with the 64-bit JRE and it makes an exception when trying to load the swt-win32-3232.dll file: “Can’t load IA 32-bit .dll on a AMD 64-bit platform”.

    Now I’ll have to go check whether or not the program behaves normally… :)

  15. Grodesh Says:

    Oh and I tried adding the registry keys to the path jUploadr is expecting, and it works for 1.1.2 on Vista.

    I guess it’s a good workaround until the next update of jUploadr.

    Thanks for the great program!

    (ok now I have to go check if everything is behaving like it should do :) )

  16. James Says:

    Should the downloaded release still support java 1.4? I’m getting a similar error to Curtis above:

    Starting JUploadr…
    Java exec found in PATH. Verifying…
    Suitable java version found [java = 1.4.2-02]
    Configuring environment…
    Exception in thread “main” java.lang.UnsupportedClassVersionError: org/scohen/juploadr/app/JUploadr (Unsupported major.minor version 49.0)
    at java.lang.ClassLoader.defineClass0(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:539)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
    at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)

    Using Ubuntu Edgy Eft with java from the OS’s package repository. 1.1.1 still works a treat, luckily I just used softlinks to switch to the new version, so falling back was very simple.

  17. Leon Says:

    Hey there, I’m trying to install jUploadr on Ubuntu 8.04 Hardy Heron AMD-64. I’ve done some forum digging and found out how to install Sun’s 64-bit JRE and think I’ve succeeded in doing this, as evidenced by:
    leon@buntubeast:~/Downloads/jUploadr-1.1.2-linuxGTK-i386$ java -version
    java version “1.6.0_06″
    Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
    Java HotSpot(TM) 64-Bit Server VM (build 10.0-b22, mixed mode)

    But then when I try to setup/run jUploadr (by entering ./jUploadr while in its directory) I get the following:

    Starting JUploadr…
    Java exec found in PATH. Verifying…
    Suitable java version found [java = 1.6.0_06]
    Configuring environment…
    2/07/2008 23:51:35 java.util.prefs.FileSystemPreferences$2 run
    INFO: Created user preferences directory.
    Exception in thread “main” java.lang.UnsatisfiedLinkError: /home/leon/Downloads/jUploadr-1.1.2-linuxGTK-i386/lib/libswt-pi-gtk-3232.so: /home/leon/Downloads/jUploadr-1.1.2-linuxGTK-i386/lib/libswt-pi-gtk-3232.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)
    at java.lang.Runtime.loadLibrary0(Runtime.java:823)
    at java.lang.System.loadLibrary(System.java:1030)
    at org.eclipse.swt.internal.Library.loadLibrary(Library.java:123)
    at org.eclipse.swt.internal.gtk.OS.(OS.java:22)
    at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:63)
    at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:54)
    at org.eclipse.swt.dnd.Transfer.registerType(Transfer.java:135)
    at org.eclipse.swt.dnd.TextTransfer.(TextTransfer.java:36)
    at org.scohen.juploadr.app.JUploadr.(JUploadr.java:84)
    at org.scohen.juploadr.app.JUploadr.main(JUploadr.java:709)

    “Architecture word mismatch” sounds like I’m trying to use a 32-bit program in a 64-bit environment in this case. Which apparently doesn’t work (I wasn’t certain of this!).

    In which case, should I try to install 32-bit JRE on my 64 bit system and then use jUploadr? Or will 32-bit JRE not work on a 64-bit version of Ubuntu.

    I believe that I should be able to install a 32-bit Ubuntu on my AMD-64 system without issues other than slowerness in some instances and a waste of potential. Is this true?

    Is there any hope of AMD-64 support in jUploadr - or is it there already and I’m too thick to find it and make it work?!

    Cheers.

Leave a Reply