java vs c#

[ichengzi]

c#

1. virtual, abstract 修饰 method， 必须为 public，否则编译错误
2. virtual method, 必须有方法体
3. abstract method, 不能有方法体
4. virtual method, 子类可以添加 override 重写
5. abstract method, 子类必须添加 override 重写
6. 有一个方法方法被标记 abstract， 则class必须标记 abstract
7. abstract class 不能实例化， 需要子类来实现

java

1. java 没有 virtual关键字
2. abstract 关键字规则同 c#, 除了子类重写方法可以不标记 override

时间格式化时， 默认日期， 1970 vs 2021

java8 严格区分了 localDate, localTime, LocalDatetime 不提供日期部分，不允许解析，直接异常
LocaTime 不允许 格式化为 yyyy, 也是直接异常
相对来说，更喜欢 joda一些，兼容性更好

[ichengzi]

多态是OO里非常重要的特性， 抽象、封装、继承 某种程度上就是为了实现多态

1. overide (重写) 是方法签名相同，实现不同， 是实现多态的有效手段。
2. overload (重载) 是只有方法name相同， 方法签名里的其他部分无要求。

坑1

override 这个重要的的功能， java并没有用关键字来实现， 而是用了个 @java.lang.Override(jdk1.5才引入) 注解来实现了，并且在javac编译器中，并没有强制要求强制标记 @override , 导致有复杂继承关系的代码， override 逻辑非常不清晰，需要借助外部工具来梳理。eg: juc 中的类基本都没有添加 @override 注解。(这个应该是历史包袱，没法轻易改动)

比如下方， java.util.AbstractList 并对于 java.util.Collection<E> 方法的override ， 中间经过了 List<E> , AbstractCollection, 多层的 override 导致 override 逻辑树不清晰。

如果不熟悉整个设计和继承结构， 只看代码， 不借助IDEA工具，
很难分清到底是实现类自己的方法， 还是override 父类的方法。

[ichengzi]

JDK代码可读性 0x00

---

j.u.c.CompletableFuture

j.u.c 里的代码，

1. 经常性的在if 语句里做赋值， 影响阅读
2. 上下对比， 上边的 getCause() 调用了两次， 不清楚是不是这里的性能考量， 因为多了一个方法调用帧栈。 因为这里还涉及一个前置条件判定， 那么这里 if 条件中赋值，可以考虑。