Have a look at cthrift. By comparison, its footprint is approximately 0. I have a thrift file with ~30 types and ~30 functions, and the total size of the client executable is about 92KB - and most of that is in the libraries. For comparison, a simpler client with 0 types and 2 functions has a 68KB executable [this is cygwin on vista]
Of course, this is all C code, so you're going to have to write a JNI wrapper to get access to the functions [and yes, automatically generating this is on my TODO list...] Mayan > if you recall, i'm working on a project called xthrift, which adds passing > objects by-reference on top of thrift. the project seemed very promising > up > until yesterday, when i realized thrift generates way to much code to make > it feasible. > > i made an test case of 6 classes, each with 6 methods and 6 attributes, > and > 6 service functions that expose those. i attached the thrift file that's > generated from my xthrift file -- it contains around 100 functions. > > generating java code using the thrift compiler yields a 2.2 MB java source > file! when compiled, it yields a 1.6MB jar! in csharp and python, the > situation is slightly better: ~700 KB. just for the sake of entropy, > compressing (bz2) the generated java code yields a 34 KB file (the a ratio > is 65! ) > > for our project, that contains ~100 classes, each with ~10 methods and ~5 > attributes, plus ~50 functions, the generated java code would weigh tens > if > not hundreds of MBs, which is unacceptable, of course. > > looking at the generated code, it's easy to spot the redundancy: thrift > employs a "full beta-reduction policy", i.e., it doesn't encapsulate > common > functionality into functions, instead it just repeats them over and over. > this yields ~80,000 lines of code that mostly repeat one another. > > judging from the code size, i understand thrift is not meant to handle > more > than ~50 functions per project, unless you are willing to accept tens of > MBs > of library footprint.[1] > is there any "compiler switch" or planned feature, to eliminate this code > bloat? > > if not, my company will have to drop thrift and adopt an in-house solution > (which we really hoped to avoid...) > > > thanks in advance, > -tomer > > [1] a 100 MB library, on today's hardware, is not unheardof, but our > project's RAM footprint is ~30 MB... it would be a pity to require such > big > a footprint just for glue code. > > > > An NCO and a Gentleman >
