Open GoogleCodeExporter opened 9 years ago
Original comment by adamf...@gmail.com
on 16 Feb 2011 at 12:25
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
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
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
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
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
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
re: "jar size" - I car remove *.map files from build
Original comment by Andrei.Pozolotin
on 2 Mar 2011 at 11:32
re: "jar size" - I can remove *.map files from build
Original comment by Andrei.Pozolotin
on 2 Mar 2011 at 11:33
Original issue reported on code.google.com by
adamf...@gmail.com
on 16 Feb 2011 at 12:25