Bug 172 - Automatically load the .lib/.so files rather than count on -Djava.library.path
Summary: Automatically load the .lib/.so files rather than count on -Djava.library.path
Alias: None
Product: Jogl
Classification: JogAmp
Component: core (show other bugs)
Version: 1
Hardware: All all
: P3 normal
Assignee: Sven Gothel
Depends on:
Reported: 2005-08-02 10:28 CEST by Sven Gothel
Modified: 2015-09-27 03:14 CEST (History)
0 users

See Also:
SCM Refs:
Workaround: ---

Proposed implementation of the enhancement (3.33 KB, text/plain)
2005-08-02 10:28 CEST, Sven Gothel

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Gothel 2010-03-24 07:47:59 CET

---- Reported by jaeden 2005-08-02 10:28:11 ----

It would be appreciated if you provided a method for auto-loading the lib files
for the native bindings to JOGL. To ease this method, I would recommend renaming
the Solaris libs so that each version has a different file name, allowing them
to be in the same directory. Then, use code similar to this to load the libs in
a static block somewhere. You could optimally make this one function that the
user must call to load them, so as not to load them twice in web start applications.

Here's the code I'm using, that seems to be working:

/** Static initialization  - load libraries */
      /** Ensure we load GL on startup. This is a replacement for the
command-line switches
     *  -Djava.library.path=. and -cp .;jogl.jar. 
    public static void loadOpenGL()
        // workaround to allow our loader to do its job
        // see;topicseen
        // Manually load AWT to work around the problem with error boxes coming 
        // up claiming it's not found. 
        // Apparently AWT has to be loaded -before- jogl's .dll files or all 
        // sorts of errors pop up.
        // Now, load the .dll/.so files for the OpenGL C bindings 
        String strOS = Tools.GetOS(); // wraps System.getProprty("os.name");

        // Absolute path to the lib directory
        String strJOGL = Tools.Path("lib") + Tools.GetFileSeparator();         
        // bLoadCg provided for those who aren't using Cg and don't want the 
        // libs for it loaded

        if (strOS.startsWith("Windows"))
            System.load(strJOGL + "jogl.dll");            
            if (bLoadCg)
                System.load(strJOGL + "jogl_cg.dll");                
        if (strOS.startsWith("Mac OS"))
              System.load(strJOGL + "libjogl.jnlib");
              if (bLoadCg)
                System.load(strJOGL + "libjogl_cg.jnlib");        
        if (strOS.startsWith("Linux"))
                System.load(strJOGL + "libjogl.so");
                if (bLoadCg)
                    System.load(strJOGL + "libjogl_cg.so");
        if (strOS.startsWith("Solaris"))
               String strArch = System.getProperty("os.arch");
               if (strArch.equalsIgnoreCase("sparc"))
                   System.load(strJOGL + "libjogl_solsparc.so");
               if (strArch.equalsIgnoreCase("x86"))
                   System.load(strJOGL + "libjogl_solx86.so");

---- Additional Comments From jaeden 2005-08-02 10:28:54 ----

Created an attachment
Proposed implementation of the enhancement

---- Additional Comments From kbr 2006-01-11 00:58:07 ----

JOGL currently offers two deployment strategies neither of which involves any
manual installation of files on the end user's machine. First, JOGL is available
as a Java Web Start extension, which is how all of the jogl-demos are deployed.
Second, with the new JOGLAppletLauncher it is possible to deploy unsigned Java
applets which use JOGL with no manual installation of any files.

I believe these two deployment mechanisms, in conjunction with new support in
Java Web Start in JDK 5 like the Import Facility (see
should be sufficient to cover most deployments of JOGL applications. I do not
think it is a good idea to standardize some directory structure in the JOGL
internals where if a certain API is called with the root of the directory
structure then the code searches through it for the appropriate native library
to load. This is exactly what Java Web Start is designed to abstract away.

I apologize but I'm closing this bug as "will not fix". Please investigate Java
Web Start more thoroughly; I think you will find it surprisingly flexible for
distributing applications.

--- Bug imported by sgothel@jausoft.com 2010-03-24 07:47 EDT  ---

This bug was previously known as _bug_ 172 at https://jogl.dev.java.net/bugs/show_bug.cgi?id=172
Imported an attachment (id=61)

The original submitter of attachment 61 [details] is unknown.
   Reassigning to the person who moved it here: sgothel@jausoft.com.