@noble4cc 因为不管是 tomcat 还是 Jetty 都不是单纯的 servlet 容器，它上面有一大堆网站服务器带有的管理类功能，这就导致这类服务器有一个巨大的弱点：启动缓慢。实际上 spring boot 之前的时代开发 web 程序是很明显的，你用 tomcat 来做测试，启动一次几十秒甚至分把钟，Spring Boot 打包的那个，不是完整的 Tomcat，而是嵌入版的 Tomcat，精简了很多东西，带来的效果就是启动快的多——另外实际上 Spring Boot 自带三种嵌入式 servlet 容器，我们现在一般用的是 undertow，这个脱胎于 JBOSS 的 servlet 容器是目前性能最好的。
最后，Java Web 界其实一直都有一股暗流希望彻底摆脱 servlet，有不少去掉 servlet 的 web 框架，比如 Spring webflux，vert.x。这类框架是直接构建在长连接库如 Netty 上的 Web 框架。Servlet 是一个产生很久的标准了。即使进行过 3 次大的升级，以现在的眼光看，实现的不太好，很多地方太重了

就我所知目前互联网公司都是去容器化，有了 spring boot 后直接用 jar 启动内嵌的 servlet 容器，还继续用独立的 tomcat 或 jetty 的很少了

Oracle 本质上其实就是个比微软还保守的企业，Java 自从 Sun 倒闭后，进步也是泛善可陈。完全是靠开源生态圈成就了 Java 本身，也许 Oracle 已经被这种情况冲昏了头脑，真以为是收割的时候到了，改 jdk 许可证就让人极度不舒服。本身这世界就是要靠竞争的，我想微软一定很高兴看到 Oracle 如此作死

*.kotlin 对 java 的增益，没有利害到 Typescript 对 javascript 的增益那种地步。java 这语言只是在语法上比较笨，明显的，无法接受的弱点很少，历史早就证明普通的语法糖是不足以使用户迁移的
*.在开发上，kotlin 始终只是 IDEA 在推，它家的 IDE 对 kotlin 支持的最好，eclipse 对 kotlin 的支持始终很糟糕，这严重限制了 kotlin 的扩张
*.kotlin 号称 100%兼容 java，但是事实情况是 kotlin 调 java 可以，但是 java 调 kotlin 是存在很多问题的。这个限制导致 kotlin 最合适的位置是新项目业务线的上层，调用 java 的接口，因为大量的 java 祖传代码的存在，你若使用 kotlin 来写类库给别人提供接口就要考虑兼容问题，这限制了 kotlin 的生态圈扩张

@pkxutao 落后时代的东西，和历史的车轮对抗的都没啥好下场的，就算你要支持老旧浏览器也有别的办法可以选

Linux 的桌面都是八斤八两。之前说过，不具备工业使用环境下的条件

@jinliming2 所以我才说，山中无老虎，猴子称霸王啊。我用来对比的不是 vscode，而是 visual studio，但是 visual studio 不像 IDEA 有那么多系列支持那么多语言。

@Tomotoes CSS 不是难，它的思维方式不是逻辑方式，而是查表方式，需要背组合，这也是为啥很多后端程序员面对前端无所适从的原因。后端程序说对前端搞不定，其实就是死在对 CSS 的理解上，CSS 不能作为“编程语言”去思考

@dacapoday JB 系列纯粹是山中无老虎，猴子称大王，又笨又重的 IDE

@qilishasha 迟早的，移动端 App 说白了大部分还不是在写 UI，不过是搭上移动端高速发展的东风。说到底，搞 UI 的都怕时代变，谁还记得塞班啊

一看这些回答就是知道大部分是互联网程序员，写客户端的现在在行业软件和工业领域活的挺好的，但是大部分没有互联网程序员薪水高，相对的嘛，身体健康情况是要好很多的，劳动强度没那么大

@TommyLemon 我之前就看到你这个东西了，其实我很看好你的思想，但是，我得说，为啥你就不愿意专注做成一个 ORM 工具+DSL 呢，你非要从控制层一路吃到数据层，对业务的侵入太重了，其实介于原生 SQL 和重度 ORM 之间的中等程度 ORM 工具+领域设计语言在所有语言里都是重要需求。如果你能从 API 层退出来，回到数据层里去我，想用上你这个工具的人会多很多的。比如我很想用你的数据层，但是我一看连 controller 层都侵入了我就没法用了

@huijiewei 你没有消除 Join 好吗，你实际是让 ORM 做了 Join 的工作，如果 Join 不复杂，ORM hold 的住，看上去这个工作就被屏蔽了，程序员不需要管。问题是有的时候 join 很复杂，ORM 根本 hold 不住，这就是为啥国内提到 hibernate 这种重 ORM 总会说它是容易入门精通困难，复杂查询性能下降的可怕

@qiyuey OLTP 一般不会需要 JOIN，OLAP 才是 JOIN 的大头

@no1xsyzy 欢迎去见识一下国内的金融报表，你与其说糟糕的表设计，不如说需求方怎么就会有那么多奇葩的脑洞，搞出那么多奇葩的查询条件来

@huijiewei ORM 那是自己实现的 Join 的算法啊，你以为 Join 的逻辑消失了吗？连 google 都有业务不得不用 MySQL 的 Join，很多不用关系数据库 Join 的分析系统，自己实现了连接引擎。你们真觉得基于关系代数的的 Join 这么容易打发啊。你不用数据库的就麻烦你自己实现一套
我这么说，谁能彻底驱逐关系代数中的 Join，谁立马就能拿图领奖

@CUMTProgrammer 人家就是叫你在代码里实现 MySQL 的连接器引擎，明白不，人家认为是个人都能写出和 MySQL 不相上下的连接算法来。哈哈哈哈

阿里的那个开发规范是有前提的（这个前提阿里自己是不会说的，本来就是给自己的企业培养预备军），这个前提就是“阿里有另外的 OLAP （联机分析事务）解决方案”，人家大数据强的很，不需要用关系数据库（阿里的主力 MySQL ）来做分析业务，Join 之所以有时候必须存在就是因为大量的中小型企业要依赖关系数据库来做 OLAP 业务，这个时候 Join 是必不可少的，甚至有时候是没办法的。1 楼说查询后合并？嗯，说的倒是没错，不过说到底就是自己做 join，自己做 join 的话，简单的业务无所谓，复杂一点的业务，多连几张表，在来点排序，统计什么的。此时你自己实际是在实现关系数据库的连接引擎！ MySQL 的连接引擎写的是不咋地，远远的不如 Oracle 这样的商业数据库性能高，不过我觉得把大部分连自己动手实现过数据库的一部分功能的程序员按在地上摩擦还是轻松愉快的。所以，你真要统计复杂业务？你还是老老实实 join 吧。
多说一句，要相信阿里总结的规范的科学性，但是不要迷信阿里当成圣经，技术都是有场景的，你不到人家的规模，盲目照搬人家的东西，是要吃瘪的。人家有些东西（大数据处理解决方案）你是没有的。你要面对的需求（没钱没人条件下用关系数据库解决分析需求）也未必是别人需要面对的