Note that there are some explanatory texts on larger screens.

plurals
  1. POJava "implibs" aka jars devoid of actual code, containing only method definitions with empty bodies?
    text
    copied!<p>Windows has concept of "import libraries" aka "implibs" - when you want to link you code against dynamic library, you don't link it against .dll itself, but rather against special static library which contains thunks to call out to .dll. Well, that's definitely Windows idiosyncrasy, but at times, the idea is not that bad.</p> <p>Consider for example that you have complex system consisting of 100 dynamic libs, each averaging 2MB, and then 10 versions of this system. So, SDK you'd ship to provide complete support of such system across all versions would be 2GB only of libs to link against. With implibs, which contain only symbols and small thunks, it would be much less.</p> <p>Concept of implibs can be pretty easily applied to normal Unixish shared libs - you just dump symbols, make simple thunks in C from them, compile, and voila, you can link against that lib instead of the original.</p> <p>Now, I'd like to extend the same idea to Java. So, ideally I'd be looking for a tool which would take jar, then rewrite bytecode classes inside it to remove bodies of methods, leaving only method definitions with empty (as much as possible) bodies. If such tool doesn't exist, I'd be looking for pointers to Java bytecode transformation framework which would make writing such tool easy. Failing that, I'd be at least looking for a tool which can dump all method signatures from a jar, to follow similar approach as for native shared libraries (granted, it would be more complicated, as I couldn't just add empty Java body to it, but rather would need to return value of valid type).</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload