这是从油管《 Java's Plans for 2022 - Inside Java Newscast #18 》那评论扒下来的吧。
这个 plan 只是那老哥“This is really just my personal guess. I don't ask the devs for their estimates because I'd either get the official, vague reply or I'd get details that I can't share. So all I know is from the JEPs, mailing lists, talks, etcetera. That means this is no official Oracle announcement, you can't trust a word I say (imagine safe harbor slide), and you better not base business decisions on my ramblings.”，
离“Java 的究极体”其实还远远远着呢，Java 就靠其生态圈吃饭，而 Loom 和 Valhalla 都是很比较激进的特性，就算正式发布了，等其生态做完适配都不知道猴年马月了，我倒是好奇会是它们的生态先成熟，还是柯南先大结局。

Amber 项目搞语法糖的，没啥好说。
Loom 项目个人没啥感觉，有迫切需求的要么切 go 了，要么上 reactor 了，协程对生态的不确定性还是太大，很多依赖库就靠线程才玩起来的（随便举个例子：日志的 MDC ）。很多老哥不习惯 reactor 那函数式编程，但这玩意就是“写熟了真香”，就靠传统的线程知识，玩 reactor ，玩线程如臂使指，很舒服。
而 Valhalla 那项目做得也太慢了，搞了快 10 年了，连 preview 都不敢发。就算将来当正式特性发布了（而不是 preview 特性），撑死就极个别上层应用敢用，等一些普适性的依赖库适配完，那估计得等到 2030 年，甚至我相信很多依赖库压根不愿意做适配。

总而言之，别抱啥希望在生产环境使用 loom 或 valhalla 做得特性，除非公司自己有能力自己打造一个生态。不过到有其他“生财之道”：1. 做培训； 2. 一些老哥不是感觉 Java 生态太全了，没啥可做了嘛。那就可以根据“新 Java”做全新的依赖库，把那些死气沉沉的古董依赖库弄出去，自己搞个牛逼的依赖库。特别一提，如果有人有兴趣，其实这条现在就可以开始做了。

@jdhao 删帖有啥。我要怕删帖，我就直接上 reddit 聊了。

@paicha 其他传统行业估计更多，只是程序员擅长网上发声，其他行业估计一是传统行业不太有网上发声这习惯，尤其是老一辈人，二是家里人拿钱就收声了，就身边的同事可能知道这些事。我过年跟父辈吃饭的时候就有聊到工厂里基本每年都死 1~2 人，可能是意外死亡，也可能是猝死，具体大家也都没细问。

@wateryessence 感谢。不过这 repo 不太全，司徒正美这么出名也没记录，并且 2021 及往后就没记录了。

国内大部分的开源项目太没想象力了（电商、博客、刷题），真是给国内教育洗脑洗傻了。OP 要做的话，就要结合自己兴趣爱好来做，不然坚持不下来。
我读大学的时候学日语，于是就做了一个兼有日语背单词、语法、刷 JLPT （ N1~N5 ）考题的 APP ，前后端都做，后来这 APP 太侵权了，听说被抓的话，就要吊销 JLPT 证书，就没继续做下去。
后来我学乐器，又想在 Web 端搞个通过 MIDI 键盘的输入，以如图（ https://www.reddit.com/r/piano/comments/fsqyte/i_made_a_piano_visualizer_free_to_download/）形式展示，并自动生成对应的 ABC notation 形式（一种可以显示成五线谱的文本，并且这文本 /五线谱可以放到 Markdown 里）。当然，这个我还没做，已经有开源项目要维护，就没精力再开一个了。

实在对啥都没兴趣，不如刷题。

op“家产 1500+W ，复旦毕业”，如#39 说的，“追求个姑娘都再三犹豫，缩头缩脚的”。
国男能不能别那么羞涩？自己没那脸皮，不敢上，就不要怪是所谓的“客观原因”：“自己匹配不上”，多多检讨自己的主观原因，你交女性朋友都直奔结婚去的？交个朋友总行吧。建议交几个混夜店的朋友，让他们带你见识下夜生活，或者抽空学学 PUA 技巧，不要把男女交往想得那么保守+矜持，心态放开

看到“代码开源，自架免费”，有点感慨。国内这环境，这话可不太可信，算是一句空头支票。国内有很多“半”开源项目了，社区版做了一个垃圾出来，几个月更新一次，更到后面就不更了，然后就靠卖商业版赚服务费 /咨询费。看到这类项目，我一般称之为“屎壳郎”，见面就直接 diss 。虽然 op 可能没这么想，但是国内大环境就是如此，你要别人怎么信任你呢？你今天可能没这么想，那以后要是赚大钱了呢？国内的开源项目能有 1/10 讲信用 /良心，就已经算“重大突破”了。
国内大环境都已经这么乌烟瘴气，那些愿意投钱的老哥也真是善良。

已点赞支持。程序员这圈子，其实有两条很清晰的路，一条刷流量，一条靠实力做内容，技术公众号 /开源项目就是很好的例子，要是想靠实力做内容，心态要尽量放平，不要跨路子跟别人搞流量的比。大家其实都是明眼人，看看内容 /看看代码，很容易就知道你是混内容的，还是混流量的。
长期做内容，一方面实力很重要，需要长时间沉淀，尽管这种教程播放量低，但别人知道你牛皮，不过我觉得这路子也不好混，好的技术教程太多了，我经常上 B 站看各种大学课，播放量能超 1W 的寥寥无几。要么就搞快餐，忽悠路过的小白，当然这跟程序员其实没啥关系了。另一方面，还是上面说的，心态要放平，不然做的心累，还不长久。

@omysho 没计划支持，因为这 feature 做了没什么意义。中国合规的 IM 应用不可能搞加密，有加密需求的群体估计也都上 TG 了，哪方都讨不好，所以完全没相关计划。

@q474818917 是的，因为服务端用 JDK17 写得。

题外话，至于为什么用 JDK17 而不用 JDK11 或 8 ，这个问题的思路其实不太对。应该翻过来，为什么不用 JDK17 ，而用 JDK11 或 8 。其实 Turms 服务端在从 JDK11 升到 17 的时候，什么 BUG 都没遇到，就跟升个 Spring 版本一样简单。Java 自身是一个很保守的语言，它比我们程序员还怕犯错，与将精力花在其担心 Java 会出错，不如担心自己的业务逻辑有没有 BUG 。哈哈哈

首先，感谢下各位 v2exer 的热情，谢谢各位赏脸给 star 。

@aceimnorst 大哥，你这是给我“保送”跳槽了吗？可能认错人了，哈哈哈

@ffgrinder Rocket Chat 适合企业内部通信，但企业内部通信也可以考虑用国内第三方云，一方面更有安全保证；二是企业通信也没什么特殊逻辑，没必要上 Turms 从底层自研。具体还是我在： https://turms-im.github.io/docs/#%E4%BA%A7%E5%93%81%E5%AF%B9%E6%AF%94 写的 IM 方案对比。

@keppelfei 是呀，看得我都不服，哈哈哈

@yanbo92 互相学习。Turms 到底是把各模块融会贯通，写一个比较完整的 IM 系统，而不是孤立的技术文档+口嗨。我在“https://github.com/turms-im/turms/issues/862”写了，Turms 没什么“原创性”，双数组 Trie AC 自动算法、数据库负载均衡 冷热分离也不是我发明的，我只是拾人牙慧，把他们融汇贯通到 Turms 这项目中，能发明这些算法 /设计的才是真大佬。

@oott123 哈哈哈，那是。前一年多都没要求备案，最近 2 、3 个月开始要求备案，但我那域名是"turms.im"，“im”顶级域名国内备不了案，所以就被拦截了。之后我会把我那 demo 网站迁到 AWS ，之所以没马上迁，是 AWS 真的贵，心疼，哈哈哈。


@leipengcheng 开源 IM 领域能打的就 Turms 一款项目，而 IM 领域估计很难凉，IM 服务下能做支持其他业务的基础服务，上能独立做款应用。如果 IM 领域，Turms 凉了也没关系，我回家找块地耕耕。具体而言：
1. IM 系统自身细节繁多，而开发人员水平又参差不齐，很难保证做出来的项目质量如何。实现用户 A 能给用户 B/群 B 发消息最多也只是实现 IM 系统功能的 1%功能，并且这些功能模块不像是一些通用的依赖库可以随意插拔而是要定制实现并环环相扣的，各模块都要自研，需要设计人员与开发人员有很强的功底（若想了解 IM 系统具体有多少细节功能，可以参考 Turms 的文档）
2. 自研 IM 服务的市场需求大。即便现在到各招聘网站查询 IM 工程师相关岗位，也能发现国内外还有大量企业招聘 IM 相关人才，各公司投入上百或千万从零或基于古老的 IM 开源项目自研，重复造 IM 服务，社会资源利用率低



@TinyKube OpenIM 是最近几个月突然火起来的开源 IM 项目，之所以说突然是因为我最早关注它的时候，它才几百个 stars 。OpenIM 是我印象中除 Turms 以外，最专业的开源 IM 项目，但是：
1. 大的通用缺点可以看我在#8 楼的回复，基础模块就做了百分之几的功能，就不要把自己叫做 IM 系统了。人可以是专业的，但做出来的项目不一定是。很多问题是需要沉淀，不要着急为了抄热度，就匆匆忙忙地上了一些功能，到底来就只能重构：具体看③。
2. 它基于写扩散做架构设计，决定了它很多功能都做不了，且实现低效（ Tumrs 基于读扩散），这点相信这位专家心里也很清楚。我在这篇文章里有分析： https://turms-im.github.io/docs/for-developers/status-aware.html#%E8%AF%BB%E6%89%A9%E6%95%A3%E4%B8%8E%E5%86%99%E6%89%A9%E6%95%A3

3. 细节实现天上地下。
诸如我看它文档里提到：“mongodb 存储离线消息，并定时删除 14 天（可自行配置）前数据； mysql 存储全量历史消息以及用户相关资料”。这里它就危险了：
一是：mongodb 默认只存 14 天消息，以为着它甚至很可能连最基本的数据库负载均衡都没做（ Turms 默认就支持数据库负载均衡，并且开发者无需做任何配置）。
二是：它用 mysql 存储全量历史消息就犯了我在②提到的问题，要么它保持原样，功能受限；要么进行技术重构（我也是在 Turms 的文档 https://turms-im.github.io/docs/for-developers/schema.html#%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90%E4%B8%8E%E9%9B%86%E5%90%88%E7%BB%93%E6%9E%84%E8%AE%BE%E8%AE%A1 中提到的，IM 的表设计中有很多“陷阱”，如果你没想好一个功能的设计，就下手实现。通常，这就意味着：未来要么从数据库层重构，要么保持原样，无法拓展。当然，反正你也可能刷完简历，跳槽跑路了，但这对后来人就惨了，哈哈哈。

对比而言，Turms 已经对 MongoDB 负载均衡与数据的冷热分离（如消息表根据消息记录的创建时间，在数据库负载均衡地分布），而冷数据的备份应该通过类似 AWS Glacier 等专业的存储服务，做 Cold 数据存储（ Turms 目前还没具体设计这个方案，因为还为时过早，另外：哥，你数据都这个规模了，你不给我发发红包？说不过去啊，哈哈哈哈）

4. 架构有点过度设计，需求与架构有点脱节，甚至我有点怀疑是不是在“面向简历编程”。明明关键功能都没实现（看③），如果需求本来就不复杂，那为什么还把架构搞这么复杂？如果需求本来就很复杂，那③的现有设计岂不是得重构？
另外，为什么 Turms 的架构能做的很简单且运维很简单，请看这两篇文章：
1. https://turms-im.github.io/docs/for-developers/architecture.html#%E4%B8%8E%E5%85%B6%E4%BB%96im%E9%A1%B9%E7%9B%AE%E7%9A%84%E6%9E%B6%E6%9E%84%E5%8C%BA%E5%88%AB

2. https://turms-im.github.io/docs/for-developers/cluster.html#%E7%BA%AF%E8%87%AA%E7%A0%94%E7%9A%84%E5%8E%9F%E5%9B%A0
补充：Turms 在早期也有很多“开发优先”的态度，只要我能写得，都给用户包了（如日志分析、度量分析，后来我把这些功能都删了，真是心态），而没关注一个事实：很多功能其实是应该运维 /大数据来做的。诸如 Kafa 可不可以换成弹性伸缩、各种监控报警分析可不可以换成日监控服务（如 AWS CloudWatch ）。现在我已经想明白了，专业的事情就要专业的服务，没必要自己搞一套，要做的功能就必须要做到极致（即：我这方案，我觉得可以 8/90 分了，你要是能想出一个 100 分的方案，那就是你厉害，但我的方案也算优秀）。
自己搞一大堆技术栈，除了“面向简历编程”，对项目没什么实际好处。PS：很多学哲学的人也有这毛病，生怕别人看得懂，很喜欢“摔词”

@ufan0 客户端 UI 我没做，也没计划做。
1. 国内外这类比较漂亮的开源 IM UI 项目还有些，你可以搜搜
2. 的设计与实现与具体业务场景、具体的编程语言、具体的技术架构、具体的运行平台都密切相关。而 Turms 引擎一直是致力于高效地满足各种复杂多变的即时通讯业务场景，不希望因为 Demo 限制了开发者的想象力。并且开发与维护 Demo 也非常地费时费力，会拖慢 Turms 项目的开发进度。
3. 我能画 UI ，但我不会设计 UI 呀。专业设计师和我这些设计 UI 极其业余的人相比，我们设计出来的 UI 也是天上地下，我技不如人，就没必要多此一举了，哈哈哈。
如上所述，既然 IM UI 的需求也如此多变，其实 Turms 这类项目更应该让其生态来做，但大公司有号召力能主导开源圈，为其做贡献，Turms 可没有什么生态，哈哈哈。要么自研 UI ，要么基于第三方自研吧。

PS：Turms 项目里带 UI 的只有一个 turms-admin Web 管理系统，用来做后台管理的。

@qq316107934 平心而论，确实完成度挺高的，毕竟我默默勤快地做了快 3 年，我自己也盼 v1.0 也盼了 3 年，但真不“敢”发，毕竟还有一些很重要+细节的优化空间。当然，其实使用者可以规避点这些点，只是我个人不搞定这些问题，不愿意发。反正也没人给我发工资，催我 N 季度不发，就给个 Z 绩效，我要做的只是：一直写下去。

关于“全部开源，免费使用所有功能，并且没有任何引流和收费”，首先这是事实，没有任何引流+收费是因为：
1. 我偶尔 diss 部分国人半开源、面向 KPI 开源、开源没创造力（都电商、博客等），一个 gayhub 中文流量榜单基本都是面向个人的小玩具 /资料，“吹”国外开源才是真开源。因此如果我只 diss 别人，自己却不搞个开源，说不过去，哈哈哈哈。（ PS：当然，国内还有很不错的个人发展来的开源项目，如 ant-design-vue 、openresty 等等）

2. 我开源的态度一些人不一样，我最开始写开源就跟一些人打游戏、打篮球一样，我初中开始写代码，写有意思的代码，我就很爽（我高中的时候还写了一个很有创意的马里奥表白游戏，哈哈哈，这是题外话了）。但这只是初衷，在我学了乐器和接受美学学习的时候，我发现我可以借由“开源”这一手段培养我对诸如“自我意识与世俗欲望”的思考，并借由开源本心与世俗欲望这一具体感受，此我更加思考诸如“人活着为什么，人因什么而快乐与幸福”等必须经过自我审视的人生议题，当然也包括培养一些比较显式的能力，如“专注力”、“学会闲暇”，又或者是陪我度过一个又一个漫漫长夜。因此其实这个角度来说，我个人还挺感谢“开源”行为本身的，如果在这过程中别人能从中受益，那又何乐不为。

我试图超越一些世俗的规约，诸如不要动不动就是为了搞钱（不是说搞钱不好，我也像搞钱。但毕竟不能主客颠倒，人得控制钱，而不是钱控制人），因为一些规约并不是我本心，害怕被蒙蔽了双眼而被环境所利用，如果被利用了，人可就活得憋屈，不自在了。尤其是现在资本家与社会意识占据着媒体的话语权，更是要吾日三省吾身。

同样，我认为一些真心喜欢开源的朋友也要有意识地要避免让一些世俗的想法“伪装”成了自己的想法，而忘却自己的初衷，这样的忘却是丢失“自我”，而变成一个木头人，同时也可以借由开源这一体验，思考自我与世俗之间的距离，想清楚点，活得自在些。这是一个很大的话题，也是比较个人的问题，有兴趣可以看看一些我关于人生的思考，哈哈哈：

1. https://github.com/turms-im/turms/issues/862
2. https://github.com/JamesChenX/introspection

@teem 接着补充一点，比较重要的。除非是很有技术含量+细致的技术实现（如 jctools 的并发数据结构、Netty 的网络实现与内存管理），就是其实自研不管是代码效率上（我们只要定制功能），还是学习难度上都比一般的抽象库优秀，用 TIO 不如直接用 Netty 。在 https://turms-im.github.io/docs/intro/redevelopment.html#%E5%85%B3%E4%BA%8E%E4%BE%9D%E8%B5%96%E5%BA%93%E7%9A%84%E4%BD%BF%E7%94%A8 文章里，我有做具体的论述。
很多抽象库干的只是体力活，这点相信很多程序员都有感觉：面对一个需求，我们的脑力其实更多的是花在我们“有没有必要实现这个功能”，真写代码的时候基本可以不过脑子（就像我现在打字一样，不用准备什么资料、看什么文档。只要手放键盘上，就是一把劲地敲）

@teem TIO 这类项目就是项目就是我常说的“做了 IM 系统的 X%功能”就敢自称“系统”了（ PS：没别的意思，我本人很 peace ，这只是就事论事）。
我就随便举几个非常直观的问题：
1. 它如何做限流防刷机制的、有无全局黑名单机制，如何实现增量拉取，实现是否高效？（ Turms 对应的文档： https://v2ex.com/t/823554#reply6 ）
2. 如何做可观察性体系建设，日志 /度量 /链路追踪都如何设计的？还是裸奔？（ Turms 文档： https://turms-im.github.io/docs/for-developers/observability.html#%E5%BA%A6%E9%87%8F ）
3. 集群是如何设计的？ RPC 是如何实现的？（ Turms 文档： https://turms-im.github.io/docs/for-developers/cluster.html#%E7%BA%AF%E8%87%AA%E7%A0%94%E7%9A%84%E5%8E%9F%E5%9B%A0 ）
4. 数据库是如何做数据冷热分离的？（ Turms 文档： https://turms-im.github.io/docs/for-developers/schema.html#%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90%E4%B8%8E%E9%9B%86%E5%90%88%E7%BB%93%E6%9E%84%E8%AE%BE%E8%AE%A1 ）
5. 如何做敏感词过滤的？（ Turms 文档： https://turms-im.github.io/docs/for-developers/anti-spam.html ）。
特别一提，目前为止，全球开源圈内，所有编程语言，没有比 Turms 更优秀的敏感词过滤实现
6. 文档全不全、细不细致。很多 IM 项目不敢写文档，一是能力不够，一些就露馅，二是怕被同行抄。我敢写，一是因为我有绝对实力在，其他 IM 开源项目要水平比我还高，那我真是求之不得，我也想学习下大佬的经验，可惜开源 IM 圈里没有这类项目。

另外，跟我比实际项目的性能优化，它们就还太嫩了。这个 Turms 文档里详细说明 Turms 的各个模块是如何做到极致的性能的。举个最近一个月的例子，Turms 使用自研 Logging 框架，直接将 Java 基础数据写入 DirectByteBuffer ，并直接 Flush 进文件描述符，除非竞品切语言跟我 PK ，在 Java 这圈子没有比我这更快的了。非常多 Java 知名依赖（如 Spring 、Log4j2 ）用内存都是放飞自我，你如果看过它们对内存的使用，那真叫一个触目惊心。也因此 Turms 很多模块都是自研的。

PS：我看代码比我看中文流利，如果有自信的 IM 项目敢直接贴源码，我也可以帮忙 review 下。

@oott123 Turms 有对比过各种主流的 IM 解决方案，还算比较详细的，具体见 https://turms-im.github.io/docs/#%E4%BA%A7%E5%93%81%E5%AF%B9%E6%AF%94
。
Tinode 的定位其实和 Rocket Chat 差不多，用 Tinode ，不如考虑 Rocket Chat 。

我这里就在我文档的基础上，总结+补充几个比较重要的点：
1. Tinode 与 Rocket Chat 这类都是很常见的、定位为企业内部通讯的 IM 项目，强调开箱即用，功能五花八门（如音视频会议、文件传输）。而什么功能都支持就必定意味着它必然不高效。我在下面这个文档里论述了为什么“IM 功能丰富是致命的陷阱”，不累述了：
https://turms-im.github.io/docs/for-developers/schema.html#%E5%8A%9F%E8%83%BD%E4%B8%B0%E5%AF%8C%E7%9A%84%E8%87%B4%E5%91%BD%E4%BB%A3%E4%BB%B7
另外，Tinode 适用的用户规模从它文档的第一段就能看出来了：“Persistent storage is any one of RethinkDB, MySQL or MongoDB”。要知道数据库模型决定了上层能高效支持什么业务。Turms 服务端针对数据库做了太多的设计。诸如：Turms 的雪花 ID 算法，并不是常规的雪花 ID ，而是类似于倒序的雪花 ID ，以最终实现数据库自身的负载均衡。如果像 Tinode 这样玩花，啥技术都支持，那就说明它只做了一些最浅显的功能，没做什么优化。这些东西你在其他文章中基本学不到的，都是到实践才会发现的。

2. Turms 的定位和它们很不同，这个就看上面的文档，不累述了。

3. IM 细节大多，如果一个开源 IM 项目不写它的系统是怎么设计的，我基本就不会往里边看了，因为不同业务场景的 IM 系统设计千差万别。不写 IM 系统的设计文档，如同在简历上不写应聘岗位，不写技术栈，全靠面试官猜。细节包括如：系统读扩散、写扩散，有没有做消息 100%必达，如何做的？数据库如何做冷热分离？等等