Java 代码中如果显式的用 throw 关键字抛出异常，那么在该分支中其后的语句不可到达，并且即使对于有返回值的函数也不必写 return 语句了。像下面的代码
以上代码是合法的。要清洁代码的话，最后的 return num + 1 不必写在 else 条件中，这样写只是为了验证抛出异常后不必有返回值。
比如我们想对该代码进行重构，把 throw 语句抽取到一个方法中，以便于在该方法中集中处理错误信息，于是变成了 阅读全文 >>
不得不承认因为 ChatGPT 为代表的 AI 的出现，让许多技术博客的写作者积极性大大降低。但本着以学习掌握知识为目的，实战，写下来对加强学习仍然是非常有意义的。如果一直使用 AI 来解决技术问题，知识永远是 AI 的，至于说有了 AI 本应没有主动学习必要的性的话，永远保持像一张白纸，A4 大小，那真就无话可说了。
开发过程驱动有分 TDD(Test-Driven Development) 和 BDD(Behavior-Driven Development)，大致的理解是 TDD 更关注实现细节，BDD 更接近于 QA 的测试，对领域的测试。BDD 从抽象中来讲更适于做面向用户的集成测试。当然在 AI 生成代码的年代可能单玩测试反而不那么重要，因为更多是一次性代码。
BDD 给人最典型的印象是 Scenario/Given/When/Then, BDD 最流行的测试框架当属 Cucumber, 它以插件的方式支持众多编程语方，如官方支持的用 JavaScript, Java, Kotlin, Ruby, Lua, Scala, C++, Go, OCaml, 还有其他半官支持的 Python, Swift/ObjC, Perl, .NET(C#, F#, VB), 以及非官方支持的 Rust, D, Groovy 等。
另外还有一个专供 Java 的轻量级 JBehave, 不过个人更推荐用 Cucumber, 因为 Cucumber 得到更多 IDE 如 IntelliJ, Eclipse, VS Code 等的支持，并能与 JUnit 4, JUnit 5, TestNG, 以及 Spring Boot 项目集成，内置的测试报告插件，多语言当然是个亮点。
本文主要关注 Maven 项目中如何使用 Cucumber, 循序渐进的从简单的测试开始，然后跃进到与 JUnit 5/ JUnit 4 的结合，以及普通 Unit Test 和 BDD 测试如何并存且可区分的执行，或者在 Maven 中创建独立的 src/bdd 目录单独存放 BDD 测试用例。 阅读全文 >>
回看三年前的一篇日志 Mockito 3.4.0 开始可 Mock 静态方法，最后对 Mockito 产生的缺憾是它无法用来 Mock 非测试线程(主线程)中的静态方法调用。其实这也是可以变通的，下面慢慢道来。
首先回顾一下 Mockito 的静态方法 Mock 的使用方法，随着 Mockito 版本的升级，引入依赖的方式也发生了些许的变化，以 Maven 项目为例，如果在 JUnit 5 下用 Mockito 的 pom.xml 依赖中为
由它引入的全部相关依赖
在用 Python 写 Web 服务端代码时，用 base64.encodebytes() 函数对字符串进行编码，然后在 Java 端用 Base64.getDecoder().decode() 时无法解码，难道 base64 编码在两种语言间还有这等差异。Google 一下，得到的答案是在 Java 端要用 Base64.getMimeDecoder().decode() 函数解码。这一问题算是解决了, 不过后来又在 Python 写的 AWS Lambda 中输出
return {
"statusCode": 200,
"body": base64.encodebytes(b"short message"),
"isBase64Encoded": True
}
以 AWS Lambda functionURL 的方式来访问，对于 body 中的小字符串是没问题，一旦 body 够大时在 Postman 或 curl 命令中无法直接展示出来，用 curl --output a.out 存成本地文件，打开后看到的是带换行的格式
H4sIAAZi7GYC/+19WXfcOLLmX+HxwxzXOS6b2AhiprvnyFtZt7yoJbdr6r74UEpKyq5UpjoXL/fX
D8AlkysIkCFmpo2H7pJJEBkAAsCHQMQXf/t6HX/YrO83a++P168+xcvVdDH/+yP6lOGnzEciCNHn
gD7yTufT9evpLD6L1rd/f3Q6n03nsXexXk7nN4+8F4v59fRms4zW8uNtHdjH9KkfPEXoM6JPsf8U
......
ThreadLocal 是 Java 编程人员要掌握的一个基本类，似乎没什么太多要说。但因为本文要牵出 TransmittableThreadlLocal, 再顺带说下几乎隐形的 InheritableThreadLocal。
ThreadLocal 用于保存与线程绑定的数据，它在框架内部使用的很频繁，但凡见到 XxxContextHolder.currentContext() 之类的十之八九用到了 ThreadLocal, 如 Spring 框架中的
RequestContextHolder
看国内的一些项目时 Dubbo 这个词经常闪现，一直也不以为然，未作搜索，当然也不知道它是做什么用的。直到最近阅读关于大型网站架构相关的书中反复提到 Dubbo 后，觉得不能再对它视而不见。Google 了一下，它是在阿里巴巴创建贡献给了 Apache 的开源项目，在阿里巴巴的大型应用中久经考验过的。Dubbo 是什么呢？借用官方 Dubbo 介绍
Apache Dubbo 是一款 RPC 服务开发框架，用于解决微服务架构下的服务治理与通信问题，官方提供了 Java、Golang 等多语言 SDK 实现。使用 Dubbo 开发的微服务原生具备相互之间的远程地址发现与通信能力， 利用 Dubbo 提供的丰富服务治理特性，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。Dubbo 被设计为高度可扩展，用户可以方便的实现流量拦截、选址的各种定制逻辑。
Dubbo 是国内企业贡献的，所以官方有原生的中文文档，它某些时候与 Spring Cloud 齐名，又有些像 AWS 的 ECS Service Discovery, Service Connect 加上 ELB 的功能。 阅读全文 >>
我们通常用的 Java 缓存基本可认为是扩展了 HashMap 或 ConcurrentHashMap 的实现，它们各自实现自己的缓存策略，如时间与空间的控制，生命周期管理，是否支持分布式，溢出时能否转储到磁盘。关于 Java 本地缓存的存储分为内存与磁盘，内存多数情况下指的是堆内内存(on-heap), 而介于堆内内存与文件存储之间的就是堆外内存(off-heap)
我们查看一下当前 Spring 支持的缓存实现, Supported Cache Providers, 列有 Generic, JCache(JSR-107), EhCache 2.x, Hazelcast, Infinispan, Couchbase, Redis, Caffeine, Simple， 这其中无一支持堆外缓存，其中的 EhCache 要付费使用 EhCache 3(Big Memory) 才能支持 off-heap。 阅读全文 >>
我们在创建 Java 线程池，无论是用 Executors, ThreadPoolExecutor, 还是 Spring 的 ThreadPoolTaskExecutor, 如果不指定工作队列的大小的话，默认为 Integer.MAX_VALUE(2147483647), 基本不会把它爆满，但是在许多的任务要执行时大量 Runnable 对象的创建却足以把内存撑爆掉。所以才有必要使用一个有限大小的工作队列，如 5000, 再配上 RejectedExecutionHandler(DiscardOldestPolicy, DiscardPolicy, 或 CallerRunsPolicy)。前两种策略会主动放弃最旧最新的任务，一般不是我们想要的，CallerRunsPolicy 还能主动发挥任务提交者的计算能力，是一种不错的选择(只可能会发生工作队列太小且提交者执行的任务太忙时产生线程池一时的空闲。
所以总结起来我们可以有以下几种实现
在工作队列满时有效利用提交任务的线程，不让它闲着，这种实现最简单, 像下面那样声明线程池
使用 Java 处理 Object 与 XML 之间的转换时 JAXB(Java Architecture for XML Binding) 仍然被广泛使用。但随着 Java 9 模块化后把 JAXB 从标准 JDK 中移除后，和 Java EE 8(Jakarta EE 8) 到 Jakarta EE 9 的变迁时命名空间由 javax.* 变成了 jakarta.*，我们在使用 JAXB 时需作出相应的适配。
本文分别使用 Java 1.8, 17，通过 Maven 插件 jaxb2-maven-plugin 的 xjc (从 xsd 文件生成 Java 类), 和如何切换 jakarta.* 命名空间，由此可给我们对使用了 JAXB 的项目升级 JDK 时指明方向。从而不致于因不了解每部分组件的具体功效而在 pom.xml 中胡乱配置，比如之前对 jaxb2-maven-plugin 插件本身配置了多余的 org.glassfish.jaxb:jaxb-xjc 和 org.glassfish.jaxb:jaxb-runtime 依赖，也未能理解 jaxb2-maven-plugin 与 org.glassfish.jaxb:jaxb-runtime 之间的版本对应关系。
实验准备，创建简单的 Maven 项目，并在路径 src/main/xsd/ 下新建 Schema 文件 sample.xsd，内容为 阅读全文 >>
出现此错误的大致环境如下
后面会详细列出能重现此问题的 pom.xml 配置及 Java 代码
在执行
restTemplate.getForEntity("http://localhost:8080/test2", String.class)
时出现如下错误 阅读全文 >>
Notifications