diff options
| author | CodingCat <zhunansjtu@gmail.com> | 2016-04-18 18:51:23 -0700 |
|---|---|---|
| committer | Reynold Xin <rxin@databricks.com> | 2016-04-18 18:51:23 -0700 |
| commit | 4b3d1294aeecc0001a7fa48c92796e6075d34540 (patch) | |
| tree | 51b4bb62bcbec0bf13c41457b9d0eacd543ea274 /common/network-shuffle/src | |
| parent | 2b151b6b93e7ef747c625d3a2b0f0732039de3b8 (diff) | |
| download | spark-4b3d1294aeecc0001a7fa48c92796e6075d34540.tar.gz spark-4b3d1294aeecc0001a7fa48c92796e6075d34540.tar.bz2 spark-4b3d1294aeecc0001a7fa48c92796e6075d34540.zip | |
[SPARK-13227] Risky apply() in OpenHashMap
https://issues.apache.org/jira/browse/SPARK-13227
It might confuse the future developers when they use OpenHashMap.apply() with a numeric value type.
null.asInstance[Int], null.asInstance[Long], null.asInstace[Float] and null.asInstance[Double] will return 0/0.0/0L, which might confuse the developer if the value set contains 0/0.0/0L with an existing key
The current patch only adds the comments describing the issue, with the respect to apply the minimum changes to the code base
The more direct, yet more aggressive, approach is use Option as the return type
andrewor14 JoshRosen any thoughts about how to avoid the potential issue?
Author: CodingCat <zhunansjtu@gmail.com>
Closes #11107 from CodingCat/SPARK-13227.
Diffstat (limited to 'common/network-shuffle/src')
0 files changed, 0 insertions, 0 deletions