最近公司这边给了一个机会启动一个新项目，公司也没有什么技术很牛的人，之前的项目都是 java8 springcloud 阿里巴巴那套，在纠结正好拿这这个机会 试一下新的。
各位大佬，有什么建议吗？

干就完事了，不写 java 的路过

练练手，挺好的

没有什么技术很牛的人,可以理解为小公司吗,如果是小公司为啥要搞微服务? 我公司在这方面踩了大坑,说多了都是泪

没啥建议，用就是了，如果不是用了什么特别 hack 的手法，基本和你在 jdk8+spring boot 2.0 没啥区别

github 找个脚手架搭起来 干就完事了。。。

新项目直接 21 了

公司项目就别瞎折腾了，少加点班不好吗

直接 21 不好吗

至于上生产，我这上很久了，不过也就是普通服务集群，倒是没遇到什么和 jdk 或者 spring boot 相关的硬伤，主要也是因为 spring ai 系列要 3.0 以上，就直接上了

没区别啊，我们生产早就都是 java17+是 springboot3 了，做业务系统和 java8 没任何区别

想玩自己玩，公司项目稳定第一，为了尝鲜加班犯不上

就正常升级就行了，特殊特性一般也用不到（比如向量 API SIMD ），像虚拟线程你还得升级到 21, 21 的还有 bug ，24 中修复了，但是 24 不是 LTS
所以对于没有什么技术很牛的公司来说，改变只是将 javax 改成 Jakarta ，改改 GC 而已

确实是小公司，我们这个项目组产研测大概 15 个人左右，其实我了解玩这个项目是可以起一个单体项目就可以完成的。但是我是想这 趁这个机会学一下。

也是因为怕有点什么疑难杂症解决不了的。毕竟我还得弄网关，认证，等这些东西。

我想这一步一步来，先 17 在 21

我们公司是非常以业务为主的一个公司，说不好听的，我们技术就是他们业务人员的外包，就算不搞这些，领导也会给你分配其他的活，让你闲不下来，该加班还是加班

ai 相关必须 sb3+j17 。感觉没什么差异

落地不是随便搞搞？ 怕的是其他低阶依赖跟不上要重写。尤其是用了国内开源的

直接拿阿里巴巴的那一套就行了

直接上 21, jdk17 有点老了

啊？？？ jdk17 + springboot3 不是都生产落地几年了吗？ 现在都在观望 21 了

Spring 7 + spring boot 4 刚刚发布😂

jdk21 + springboot3 已经稳定用了一年了，基本没有什么坑

有啥区别吗？

我直接 kotlin + springcloud

直接 jdk21, 另外小公司不建议用 springcloud

可以玩玩 jdk21 + spingboot3 + graalvm

微服务其实不用局限在 springcloud ，不如先按模块开发业务，后续找瓶颈再扩展微服务，至于用不用 alibaba 全家桶就根据实际环境来了

没差+1 ，真要在 JVM 平台上尝鲜的不如 kotlin + JDK21 以上

同 jdk21 + springboot3 差不多一年了，记得好像就是升级后，copy 以前的代码，有些不兼容的问题

没啥区别啊，只有升级到 21 因为包名修改了稍微有兼容性问题

直接用 21 就行，没啥问题的

时间多就搞，时间少就不搞

看一下 blade x 这个脚手架，我司就是用这个，基于 17+boot 3 ，但是我司是商业版的，你看下社区版的是不是也是这个配置

小问题，干久了你就会发现，管他什么技术框架，就是干，逢山开路遇水搭桥，有问题解决就好了，多的是人已经踩过坑了

问题不大，我在 2023 年开始已经在公司内开发的时候推 jdk17 了，但是大概率推行过程中大部分人还是水用 jdk8 的写法，不过起码启动速度和一些相关优化肯定是要比 jdk8 好的，在开发过程中大部分场景其实用不到新特性。放手升吧，8 -> 17 相对来说还是很稳的。

17 升级 21 应该可以无缝升级,但是等业务上来了 说不定哪里回出问题,所以如果想用 21 建议直接 21
我们公司现在生产从 8 一路升级到了 21 升级还是有坑的

只要不转 native ，都是一样的用

直接 21

直接 servlet+jsp+sqlite

不用 springcloud 用啥啊

我们公司全部 java8 直接升 21 了，目前用着稳定落地了

有没有大佬有脚手架推荐

jdk 21 + spring boot 3 完全没有问题，但是建议不要直接使用微服务，先使用 spring modulish 把模块划分好，等需要的时候再使用微服务。

没啥问题 JDK17 唯一的坑就是 toList() 和 List.of() 等生成的类在序列化的时候会炸（ Dubbo3 ）

起新项目一点问题都没,抛开语法不说 17/21 下的 G1 还是比 java8 那个 GC 稳很多,语法上 list.stream().toList(),'''长字符串用起来还是很实在

21 的多线程模型比 8 强太多了, 综合提升 40%~70%, IO 密集型直接提升 3 倍

一样的，放心用

直接 21 吧。我们公司用 11/17 的都必须升级到 21. 反倒是用 8 的，多给了点时间，因为 8 升级 21 稍微麻烦丢丢

jdk21 springboot 虚拟线程稳定用了 1 年多了

21 + springboot 3 落地一年了，不建议用 alibaba 那一套，有重大配置变更更新日志和文档都没写，举个例子比如 nacos 新版本变更了配置文件的读取方式之前没看到有升级说明。

21 虚拟线程 有缺陷, 等 25 出了就可以升上去了

直接 24 ，等 9 月份出 25 了无缝衔接。而且真的确定是因为业务足够复杂需要上微服务吗。

jdk24 + springboot3 ,没有任何问题,还有就是建议把 idea 升级到最新版本,这样才能发挥最新 jdk 的威力,当然了目前最新版本的 jdk 对 jdk24 的支持并不完美,就比如 kotlin 编译选项里最高就只能选择 jdk23,不过新版本已经在路上了,理论上不超过 2 周就会推出针对 jdk24 优化过的版本

不是的，从业务复杂度来说，单体，微服务都行，用微服务就是为了多用点 cloud 其他组件，让自己在回顾学习一下，这两年净写业务了。

先搞一个单体项目干它😁

为啥不直接用 kotlin 呀,忽略 java 这种上古语言吧

＃38 我也纳闷呢，不用 springcloud 用啥，小公司不意味着业务也小

用新版本框架写新项目，你可能都感知不到跟旧版本的开发差异

虽然我自己也用 kotlin 也觉得好用爱用，但是公司项目得考虑招人的时候能不能找到吧，java 随便招

1. 为什么要用微服务？不要拿公司的项目练手，压力会很大，也不负责任。

2. vibe coding 的话，单体仓库上下文更友好。你也说了公司没啥技术氛围，可以让你有更多的时间搞点别的。

   水平不是很离谱，上手最多三五天就能用个差不多吧

   现在微服务不用 alibaba 那套，现在用啥？

   ＃48 现在都不用 alibaba 那套了吗，最新用啥

   为啥不直接 21 没啥区别注意虚拟线程+synchronize 有坑就行

   我们直接 21+spring boot3 ，但是也没支撑过什么大型服务，就和之前用法区别不大。顶多用个封装好的 webflux 、httpinterface

   kotlin+jdk21 都跑了两年了

   我们公司使用 21+spring boot3

   Java 本身版本随便升，没啥兼容性问题，可能一些 javax 的包挪走了手动依赖加回来就行
   SpringBoot 升级，主要就是 Security 组件和 Jakarta 的问题。
   然后没事别折腾 SpringCloud 了，时代变了，现在就算是做微服务也是从运维层解决问题。

   直接 21 ，ems-admin

   ems-admin

   java 新人表示，你说的那套 j8 ，我就压根没玩过。
   学的时候就是 j17 和 springboot3 。

   公司项目到现在依然是 JDK8 +2.2 。 不耽误赚钱。

   没啥区别，因为阿里云扫描 cve 漏洞，已经被摁着从 jdk8+spring boot2 迁移到 jdk17 + spring boot 3 上了

   都没啥技术的老旧项目，还不接触下新版本，你以后跳槽咋办

   我们直接干 24 虚拟线程去了

   不建议小项目上微服务，甚至中型项目也没必要上微服务，完全可以一套代码部署多个副本，通过 nginx 路由规则分流做业务，分布式事务是一个头疼的问题，市面上没有一个框架做得好的

   之前我们公司自己有个项目就用的我写的微服务框架 jdk24+spring boot3 ，自己写的每行代码都门清，比开源框架放心

   一步到位比较好，反正目前就 8 个非 8

   那是不是招人入职的时候就会说要求转语言？

   建议只有一个，不要让代码看上去还是 11 年前的样子就行

   ＃77 面试时肯定要提一嘴，使用 Kotlin 也帮助会筛选掉一部分人