Use external jnilib files if present

[GoogleCodeExporter]

I'd like to make a tweak so the code loads a local jnilib/dll/so library if the 
file is already expanded outside of the jar. This would allow the distribution 
of the native libs outside of the jar itself, reducing the jar size. I'd 
basically like to make the top of the extractResource method in RES.java read 
as follows:

    /** from class path into file system */
    public static void extractResource(final String sourcePath,
            final String targetPath) throws Exception {

        final File targetFile = new File(targetPath);
        log.debug("targetFile={} ", targetFile.getAbsolutePath());

        if (targetFile.isFile()) {
            log.debug("Found target file");
            return;
        }

What do you think Andrei? Any objections?

Original issue reported on code.google.com by adamf...@gmail.com on 16 Feb 2011 at 12:25

[GoogleCodeExporter]

Original comment by adamf...@gmail.com on 16 Feb 2011 at 12:25

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

1) no objections;

2) please add unit test along with the change;

3) dll loader is a pain and will need be re-written after nar plugin gets a 
release;
this might affect your changes again;

4) dll inside jar takes less space, especially if we start using pack200;
may be no need to change this?

5) also, if you app gets to users via jnlp delivery 
you can specify jnlp platform-native resorces jar; this will reduce download 
size;

Original comment by Andrei.Pozolotin on 16 Feb 2011 at 5:44

[GoogleCodeExporter]

error with your extract logic - the dll will not get updated
when extracting from the new version of the jar

Original comment by Andrei.Pozolotin on 16 Feb 2011 at 5:58

[GoogleCodeExporter]

more simple solution: 
1) do not change current code;
2) deliver only jar w/o dll;
3) place dll in proper folder/file on the runtime class path;

Original comment by Andrei.Pozolotin on 16 Feb 2011 at 6:48

[GoogleCodeExporter]

Apologies for the delay, Andrei. I have a few thoughts. I like the idea of not 
making a code change in theory, but I don't think that's possible without some 
ugly hacking with custom classloaders and such. Just adding the path 
./lib/bin/x86_64-MacOSX-gpp/libbarchart-udt4-1.0.3-SNAPSHOT.jnilib won't do it, 
and neither will adding 
/lib/bin/x86_64-MacOSX-gpp/libbarchart-udt4-1.0.3-SNAPSHOT.jnilib, for example.

Is there some trick I'm missing to do that? 

I like the jnlp angle and the easier delivery of including them in the larger 
jar bundle, but 1MB or up is really big in my opinion.

Assuming there's not a really nice trick I'm missing, I propose the following 
code snippet for the end of LibraryUDT loadCore() -- basically just load the 
raw file if it's there and we haven't found the library in the jar in any of 
the above attempts:

So:

       throw new Exception("core library load failed");

becomes:

    try {
        final String loadPath = (new File(targetPath)).getAbsolutePath();
        System.load(loadPath);
        return;
    } catch (Exception e) {
            log.warn("\n\t {} {}", e.getClass().getSimpleName(), e.getMessage());
        }

        throw new Exception("core library load failed");

What do you think? 

Oh also, I don't think the dll inside the jar will be any smaller with pack200. 
Pack200 is super specialized for compressing *class files* -- it shouldn't have 
any effect on other file types, or certainly no better than lzma or whatever 
else to my knowledge.

Original comment by adamf...@gmail.com on 27 Feb 2011 at 11:31

[GoogleCodeExporter]

the "trick" is that current loader loads resource both from jar and file 
system, as long as file system resource is on the class path; let me take 
another look;

Original comment by Andrei.Pozolotin on 2 Mar 2011 at 10:19

[GoogleCodeExporter]

I decoupled library loader from socket; please make your own loader; when we 
are happy with it, we can use it as default;

see:

LibraryLoaderUDT

LibraryLoaderDefaultUDT

TestLibraryUDT
    @Test
    public void testLoadWithProps() throws Exception {

        ResourceUDT.setLibraryLoaderClassName(LibraryLoaderDefaultUDT.class.getName());

        ResourceUDT.setLibraryExtractLocation("./target/test-testLoadWithProps-" + HelperUtils.getRandomString());

        SocketUDT socket = new SocketUDT(TypeUDT.DATAGRAM);

        assertTrue(socket.isOpen());

    }

Original comment by Andrei.Pozolotin on 2 Mar 2011 at 11:09

[GoogleCodeExporter]

re: "jar size" - I car remove *.map files from build

Original comment by Andrei.Pozolotin on 2 Mar 2011 at 11:32

[GoogleCodeExporter]

re: "jar size" - I can remove *.map files from build

Original comment by Andrei.Pozolotin on 2 Mar 2011 at 11:33