确实有点为赋新辞强说愁的感觉；

楼主为了解决关系型数据库的模型、语义等和 Java 的对象模型不一致的问题，发明了一堆注解和一个 DSL ；
其他人为了解决同样的问题，发明了一个概念叫对象关系映射，同样的，发明了一堆注解和一个 DSL （ Criteria ）；

so，大家都是一样的东西，你这个咋就“完美的解决了上述两个问题”呢。。。

lettuce 的优点一直不是性能啊。。。而是可以复用的连接、易用的同步 API 、统一风格的异步 API 、完备的功能和对 Redis 新特性的支持

6 了

@gantleman emmmm 可能是我没说清楚。“游戏服务器对性能要求非常的高”这种结论一般是横向对比 web 服务器得出的，通常的逻辑链条是：游戏业务延迟敏感+连接数少运算量大 = 性能要求高 --> 要用 C++实现。我想说的是，在客户端的角度，服务器实现成什么样并没有区别，所以，没必要非得上 C++。

纯函数的话，这个想法是可行的。。然而纯函数的单测很容易写，通过这样的方法生成用例感觉绕路了。

其实不太能理解游戏服务器对性能要求非常高这种结论是怎么来的。。。对客户端来说，绝大多数 RTT 都在网络传输上，无论服务器实现成什么样，也就是响应时间增减几毫秒的问题，当然可能有个别业务特别耗时，但不会影响玩家的整体体验。因此，为啥非得上 C++呢。。。Java+ZGC 可以把暂停时间控制在 10ms 以内，大多数时候不超过 2ms 。。

盲猜是 Jackson，请自行实现 JsonDeserializer ；
其他的 json 库也都有类似设计。

如果对测试特性没有什么心理障碍的话，可以试试这个

https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md#run---mounttypecache

可以缓存编译的中间产物

@ohoh 感觉你在嘲讽 yinxiang notebook

@passerbytiny
1. 序列化(Serialization)是将对象的状态信息转换为可以存储或传输的形式的过程，反序列化是相反的过程。JSON 是一种可以存储或传输的数据格式规范，因此把对象转换成 JSON 的过程就是序列化，把 JSON 数据转换为对象的过程就是反序列化。这中间并不需要转出来的 JSON 和原来的对象一一对应，甚至不需要转出来的 JSON 能通过反序列化还原为原来的对象。不是很懂你对序列化有什么误解。
2. 能举一个活得还不算差的基于 Java 序列化的 RPC 框架吗，我觉得同时支持多种序列化方式的 RPC 框架可能不能算，因为有选择的情况下，多数人应该不会选它。。
3. 由于历史包袱，Java 中的确存在大量的不被推荐使用的 API，它们可能没有被显式标注废弃，但的确是在被逐渐减少使用，包括旧的 DateTime 相关工具类、clone 方法，也包括 Serializable 接口。

GBoard 可以满足文本方面的管理需求。。

why not

如果 MarkDown 只是给自己看，那这样的东西是有用的。。

@whypool #9 能不能详细说一下，这个思路比较清奇。。

不空，除非方法签名太长占了好几行

hao123 ？