[QUESTION] Use enumerated annotations instead of enums

Given how inefficient enums are on Android, would it be possible to leverage enumerated annotations instead of generating plain Java enums?

[futtetennista]

I’m not working on a project that involves Thrift on Android atm so I won’t be able to try it in the near future. But thanks a lot for implementing it.

On Fri, 11 Nov 2016, 02:15 Ben Bader, [e-mail] wrote:

@futtetennista https://github.com/futtetennista I don’t know if you’re still interested in this feature, but I slapped it together just now. It’s available to play with at https://github.com/benjamin-bader/thrifty/tree/int-enums. I’m probably not going to publish this as a snapshot soon; it’s such a far-reaching change that the current test setup can’t do both Java and IntDef enums.

If you do try this out, I’d be curious what it does to your total method count and to your .dex size. My suspicion is that it won’t do much, due to the helper classes. If we decided to forego string names, that would change things considerably.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/Microsoft/thrifty/issues/20#issuecomment-259855659, or mute the thread https://github.com/notifications/unsubscribe-auth/AATuwz8hwtw1i6xq_9PrGZzQ6HTUKKGZks5q88GogaJpZM4H1Ds2 .

[benjamin-bader]

My understanding is that the ~1.5kb “memory penalty” for enums happens per declaration

Hmm, maybe I misunderstand. I’m thinking that quite a bit of that 1kb comes from the base class and associated code, which (thanks to object orientation) are shared across declarations. Certainly, methods like Enum#values() get deduplicated during dexing.

As you say, it’s not exactly the case that using a few enums will ruin your app. I still hold the belief that the safety provided by enums outweighs their cost on-device. I certainly wouldn’t use such a feature as int-enums myself, but wouldn’t say no to having an option (non-default) to generate them.