Hi Ben,
I remember some discussion a while ago around that topic. IIRC there was no
final action taken on this, but I see the problem.
I personally think it is a good proposal, and I would suggest to follow the
usual way with contributions: file a JIRA ticket (or re-use a matching
existing one) and send a pull request via GitHub referring that ticket
number. That way people can look at it and review the stuff until everyone
is happy with it.
@Android devs: Anyone willing to do an in-depth review? That would be
awesome!
http://thrift.apache.org/docs/HowToContribute
Have fun,
JensG
-----Ursprüngliche Nachricht-----
From: Ben Bader
Sent: Tuesday, June 14, 2016 9:08 PM
To: [email protected]
Subject: Android-specific codegen and runtime proposal
Hi Thrift devs,
I maintain a Thrift implementation that is specialized for Android
(https://github.com/Microsoft/thrifty), and am curious if there is any
interest in accepting something like this in Apache Thrift. I’ll try to be
brief and summarize.
Briefly, on Android we have a system limitation such that application code
is limited in the number of methods that can be referenced – 65,535 to be
precise. The generated Java code from the Apache compiler is very heavy in
this respect – the app that I work on, for example, has about 300 thrift
structs which occupied 35,000 of the methods at our disposal. We ended up
hitting the limit, which meant that we could no longer add code to our app
without either removing other code or using slow/bug-prone workarounds.
With that motivation, we implemented our own Thrift compiler and runtime.
The key notions are:
- No getters and setters - struct fields are Java fields
- No isSet/setIsSet - unset fields are represented by null
- No schemes or factories
This plays a little loosely with the accepted meanings of
required/optional/default requiredness, but at least in client usage it is
sound. This approach took us from 35,000 methods to 6,400, a substantial
improvement.
With all that being said, I think there is room for some of these ideas as a
new runtime/codegen pair. Facebook’s fbthrift fork has something similar
which, although it doesn’t go as far as what we’ve done, demonstrates the
need for such a feature. I’m interested in your thoughts!
Thanks,
Ben
