madrob commented on a change in pull request #169:
URL: https://github.com/apache/solr/pull/169#discussion_r650535730
##########
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/beans/DocumentObjectBinder.java
##########
@@ -408,28 +406,28 @@ private Object getFieldValue(SolrDocument solrDocument) {
}
}
- @SuppressWarnings({"unchecked", "rawtypes"})
<T> void inject(T obj, SolrDocument sdoc) {
Object val = getFieldValue(sdoc);
if(val == null) {
return;
}
if (isArray && !isContainedInMap) {
- List list;
+ List<?> list;
if (val.getClass().isArray()) {
set(obj, val);
return;
} else if (val instanceof List) {
- list = (List) val;
+ list = (List<?>) val;
} else {
- list = new ArrayList();
- list.add(val);
+ List<Object> temp = new ArrayList<>();
+ temp.add(val);
+ list = temp;
Review comment:
In this case I think we can actually get away with
Collections.singletonList because we turn it into an array on the next line
anyway. In general, it's because you can't add any objects to a wildcard
capture.
##########
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/GaussFitEvaluator.java
##########
@@ -81,7 +80,7 @@ public Object doWork(Object... objects) throws IOException{
double[] coef = curveFitter.fit(pointList);
Gaussian gaussian = new Gaussian(coef[0], coef[1], coef[2]);
- List list = new ArrayList();
+ List<Double> list = new ArrayList<>();
Review comment:
I'm not sure I understand the suggestion - `VectorFunction` takes a
List<? extends Number> specifically so that we can have the flexibility to use
`List<Double>` or `List<Integer>` or whatever in other places.
##########
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/CloudSolrStream.java
##########
@@ -284,12 +284,10 @@ public void open() throws IOException {
return solrStreams;
}
- @SuppressWarnings({"unchecked"})
private StreamComparator parseComp(String sort, String fl) throws
IOException {
String[] fls = fl.split(",");
- @SuppressWarnings({"rawtypes"})
- HashSet fieldSet = new HashSet();
+ HashSet<String> fieldSet = new HashSet<>();
Review comment:
I think you're right about this. I'd prefer to see that as a separate
issue so that we can cover this, and SearchStream, and add a unit test.
##########
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/FetchStream.java
##########
@@ -204,9 +205,8 @@ public void setStreamContext(StreamContext streamContext) {
return l;
}
- @SuppressWarnings({"unchecked", "rawtypes"})
public void open() throws IOException {
- tuples = new ArrayList().iterator();
+ tuples = Collections.emptyIterator();
Review comment:
I don't think there's any reason for this, we don't use ListIterator
functionality anywhere with this.
##########
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/SearchStream.java
##########
@@ -227,13 +227,12 @@ public StreamComparator getStreamSort() {
return comp;
}
- @SuppressWarnings({"unchecked", "rawtypes"})
private StreamComparator parseComp(String sort, String fl) throws
IOException {
- HashSet fieldSet = null;
+ HashSet<String> fieldSet = null;
Review comment:
Good catch.
##########
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/DbscanEvaluator.java
##########
@@ -90,8 +88,7 @@ public Object doWork(Object... values) throws IOException {
}
}
- @SuppressWarnings({"rawtypes"})
- Map fields = new HashMap();
+ Map<String, Object> fields = new HashMap<>();
Review comment:
We can safely pass a String to a wildcard type bound. The receiver makes
no assumptions about the types, and will read them as Objects regardless of
what they are declared as.
##########
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/DbscanEvaluator.java
##########
@@ -90,8 +88,7 @@ public Object doWork(Object... values) throws IOException {
}
}
- @SuppressWarnings({"rawtypes"})
- Map fields = new HashMap();
+ Map<String, Object> fields = new HashMap<>();
Review comment:
I did a little more looking and am fairly confident that Tuple key types
should always be Strings anyway, so we are enforcing that now (and I got rid of
the Object... varargs constructor that wasn't letting us do that)
--
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
