Enum vs @IntDef

105 views
Skip to first unread message

Bo Liu

unread,
Jul 20, 2020, 11:05:08 AM7/20/20
to java, ericwi...@chromium.org
Came up on this CL:

Enum bloats the binary size and I don't believe that has changed. The rule for avoiding enums isn't actually written down however; at least I didn't find it when I tried.

@IntDef afaict isn't actually type safe and is just serving as documentation. Eg this is an example where just passing an int into a @NetError and nothing seems to complain. So unless it can be fixed, the choice here is actually a trade off between binary size and type safety. For an content API that might end up being used widely, I think it might actually be worth the binary hit in this case.

Thoughts?

Andrew Grieve

unread,
Jul 20, 2020, 11:36:30 AM7/20/20
to bo...@chromium.org, java, ericwi...@chromium.org
R8 team has been working on optimizing enums -> ints for the past few months. I expect the optimization to land at some point this quarter. I think we should probably still just have no documentation on it for the interim, but then hopefully we can use them (in perhaps constrained ways).

I'd probably still avoid them for now, since I'm skeptical they will be optimized to the point of ints (e.g. they might still require null checks to be put in here or there). So long as you're using constants, I don't think the extra type safety adds meaningfully more safety.

@IntDef is supposed to be checked by android lint, and be more than just documentation. It's a bug if there's a case where it's not working. Note that in order to run lint now, you need to build an apk / module target rather than just an individual library target.

--
You received this message because you are subscribed to the Google Groups "java" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java+uns...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/java/CAPCJOUqcLMWO41eQd%2BQEVmB7SxVQ1Y641E7hxUGqwhVuugEduQ%40mail.gmail.com.

Bo Liu

unread,
Jul 20, 2020, 11:47:02 AM7/20/20
to Andrew Grieve, java, ericwi...@chromium.org
> @IntDef is supposed to be checked by android lint, and be more than just documentation. It's a bug if there's a case where it's not working. Note that in order to run lint now, you need to build an apk / module target rather than just an individual library target.

Playing around with it locally, I can't get it to ever fail the build..

On Mon, Jul 20, 2020 at 11:36 AM Andrew Grieve <agr...@chromium.org> wrote:
R8 team has been working on optimizing enums -> ints for the past few months. I expect the optimization to land at some point this quarter. I think we should probably still just have no documentation on it for the interim, but then hopefully we can use them (in perhaps constrained ways).

I'd probably still avoid them for now, since I'm skeptical they will be optimized to the point of ints (e.g. they might still require null checks to be put in here or there). So long as you're using constants, I don't think the extra type safety adds meaningfully more safety.

@IntDef is supposed to be checked by android lint, and be more than just documentation. It's a bug if there's a case where it's not working. Note that in order to run lint now, you need to build an apk / module target rather than just an individual library target.

On Mon, Jul 20, 2020 at 11:05 AM Bo Liu <bo...@chromium.org> wrote:
Came up on this CL:

Enum bloats the binary size and I don't believe that has changed. The rule for avoiding enums isn't actually written down however; at least I didn't find it when I tried.

@IntDef afaict isn't actually type safe and is just serving as documentation. Eg this is an example where just passing an int into a @NetError and nothing seems to complain.

Andrew Grieve

unread,
Jul 20, 2020, 12:03:13 PM7/20/20
to bo...@chromium.org, Andrew Grieve, java, ericwi...@chromium.org
On Mon, Jul 20, 2020 at 11:47 AM Bo Liu <bo...@chromium.org> wrote:
> @IntDef is supposed to be checked by android lint, and be more than just documentation. It's a bug if there's a case where it's not working. Note that in order to run lint now, you need to build an apk / module target rather than just an individual library target.

Playing around with it locally, I can't get it to ever fail the build..

On Mon, Jul 20, 2020 at 11:36 AM Andrew Grieve <agr...@chromium.org> wrote:
R8 team has been working on optimizing enums -> ints for the past few months. I expect the optimization to land at some point this quarter. I think we should probably still just have no documentation on it for the interim, but then hopefully we can use them (in perhaps constrained ways).

I'd probably still avoid them for now, since I'm skeptical they will be optimized to the point of ints (e.g. they might still require null checks to be put in here or there). So long as you're using constants, I don't think the extra type safety adds meaningfully more safety.

@IntDef is supposed to be checked by android lint, and be more than just documentation. It's a bug if there's a case where it's not working. Note that in order to run lint now, you need to build an apk / module target rather than just an individual library target.

On Mon, Jul 20, 2020 at 11:05 AM Bo Liu <bo...@chromium.org> wrote:
Came up on this CL:

Enum bloats the binary size and I don't believe that has changed. The rule for avoiding enums isn't actually written down however; at least I didn't find it when I tried.

@IntDef afaict isn't actually type safe and is just serving as documentation. Eg this is an example where just passing an int into a @NetError and nothing seems to complain.


Tommy Nyquist

unread,
Jul 21, 2020, 7:53:26 PM7/21/20
to Andrew Grieve, boliu, java, ericwi...@chromium.org
I'd prefer us using @IntDef and finishing up the recent lint work, as it definitely should be reported as an issue.

Peter Wen

unread,
Jul 22, 2020, 10:16:51 AM7/22/20
to Tommy Nyquist, Andrew Grieve, boliu, java, ericwi...@chromium.org
Reply all
Reply to author
Forward
0 new messages