Scanner for name repository is problematic when constants values are not unique

[andreacalia]

Found out when building on Travis with jdk9. If the package scan finds, e.g., 2 constants with the same value, the key of the internal map will be the same overriding one of them..

How could we improve this? This pull request is just for not forgetting about this :)

[andreacalia]

This is the test that should work after the improvements

[michi42]

I don't think there is a general solution for this problem - how shall we know which constant is the "right" one? Unless we want to work somehow with annotations (e.g. qualifiers) I think the best would be to force exactly one match or else throw. There could be another method which never throws but returns a Set of names.

[andreacalia]

Yes, there isn't a clear option in my opinion. We anyway have to choose one, I think throwing is a good option since at least you get a nice error message, but then we have to restrict the packages to scan, because it will throw while scanning Java packages out of our control (this it exactly what was happening).

[kaifox]

Probably a solution could be to not throw when scanning, but keep the set in the repo. However, when querying we could have several methods (There one has to know what to expect and it is potentially a better moment to throw...). E.g. :

repo.names(value); // would return a set
repo.name(value); // would return the name or throw if none or more than one.
repo.optionalName(value); // would return an empty optional if no name available, a filled optional if the name is present or throw if more names are available.

What would you think?

[andreacalia]

Probably a solution could be to not throw when scanning, but keep the set in the repo. However, when querying we could have several methods (There one has to know what to expect and it is potentially a better moment to throw...). E.g. :

repo.names(value); // would return a set
repo.name(value); // would return the name or throw if none or more than one.
repo.optionalName(value); // would return an empty optional if no name available, a filled optional if the name is present or throw if more names are available.

What would you think?

Agree :)