Java 判断空操作

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

理解是没错的

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

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

后来=后台

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Optional 了解一下

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

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

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

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

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