madrob commented on a change in pull request #169:
URL: https://github.com/apache/solr/pull/169#discussion_r651178061
##########
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/io/ClassificationEvaluation.java
##########
@@ -36,28 +36,26 @@ public void count(int actual, int predicted) {
}
}
- @SuppressWarnings({"unchecked"})
- public void putToMap(@SuppressWarnings({"rawtypes"})Map map) {
+ public void putToMap(Map<? super String, ? super Long> map) {
map.put("truePositive_i",truePositive);
map.put("trueNegative_i",trueNegative);
map.put("falsePositive_i",falsePositive);
map.put("falseNegative_i",falseNegative);
}
- @SuppressWarnings({"rawtypes"})
- public Map toMap() {
- HashMap map = new HashMap();
+ public Map<String, Long> toMap() {
Review comment:
There is some nuance here for why the signatures are different. The
mnemonic I've heard that helps me remember is PECS (producer-extends,
consumer-super). When we putToMap, we need the caller to know that they have to
give us a map that can handle strings and longs. It could be Object,Object, and
that's sufficient, the important bit is that somebody won't pass a
Map<String,String> where they later will expect the values to be something
they're not. When we return from toMap, we explicitly declare what we have, and
while this does limit that somebody can't assign it to a Map<Object,Object>
anymore, putting bounded wildcards in the return type doesn't let them do that
either.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
