Java 一路突突突， 版本 16 在 2021-03-16 都发布了, 而我们一直碍于 Java 9 的大改还在 Java 8 上原地踏步, 以往每当有新版本 JDK 发布后都是很快就验证，立马升级。Java SE versions history) 列出了所有 Java 的历史版本的发布日期。在今天(2021-05-04) 网站 Java SE Downloads 上直接提供下载的 Java SE 版本有以下三- Java SE 16.0.1
- Java SE 11.0.11(LTS)
- Java SE 8u291
两个 LTS(长期支持) 版 8 和 11，外加一个目前最新的非 LTS 版本 16, 其他的版本都被归档到了 Java Archive. 查看一下 Java 支持的 roadmap, 几个 LTS 版本的服务支持年限版本本 发布日 原定支持至 延期支持至
注意到 Java 8 将比 Java 11 和将来的 Java 17 生命力还顽强，一下就觉得这么久坚守在 Java 8 的阵地上不应觉得有什么好害羞的。眼看着下一个 LTS 版本的 Java 17 就要在今年 9 月份发布了，Java 11 看来是要错过了，等准备好和 Java 8 告别时要直接跳到 Java 17 了。 Read More
Java 8 2014/3 2022/3 2030/12
Java 11 2018/9 2023/9 2026/9
Java 17 2021/9 2026/9 2029/9
在上篇 使用 Java 转换 Apache Avro 为 Parquet 数据格式 实现把 Avro 数据转换为 Parquet 文件或内存字节数组，并支持 LogicalType。其中使用到了 hadoop-core 依赖，注意到它传递的依赖都非常老旧， 到官方 Maven 仓库一看才发现还不是一般的老
长时间无人问津的项目，那一定有它的替代品。对啦，据说 hadoop-core 在 2009 年 7 月份更名为 hadoop-common 了，没找到官方说明，只看到 StackOverflow 的
Differences between Hadoop-coomon, Hadoop-core and Hadoop-client? 是这么说的。 应该是这么个说法，不然为何 hadoop-core 一直停留在 1.2.1 的版本，
而且原来 hadoop-core 中的类在 hadoop-common 中可以找到，如类 org.apache.hadoop.fs.Path。不过在 hadoop-core-1.2.1 中的 fs/s3包不见， 这么重要的 s3 文件系统没了。 Read More
Java 单元测试最趁手的 Mock 组件当属 Mockito，虽然它最初是基于继承来实现 Mock 的，所以对私有方法，私有属性，静态方法， final 类，final 方法，构造函数无能为力。于是有时不得不引入 JMockit 或 PowerMockit 来辅助。不过现在的 Mockito 功力有所增强。
首先是 Mockito 2.1.0 开始可以 Mock final 类和 final 方法，要在 classpath 下创建个文件mockito-extensions/org.mockito.plugins.MockMaker, 内容为mock-maker-inline。 之前写过一篇介绍：Mockto 也能 Mock final 类和 final 方法了，其中也探索了它的实现细节，使用到了 ByteBuddy 修改字节码。
从 Mockito 3.4.0 通过类似的 mockto-extensions 扩展的方式，实现了对静态方法的 Mock。所有使用到的接口是 org.mockito.MockedStatic， 它当前在 Mockito 3.7.7 中还是一个试验性方法 @Incubating，能拿来用就行。 Read More- 使用 Mockito Mock 方法式，一直以为可以用
anyString(),any(Foo.class)等匹配null值，其实不行，null值必须显式的用null, 或eq(null)来匹配。anyString(),anyInt()等只能匹配非null值，查看它们的返回值实际是 "" 和 0 等, 而更为特别的是any(Foo.class)看到的是null, 仍然不能匹配null值。进一步用Mockito.mockingDetails(mock).printInvocations()打印出的内容，anyString(),any(Foo.class)都会显示为null值。
说的有点罗嗦，看下面的例子, 被测试类 UserDao，sql 和 sqlArguments 由各自的 setter 方法来控制，默认它们都为nullRead More - Java 多线程编程常用的一个接口是
ExecutorService, 其实就一个线程池的接口，一般由两种方式创建线程池，一为 Executors 的工厂方法，二则创建 ForkJoinPool 实例，当然也有直接使用 ThreadPoolExecutor 的。
关于什么时候用ForkJoinPool或普通的线程池(如 Executors.newFixedThreadPool(2) 或 new ThreadPoolExecutor(...)) 不过多的述说。如果要运用到 ForkJoinTask 的话就要用 ForkJoinPool, 它是 Java7 新引入的线程池类型。
关于 Java7 的 fork-join 框架可参考很多年前的一篇 Java 的 fork-join 框架实例备忘。ForkJoinPool 的一个典型特征是能够进行 Work stealing。它也是 Akka actor 效率高效的一个有力保证。
本文只能某一种情形下在选择普通线程池与 ForkJoinPool 的区别，直接说吧，普通线程更容易造成死锁，而 ForkJoinPool 却能应对相同的状况。 Read More 
承接近两年前的 用 PreparedStatement 向 SqlServer 中一次性插入多条记录，其文后用 User-Defined Type 可用下面简单的代码把 Java 本地内存中表格数据一股脑的刷入到 SQL Server 数据库表格中
String sql = "INSERT INTO Customers SELECT * FROM ?";
SQLServerPreparedStatement pstmt = (SQLServerPreparedStatement) conn.prepareStatement(sql);
SQLServerDataTable dataTable = ..... // 生成好的本地表格数据
pstmt.setStructured(1, "CustomersTableType", dataTable);
pstmt.execute();上面的 dataTable 本地表格类型变量容易生成，关键是必须在正式数据库数须预先用
CREATE TYPE创建好CustomersTableType这个用户自定义类型，这会受权限的约束。如果由 DBA 预先完全依照目标表来创建好这个用户自定义类型，又无法确定是否总是要操作该目标表的所有字段。数据库是允许我们创建临时的用户自定义类型 Read More
现实中有这样的用法，创建一批在线程池中运行的 CompletableFuture 实例，然后等待它们全部执行完再继续后面的操作。比如说 AWS 的 Lambda, 单单提交任务到线程池，不等待所有任务全部完成便退出主线程的话，AWS 便认为 Lambda 执行完毕，无视线程池中正在执行的任务而强行结束该 Lambda 实例。
以往我们通常的作法如下
1ExecutorService threadPool = Executors.newFixedThreadPool(10); 2List<CompletableFuture<Void>> futures = IntStream.rangeClosed(1, 10000) 3 .mapToObj(n -> 4 CompletableFuture.runAsync(() -> { 5 System.out.println("done " + n); 6 }, threadPool)).collect(toList()); 7 8futures.forEach(CompletableFuture::join); 9 10System.out.println("all done");如果所有的任务均无异常，上面的代码能得到预想的结果，只要上面打印出
all done的话真的就是表明所有的任务都完成了。但是在循环 joinfutures中的每一个 CompletableFuture 时，只要碰到任意一个任务有异常时，便立即抛出给外部线程，不在乎是否还有其他任务正在执行。此时，如果外部未予捕获，当然 Read More
在进行数据流处理过程中，需要一个高效苗条的流处理组件，比如对输入流能进行分组(窗口)，能进行流量控制(Back Pressure - 背压)，这也就涉及到响应式编程，流处理框架。这方面如果直接基于 Akka actor 来构建 Akka ActorSystem 也是比较复杂，依赖的组件也不少。还有构筑在 Akka actor 之上的 Akka Streams，再往上的 Flink Streaming，它们都有像滑动，滚动窗口的概念，但是依赖更不得了。一个基本的 Flink Streaming 的项目会依赖到 45 M 以上的第三方组件，如果用它来写一个数据流处理的共享组件，那真是要命。Spring 5 也开始带上了自己的 Reactive-Streams 实现 Spring Reactor, 想要把它从 Spring 中单独抽离出也非易事。Flink Streaming 组件依赖：org.apache.fling:flink-streaming-java_2.12:1.80, 会依赖于其他诸如 akka-stream, akka-actor, flink-core, flink-clients, scala-library 等非常多的东西
而另一个著名的响应式框架 RxJava 2 就清爽多了，完全没有第三方依赖，要说有也就是定义了四个接口的 reactive-streams(2 KB 大小)，就自身那个 rxjava-2.2.9.jar 包只有 2.3 M，这才叫轻量级。因为它设计来是能被应用于 Android 客户端应用的，Andriod 上的 rxandriod-1.2.1.aar 只有 9 K。所以 RxJava 2.x 太适合用来写一些小的共享组件了。 Read More
在我们对数据库 DAO 类进行单元测试时，通常不应该依赖于一个外部数据库，所以会选用特定比较接近于真实数据库类型的内存或嵌入式数据库，如 HSQLDB(HyperSQL), H2, Derby 等。但总难免会用到特定数据库的特性，这时候就无法用前述各种数据库进行测试了。非要单元测试中覆盖到所用的数据库特性的话可以选择用 docker，如 Testcontainers, 经过模块扩展，它可以由 docker 来启动许多种类型的数据库，MySQL, Postgres, Oracle-XE, MS SQL Server, Couchbase 等等，详情见 Database containers。刚了解到的是它的模块化的无限可能，像支持 Kafka Containers 和 Localstack Module 等。
这里就不走 Testcontainers 那条路 -- 要求构建服务器上也要有 docker。早先希望能找到一种嵌入式或内存 PostgreSQL 数据库，后来发现 PostgreSQL 未能提供 In-Process 和 In-Memory 的启动方式，好在 PostgreSQL 是开源，有人可以把它改造为小型的可由测试代码启停的本地数据库。有两个具有代表性的组件，分别是 OpenTable Embedded PostgreSQL Component 和 Embedded PostgreSQL Server，它们都号称是 Embedded，所谓嵌入式，其实是进测试进程外的数据库。
下面简单体验下两个组件的用法 Read More
