Java 判断空操作

[kuyuzhiqi]

我的理解是 java 里面的对象都是用到的时候才判断是否为空吧，比如传递 String，传的时候可以为 Null，但使用的时候做判断吧

[ycfung]

印象中是这样（为什么不自己跑一下啦…有的时候不一定是这个问题😅

[wyieeLu]

理解是没错的

[kuyuzhiqi]

@ycfung 是同事让我不要这么传，免得 app 崩溃了，感觉挺沙雕的

[lagoon]

这是 app 的老大难问题，后来传 null 来怎么办，总不能到处判断。
所以我改用 kotlin 了。app 是希望从源头上，避免空值的产生吧。

[lagoon]

后来=后台

[ipwx]

这不是傻屌。Java 里面的 null 甚至被其发明者认为是错误的设计。

https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions

对于强类型的语言而言，Optional<T> 其实更优雅，因为语义上就会提示调用者这返回值可能是空。

https://lw900925.github.io/java/java8-optional.html

[DrJoseph]

字段加 @JsonInclude(JsonInclude.Include.NON_NULL)属性就好了，序列化时会过滤掉
但传个 null 也会 app 崩溃，确实很沙雕

[DrJoseph]

纠正一下，那个不是属性，是注解，手误打错了

[ffeii]

经常这样：“ app 改的话还要发新版本，服务器改是最快的”。

[kuyuzhiqi]

@ipwx 设计如此，但好像记得出现了 谁使用谁判断的原则

[micean]

很多安卓开发人员懒得写问号，也懒得补默认值，于是乎就崩溃了

[ipwx]

@kuyuzhiqi 你这个原则是建立在 Java 作为强类型语言却有 Null，而且因为早期没有 Optional，所以大量开发人员不保证不传回 Null 这一事实基础上的。

如果随处要检查 null，会带来巨大的开销。现代 CPU 都有流水线，一个 if 条件判断会打断流水线，造成几十倍的性能损失。虽然 Java 有牛逼的 JIT，对于大部分情况下不返回 null 的接口，很多时候可以弥补这一性能损失，但是如果一开始就不需要判断 if，岂不美哉？

[kuyuzhiqi]

@ipwx 像实体的话如果默认不为空岂不是实体多了就很占内存

[ipwx]

@kuyuzhiqi 不不不，引用 /指针其实没问题，但是可以设计为，不能把 null 赋予一个引用 /指针。即，一个引用 /指针的初始化必须是有东西的。如果你想表示一个可能是空的东西，就用范型叠加，比如 Optional<T>。

当然，Java 的范型是补丁打上去的，是个 shit，这是另一回事情了。

[ipwx]

@kuyuzhiqi 至于 Optional<T>，可以设计为内置功能而不是打补丁打上去的类。这样的话也不会有多少效率损失，字节码层面完全可以进行编译期优化。当然这就变成另一个语言而不是 Java 了。

如果是 Java 的话，那就只能靠约定了。虽然我觉得 Optional<T> 的约定很舒服，可是也并不是所有人都认同这种用法，就没办法了。

[EastLord]

Optional 了解一下

[wysnylc]

java8 新增 Optional,可以处理这种情况

[ukyoo]

java8 好多特性包括 Optional 安卓要 SDK24 以上才支持....安卓还是老老实实 Kotlin

[passerbytiny]

@ipwx 说得振振有词，那么：if(a !=null)，跟 if(a.isPresent)，或者 a.ifPresent(()->{bulabula})，到底损失了多少性能呢； Optional.get()是不是永远不会抛出 NullPointException 呢；在序列化 json 的时候，你要怎么处理 Optional 字段呢。

null 到底是强类型语言的特性，还是弱类型或无类型语言的特性呢。

[ipwx]

@passerbytiny 所以我说了嘛，如果要超级好用的 Optional （包括解决性能问题），得要别的语言，反正不能是 Java。