-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unbounded wildcards in Collections and Maps #112
Conversation
Avoid wrong generic method resolution (c.f. http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.5.1 ; example 4.5.1.1.)
- additional wildcards
Glad to see the same pull request as mine. I think your changes are better than mine. I see the main difference is related to Map, If you agree I'll close my pull request and keep yours. |
@domusofsail |
The perception that keys have to be strings in JSON surely is correct.
Maybe we could settle for something like the following comment/javadoc in the methods accepting a The keys of the Map parameter are usually strings, if not, then the keys toString() implementation will be used to derive a proper JSON key. |
I believe there are 2 points to consider:
So my vote is for @mdobrovnik solution to accept |
Clarifying comments. Additional Collection<?> occurence.
Added the comments. |
Please see the README. |
Generics: use unbounded wildcards instead of Object as generic type.
There is a JSONArray constructor with
(Collection <Object> c)
and another constructor with signature(Object o)
. A call withnew JSONArray(new HashSet<Something>())
will not resolve to thefirst constructor, but to the second one. This broke our code when we tried to upgrade from
an older JSON-java version.
There is a similar issue which concerns Maps. Maps with
<?,?>
instead of<String, Object>
type parameters should be used. So maximum flexibility is gained for the callers.For details, please refer to example 4.5.1.1. in the java language reference
http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.5.1
Very much appreciate your efforts.
P.S.: just saw the very similar pull request (#111 from @domusofsail).
While i do believe that the changes in my request are a little bit more
complete than the ones incorporated in #111, the remarkable timely coincidence of the two
requests signifies that the principal issue is legitimate.