Forum Stats

  • 3,759,067 Users
  • 2,251,495 Discussions



940956 Member Posts: 2
edited Mar 18, 2013 6:00AM in Java Programming
Hi All

I having a issue that I can't seem to get by. I'm getting the following exception.

java.lang.UnsatisfiedLinkError: javax/realtime/RealtimeThread.putAsyncHandlerClassToThread(Ljava/lang/Class;)V
at javax.realtime.RealtimeThread.<clint>(
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(
at java.lang.J9VMInternals.initialize(
.......... (etc)

Using java 1.5.

Does anyone have a general idea of what to check for when getting this error. I have checked my classpath and I have the realtime jar in it and also the location of the .so file that contains the putAsyncHandlerClassToThread that the error mentions. I'm using eclipse as my dev environment.

Any help on this would be great. I'm stumped.

Edited by: 937953 on Jun 1, 2012 2:19 PM


  • EJP
    EJP Member Posts: 32,920 Gold Crown
    The .so has to be on the PATH, or java.library.path, not the CLASSPATH.
  • gimbal2
    gimbal2 Member Posts: 11,949 Gold Trophy
    The easiest way that I know of to work with binary files is thus:

    1) dump binary files in the same directory as where you will be invoking Java (for example, in the same directory as the executable jar)
    2) make sure Java is executed in that exact directory (for example: executable jar, a jar wrapper executable or through a shell script).

    Then you don't need to fiddle with any configuration properties or have to put binaries in directories that are guaranteed to be on the path; it "just works".

    In the case of running from your development environment (Eclipse in this case), you should set a specific "working directory" where you can put your binaries. In the case of Eclipse it creates a "run configuration" for each class you run. You can see it by choosing "run as -> run configurations...". In there you can click on the "arguments" tab and at the bottom of that panel you can override the working directory for that specific executable class. By default it will be the root of the Eclipse project directory.
  • 940956
    940956 Member Posts: 2
    edited Jun 1, 2012 5:13PM
    So when I said classpath I actually meant LD_LIBRARY_PATH. Is this the same as the java.library.path you mentioned? My eclipse is own a redhat linux environment. I'm getting the error when I'm running a JUNIT test. I've also tried creating an LD_LIB... variable on my run configuration as well as adding it to the run configuration arguments with the -Djava.library.path. None of these options worked. Any other ideas on what the issue might be. I also tried a System.load with the .so file but that gave a different error message java.lang.nosuchmethod found.

    Edited by: 937953 on Jun 1, 2012 2:09 PM
  • EJP
    EJP Member Posts: 32,920 Gold Crown
    edited Jun 1, 2012 10:04PM
    LD_LIBRARY_PATH isn't the same thing as java.library.path, but it should do. However I agree 100% with gimbal2's advice. Don't futz around with PATH, java.library.path, LD_LIBRARY_PATH, and who knows what else: use the current directory. It never fails.

    @gimbal2: do you also gyre in the wabe? as well as gimbling?
  • PhHein
    PhHein Member, Moderator Posts: 7,167 Silver Trophy
    sunil wrote:

    Mod: I'm locking this zombie.
This discussion has been closed.