Github user StephanEwen commented on a diff in the pull request:
https://github.com/apache/flink/pull/1217#discussion_r41126892
--- Diff:
flink-java/src/main/java/org/apache/flink/api/java/io/CollectionInputFormat.java
---
@@ -130,8 +130,14 @@ public String toString() {
if (elem == null) {
throw new IllegalArgumentException("The
collection must not contain null elements.");
}
-
- if (!viewedAs.isAssignableFrom(elem.getClass())) {
+
+ // The second part of the condition is a workaround for
the situation that can arise from eg.
+ // "env.fromElements((),(),())"
+ // In this situation, UnitTypeInfo.getTypeClass returns
void.class (when we are in the Java world), but
+ // the actual objects that we will be working with,
will be BoxedUnits.
+ if (!viewedAs.isAssignableFrom(elem.getClass()) &&
--- End diff --
This looks like a fragile (and unelegant) test that can easily break as
soon as Scala changes something about boxed units.
Is there a different way to do this, for example let the `UnitTypeInfo`
return directly `BoxedUnit` as the type class?
If that is not possible, then this needs a Unit test in `flink-tests` to
guard this check...
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
