InfoQ 2024 年 Java 趋势报告

[fuhanfeng]

《 InfoQ 2024 年 Java 趋势报告》

其中提到，根据 New Relic 2024 年 Java 生态系统现状的数据，Java 17-11-8 的比例分别为 35-33-29%

公司还是 Java 8 为主，想整体切到 Java 11 都费劲，想升级 Java 17 估计只能等到技术栈切到 Spring Boot 3 了。

里面提到的一些 Java 生态的技术: GraalVM 、Quarkus 很少见到有国内公司用。

让我想起了前几天的帖子：《国内的 Java 体系真的很落后吗？》

经济上行的时候，想用新的版本和技术都很困难，现在这个大环境估计就更难了。

[murmur]

那个帖子喷 mybatis / mybatis plus 简直莫名其妙甚至没脑子

2024/2025 都 AI 年代了，代码都可以写，为啥 SQL 不能 AI 帮写，而且现在大框架 CURD 都是代码生成器做出来的，根本不需要手写 SQL

反过来对于企业开发动不动几十行 SQL 起步的复杂查询，mybatis 里贴进去就完了

我用过的一个最复杂的 OA ，光选人逻辑就十几种，数了一下流程引擎 200 个表，这东西每次 redis 要查至少几次缓存，sql 部分传统 ORM 咋配出来

[sagaxu]

国外 Java 份额被 C#和 Kotlin 蚕食不少，C#跟 Java 已经接近 1:1 了。

尽管比国内多一些，国外 JVM 生态中，GraalVM 和 Quarkus/Vertx 其实也算小众。

11-21 兼容性非常高，11 能跑的项目，换 17 或者 21 都不用重新编译，但除了馋 zgc ，更新收益并不大。11 之后比较有吸引力的版本是 25 ，分代 zgc + 兼容 synchronized 的 loom + 紧凑对象头。

[sagaxu]

@murmur 传统 ORM 不等于 完全不写 SQL 。在传统行业很多项目用 hibernate ，也经常有那种 200 行以上的大号 SQL ，由业务专家写好，交给开发集成进去，开发看不懂 SQL ，业务专家不懂 mybatis 或者 orm ，只约定好入参和查询结果，逻辑都在存储过程中。

业务专家写的存储过程，只能说太强大了，竟然能发送 HTTP 请求或者访问 redis 。

[murmur]

@sagaxu 存储过程有个问题是他在迁库（开源-国产，国产-国产）的时候容易出大问题，而且对于草台班子每次发布容易把这部分丢了

所以写到代码里的 SQL 更保险一些

[Gress]

坐等满血版的虚拟线程

[flowerains]

java8 从我入行到现在多少年了，回到老县城居然还是 java8 的项目一把梭

[ala2008]

给自己定个目标，今年升级 jdk 版本

[fuhanfeng]

@sagaxu #2 C# 国内早期用得还挺多的，很多大学课程还教这个，后来随着互联网兴起陆续转 Java 了。现在传统的医疗、金融领域用得还是蛮多的，就是人相当不好招。

[fuhanfeng]

@flowerains #6 Java 8 14 年 3 月发布的，目前来看主流用到 27 ～ 28 年都不成问题。

[fuhanfeng]

@murmur #1 mybatis xml 和代码分离我觉得项目分层上反而更清爽，也更容易定位。

[sagaxu]

@murmur 开源用 pgsql ，缺功能就写扩展，国产就让厂商写扩展，十几个人的分包小公司，redis 二开，inkscape ，二开都很平常，我还帮一家做过 influxdb 二开加点功能变成自主研发。

@fu82581983 《上海市卫生健康“信息技术应用创新”白皮书》将 C#/.NET 认定为“A 组件”——需要替换。马士兵说.net 封闭，是微软掌控，不知道是蠢还是坏。

@fu82581983 代码拼 SQL 也可以约定放指定目录，甚至单独打个 jar 包。