Enum definition with a value "VALUES" generates code that fails to compile in Java

[dcitron]

Given the following proto file:

package test;

enum TestEnum {
  VALUES = 0;
}

the generated Java code fails to compile:

variable VALUES is already defined...

This is because the generated enum java code includes the following generated declaration (in order to implement valueOf())

private static final TestEnum[] VALUES = values();

A solution might be to use more unlikely internal names in the generated code (perhaps with a prefix, etc.).

[olim7t]

I also ran into that. Java is my main target so I was able to change the value name immediately, but this could be more serious if not detected until later.

I agree that something like __VALUES in the generated code would be less likely to clash. The protobuf compiler could also detect that special name and warn the user.

[dcitron]

I looked into this more and perhaps all that's required is to change VALUES to something like __VALUES__ at the following two places:

https://github.com/protocolbuffers/protobuf/blob/2ef1b7a9fad4c02c7e85aeac4819fb44406b2a17/src/google/protobuf/compiler/java/enum.cc#L309-L313

https://github.com/protocolbuffers/protobuf/blob/2ef1b7a9fad4c02c7e85aeac4819fb44406b2a17/src/google/protobuf/compiler/java/enum.cc#L355-L358

There could be more to it than that, though -- should I work up a PR?

[googleberg]

Ideally, that would be the case. Unfortunately, there are cases within Google that use reflection to get to some of these fields by name. I need to verify that changing this name doesn't break anything.

[dcitron]

Sounds good, @googleberg! I re-built it locally after changing VALUES to __VALUES__ in those two places, and the fix is working for me (and allowing me to proceed), but I understand that it might be a risky change.

Hopefully the Google code is calling valueOf() and not directly accessing the private static final VALUES field, but anything is possible.

[gwenshap]

FWIW, we also ran into this issue. Hopefully Google can validate these soon and the simple fix can be merged and released.

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago.

[dcitron]

Is there any interest in fixing this? Shall I work up a pull-request myself?

[googleberg]

Hi @dcitron, unfortunately, the "VALUES" field is accessed refectively inside of Google. I will file a bug to clean up those uses and then change the name.

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago.

[dcitron]

Hi, @googleberg ! Is there any update on this? Thank you!

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago. This issue will be closed and archived after 14 additional days without activity.

[googleberg]

Unfortunately, we have not yet had the bandwidth to do the prerequisite cleanup to do the fix.