Github user ggevay commented on a diff in the pull request:
https://github.com/apache/flink/pull/1217#discussion_r41135832
--- 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 --
I agree that this is not elegant, but I don't see any better way.
UnitTypeInfo.getTypeClass can't return classOf[BoxedUnit], because
TypeInformation<T>.getTypeClass() returns Class<T>, and here T is Unit.
I already had a test for this in TypeInformationGenTest.testUnit. Now I
also added a comment, that explains that those two lines in the test are
testing this condition.
By the way, if you really dislike this condition, then I can just remove
it. The rest of the PR already solves my original problem, so I can live
without "fromElements((),(),())" working.
---
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.
---
