[
https://issues.apache.org/jira/browse/FLINK-9694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16549095#comment-16549095
]
ASF GitHub Bot commented on FLINK-9694:
---------------------------------------
Github user pnowojski commented on the issue:
https://github.com/apache/flink/pull/6231
I agree with @zentol and I do not see reason for supporting nulls here.
This fix looks like hiding underlying implementation problem. Default
constructor of `CRowSerializerConfigSnapshot` could use
`CompositeTypeSerializerConfigSnapshot#CompositeTypeSerializerConfigSnapshot()`
(without parameters).
I don't know much about scala, but shouldn't it use this pattern:
https://stackoverflow.com/questions/3299776/in-scala-how-can-i-subclass-a-java-class-with-multiple-constructors
?
> Potentially NPE in CompositeTypeSerializerConfigSnapshot constructor
> --------------------------------------------------------------------
>
> Key: FLINK-9694
> URL: https://issues.apache.org/jira/browse/FLINK-9694
> Project: Flink
> Issue Type: Bug
> Components: Table API & SQL
> Affects Versions: 1.5.0
> Reporter: vinoyang
> Assignee: vinoyang
> Priority: Minor
> Labels: pull-request-available
>
> the partial specific exception stack trace :
> {code:java}
> Caused by: java.lang.NullPointerException
> at
> org.apache.flink.api.common.typeutils.CompositeTypeSerializerConfigSnapshot.<init>(CompositeTypeSerializerConfigSnapshot.java:53)
> at
> org.apache.flink.table.runtime.types.CRowSerializer$CRowSerializerConfigSnapshot.<init>(CRowSerializer.scala:120)
> at
> org.apache.flink.table.runtime.types.CRowSerializer$CRowSerializerConfigSnapshot.<init>(CRowSerializer.scala:123)
> at sun.reflect.GeneratedConstructorAccessor10.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at
> org.apache.flink.util.InstantiationUtil.instantiate(InstantiationUtil.java:319)
> ... 20 more{code}
> related code is :
> {code:java}
> public CompositeTypeSerializerConfigSnapshot(TypeSerializer<?>...
> nestedSerializers) {
> Preconditions.checkNotNull(nestedSerializers);
> this.nestedSerializersAndConfigs = new
> ArrayList<>(nestedSerializers.length);
> for (TypeSerializer<?> nestedSerializer : nestedSerializers) {
> TypeSerializerConfigSnapshot configSnapshot =
> nestedSerializer.snapshotConfiguration();
> this.nestedSerializersAndConfigs.add(
> new Tuple2<TypeSerializer<?>, TypeSerializerConfigSnapshot>(
> nestedSerializer.duplicate(),
> Preconditions.checkNotNull(configSnapshot)));
> }
> }
> {code}
> exception happens at :
> {code:java}
> TypeSerializerConfigSnapshot configSnapshot =
> nestedSerializer.snapshotConfiguration();
> {code}
> the reason is the type of constructor's parameter "..." used "varargs"
> feature. The initialize code in *CRowSerializer.scala* is :
> {code:java}
> def this() = this(null) // Scala code
> {code}
> when invoked this, actually the the type of
> CompositeTypeSerializerConfigSnapshot's
> nestedSerializers parameter is :
> {code:java}
> TypeSerializer<?>[] nestedSerializers = new TypeSerializer<?>[] {null};
> {code}
> so the checkNotNull precondition statement :
> {code:java}
> Preconditions.checkNotNull(nestedSerializers);
> {code}
> is always useless.
> So we should check the object reference in _for_ loop to protect NPE.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
