[
https://issues.apache.org/jira/browse/BEAM-6545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16756398#comment-16756398
]
Ahmet Altay commented on BEAM-6545:
-----------------------------------
Thank you for checking. I suggest:
* Removing this from the blocker list. It is possible that user in question is
overriding the dependency.
* Change the code to preserve the previous behavior (i.e. return null for null
input instead of calling into base64 library). I did a quick search there are a
few uses of this.
Hopefully there are no other similar changes in the underlying library. Could
we use tooling to check whether we are passing any Nullable variables to any
libraries we use that does not accept Nullable args?
> NPE when decoding null base 64 strings
> --------------------------------------
>
> Key: BEAM-6545
> URL: https://issues.apache.org/jira/browse/BEAM-6545
> Project: Beam
> Issue Type: Bug
> Components: sdk-java-harness
> Affects Versions: 2.9.0
> Reporter: Ahmet Altay
> Assignee: Kenneth Knowles
> Priority: Major
> Fix For: 2.10.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> **ByteArrayShufflePosition.fromBase64 is marked with a @Nullable argument,
> however it does not properly handle null inputs resulting in NPE.
> This seems like an unintended change we picked up from the dependency:
> google-http-java-client/ switched from apache commons to guava
> ([https://github.com/googleapis/google-http-java-client/commit/990c534f0e5103a142b0639c12c90cb990a00cfd#diff-97264fba16d690a26d63fbbc992af937)]
>
>
> and decodeBase64 behaves differently in both cases. Former can handle null by
> returning null, latter will throw NPE.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
