[
https://issues.apache.org/jira/browse/FLINK-9694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16552686#comment-16552686
]
ASF GitHub Bot commented on FLINK-9694:
---------------------------------------
Github user yanghua commented on the issue:
https://github.com/apache/flink/pull/6231
@pnowojski I have said it is because of the constructor :
```
CompositeTypeSerializerConfigSnapshot(TypeSerializer<?>...
nestedSerializers)
```
used [`varargs ` in JIRA
description](https://issues.apache.org/jira/browse/FLINK-9694), the last
comment in this PR, I just explain it looks like this style.
We added null check and it works fine in our Flink env. So if we do not
process it, in this case, this code is useless:
```
Preconditions.checkNotNull(nestedSerializers);
```
Why we do not check null in the potential nullable context? So what's the
way you think is not ugly and dangerous?
> 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)
