@tctc4869 4.0 在 3.8 的时候就开始做了，3.9 是有一些小更改。基本都是 BUG 修复之类的。3.8 的一些变动基本上就是为了 4.0 做准备的。比如以前都是 Future 负责生产和消费。3.8 改了实现，新增了 Promise 负责生产、Future 负责消费。

4.0 的更新就比较多了，所有 API 都默认返回 Future，还有就是以前官方建议所有的第三方客户端，例如 Mysql 、HttpClient 、Redis 都是每个 Verticle 创建自己的。4.0 之后 Vert.x 将这些客户端在获取连接或者执行时都绑定在了一个 Context 上，所以可以多个 Verticle 去共享一个 Client 。 还有就是 Json 处理 Jackson 不在是强制的了，可以替换为任意一个 Json 实现。

这些是比较大的变化，其他的你可以参考 Vert.x 的 Break Change

https://github.com/vert-x3/wiki/wiki/4.0.0-Deprecations-and-breaking-changes

@tctc4869 是的，4.0 目前还没有正式发布。具体发布时间我也不太清楚。假如后面的项目要用 Vert.x 我还是建议直接使用 4.0 。因为 4.0 更改的东西蛮多的。之前有个朋友已经直接使用 4.0 第 4 个里程碑版本 在正式环境了。

另外再补充一下，Quarkus 也不错可以考虑考虑，就是用的人少点，这两个项目都算是红帽的。而且两个项目的核心开发者与 Graalvm 都交流挺密切的。另外 Vert.x 也利用 Graalvm 衍生出了 ES4X 这个项目。

另外如果真想 WebFlux 与 Vert.x 中做技术选型的话 我还是比较推荐 Vert.x 的

主要还是我觉得国内开发者参与 Vert.x 项目不少，因为前几届的谷歌夏令营项目 Vert.x 都有参与的。

而且好几个参与 Google 夏令营的国内开发者参与了 Vert.x 的一些子项目开发。

例如从去年开始出的 Vert.x-sql-client 就是国内的开发者开发的。

参与了 Vert.x 项目贡献的人也不少。虽然我也仅仅是修复了 Vert.x 的一些简单的 BUG 。

也就是说假如你使用 Vert.x 出了一些紧急问题，那么你提个 Issues，或者群里发一下问题，可能没多久就能解决掉

对于 Webflux 和 R2dbc 来说，我没太关注。不知道有没有国内的开发者贡献过代码所以出了问题很可能只能等官方解决。

@tctc4869 就是开发速度和阅读性，Vert.x 自带了 Promise/Future 。但是在 4.0 之前 所有 API 默认都是 callback 那一套。

自己为每个 API 封装个 Future 太蛋疼了，要么就只能选择 RxJava 。

4.0 之后，每个 API 都原生返回 Future 了，操作起来就比较方便。

用 Kotlin 的好处就是 Vert.x 的 Kt 包是封装了 API 了。每个异步操作都是 XXXAwait 。和写传统都代码区别不大了。

Future 和 Rxjava 那套对同事以及个人水平都是有要求的。很容易把代码组织成 shi 。。。

作为一个为 Vert.x 贡献过一点代码人。

在不考虑性能等情况下 WebFlux 和 Vert.x 都不要用

Webflux 表面看起来生态齐全，但是其大部分生态都是阻塞的客户端外面套一层壳。所以性能看起来与传统 SpringBoot 差别真心不大。

Vert.x 除非你比较强，或者说项目真的并发比较大，否则也是不太建议你使用 Vert.x

Vert.x 4 后所有的异步操作默认都返回了 Future 。所以开发也比较方便，另外就是你用 Kt 的话也会比较舒服。

相对于 Spring 家的来说，Vert.x 不是框架，而是工具。官方开发人员就那么多。维护每个中间件的 Client 已经比较累了

所以 Vert.x 的一些 Client 都很原始。并没有太多的精力在去开发框架。Vert.x 的官方人员只负责给你写一个基础协议通信的 Client 、想要更简单的开发还是需要自己写很多东西。

所以如果你的某些项目业务不复杂，而且并发高。那么用 Vert.x 是一个很好的选择

反之你的项目业务流程比较复杂，并发不高。大量的 CRUD 。我还是建议你使用传统的 SpringBoot 。开发速度更快。配套设施也齐全

再着回答一下第三条附言，要用异步驱动 jdbc 来访问数据库再能保持良好的性能么，不然性能会比传统阻塞式性能还差？

这里不得不说一下 Vert.x 下关于访问数据库的两个项目，一个是传统 JDBC 外套一个壳子的 Vertx-JDBC 。一个是完全异步的 SQL-Client 。 比传统阻塞性能还差是不存在的。只不过确实会因为传统的 JDBC 占用的大量的连接会导致吞吐量上不去。但是总体来说也是比 Springboot 强不少

另外，其实对于这种玩意来说，大吞吐量下必然情况是大多数访问打进来是打到缓存层的 Redis 啊之类的。这种就特别适合 Vert.x 。代码量少。性能高。不必纠结 SQL 问题。

你说的不考虑性能的情况下，完全操作就是基于传统数据库，那么这种比较原始的 SQL-Client 写起来是非常蛋疼的。

参与开源项目

用户数和 star 数没有任何意义......

都去参与开源了，直接翻 commit 记录 修改的内容不就好了.....

强制考核开源项目 项目只会变烂

我的 590 是换了一个 DP 线，同款显示器

官方其实不打算维护了....

貌似因为 dde 的各种依赖之类的原因....

我是 zulu 的 12 目前没有发现问题

看回答....没脑子的人还是挺多的

分不清 openjdk 与 oracle 其他的关系。

懂都不懂就开始黑 oracle....

您可真是个天才

有的人不是坏就是蠢

ebean

启动慢是 spring 全家桶启动慢....

maven gralde 之类的我觉得还是挺好的，gradle 也支持 kotlin 与 groovy

一些东西还是跑 unit test...好点。

如果没有 unit test 并且用的还是 spring 系的。。那么重启之类的就确实很蛋疼。。

https://www.nicetheme.cn/shangche/AzlkjEhdIE8

这个挺好的，就是贵了点

= =我是去的宝岛眼镜５０块验光

vert.x

可以，非常建议。
学 springboot 的过程就是在学 spring，难道非要去学 xml 配置写一大堆，还整 jar 包整 tomcat 之类的么
谁有那个闲心

央视。。。央视影音

我可以想到任何语言去转 Go 的,唯独看不懂 java 去转 go 的..
不太懂什么心态....
开源项目...除了 github 还能有啥?
docker kubernate hugo istio 不都是 go 的开源项目

github trending 里面 搜 go 出来的不都是 go 的...