[NEWS] AssertJ 3.6.X – Interview with Joel Costigliola – [新闻] AssertJ 3.6.X – 采访Joel Costigliola

最后修改: 2017年 3月 13日

中文/混合/英文(键盘快捷键:t)

1. Introduction

1.介绍

AssertJ is a library that provides fluent assertions for Java. You can read more about it here and here.

AssertJ是一个为Java提供流畅断言的库。你可以在这里这里阅读更多关于它的信息。

Recently, the 3.6.0 version was released along with two small bug-fix releases 3.6.1 and 3.6.2.

最近,3.6.0版本与两个小的错误修复版本3.6.1和3.6.2一起被发布。

Today, Joel Costigliola – the creator of the library – is with us and will tell you a little bit more about the release and future plans.

今天,Joel Costigliola–该库的创建者–和我们在一起,将告诉你更多关于该版本和未来计划的信息。

“We are trying to make AssertJ really community-oriented”

“我们正在努力使AssertJ真正面向社区”

2. Versions 2.6.0 and 3.6.0 Were Released Pretty Much at the Same Time. What Is the Difference Between Them?

2.2.6.0和3.6.0版本几乎是在同一时间发布的 它们之间的区别是什么?

2.x versions target Java 7 while 3.x target Java 8. Another way of seeing this is that 3.x = 2.x + Java 8 specific features.

3. What Are the Most Notable Changes/Additions That Appeared in 3.6.0/2.6.0?

3.在3.6.0/2.6.0中出现的最显著的变化/补充是什么?

2.6.0 ended up having different small features but no big additions. If I had to choose, the most interesting ones would be those related to suppresed exceptions:
hasSuppresedException()
hasNoSuppresedExceptions()

2.6.0最终有不同的小功能,但没有大的增加。如果让我选择,最有趣的应该是那些与suppresed异常有关的:
hasSuppresedException()

hasNoSuppresedExceptions()

3.6.0 additionally got a way of checking multiples assertions on array/iterable/map entry elements:

4. Since the Release of 3.6.0, Two Bugfix Releases Appeared (3.6.1, 3.6.2). Can You Tell Us a Little Bit More What Happened There and What Needed to Be Fixed?

4.自3.6.0发布以来,出现了两个错误修复版本(3.6.1和3.6.2) 你能告诉我们更多发生的事情和需要修复的内容吗?

In 3.6.1, filteredOn(Predicate) was only working with List but not Iterable, pretty bad.

在3.6.1中,filteredOn(Predicate)只对List有效,而不是Iterable,相当糟糕。

In 3.6.2, we did not think of extracting properties from Java 8 default getter method, it turns out it did not work out of the box after some internal refactoring.

在3.6.2中,我们没有想到从Java 8默认的getter方法中提取属性,事实证明,经过一些内部重构后,它并没有开箱即用。

I asked users whether they could wait for the next release, the bug reporter told me he was ok to wait but another user wanted it so I released a new version. We are trying to make AssertJ really community-oriented, since cutting a release is cheap (well except the documentation part) I usually don’t see any problem releasing.

我问过用户是否可以等待下一个版本,错误报告者告诉我他可以等待,但另一个用户想要,所以我发布了一个新版本。我们正在努力使AssertJ真正面向社区,因为削减一个版本很便宜(好吧,除了文档部分),我通常认为发布没有任何问题。

5. Did You Encounter Any Interesting Technical Challenges When Working on the Newest Release?

5.在制作最新版本时,您是否遇到了任何有趣的技术挑战?

I will point a problem I have encountered working on the next release 3.7.0 that should be out in few weeks.

我将指出我在下一个3.7.0版本工作中遇到的一个问题,该版本将在几周内推出。

Java 8 is picky about “ambiguous” method signatures. We added a new assertThat method that takes a ThrowingCallable (a simple class that is a Callable throwing an exception), it turned out that Java 8 confuses it with another assertThat method that takes an Iterable!

Java 8对 “模糊的 “方法签名很挑剔。我们添加了一个新的 assertThat 方法,它需要一个 ThrowingCallable(一个简单的类,它是一个抛出异常的 Callable),结果发现 Java 8 把它和另一个需要一个 Iterable!assertThat 方法混淆了。

That was the most surprising to me as I don’t see any ambiguity between the two.

这是最令我惊讶的,因为我没有看到这两者之间有任何模糊不清的地方。

6. Are You Planning Any New Major Release Soon? Anything That Will Utilize Java 9 Additions?

6.你们是否计划在近期发布新的主要版本?任何将利用Java 9增加的内容吗?

In the next weeks / one month. We usually try to have releases every few months or when there are major additions.

在未来几周/一个月内。我们通常尝试每隔几个月或有重大补充时发布一次。

Pascal Schumacher that has joined the AssertJ team has done some work on Java 9 to check compatibility, a few things don’t work, mainly the ones that rely on introspection since Java 9 changes the access rules. What we will do is start a 4.x branch that will be Java 9 focused, following the same strategy as 3.x vs 2.x, we will have 4.x = 3.x + Java 9 features.

加入AssertJ团队的Pascal Schumacher已经在Java 9上做了一些工作,以检查兼容性,有一些东西不工作了,主要是那些依赖于自省的东西,因为Java 9改变了访问规则。我们要做的是启动一个专注于Java 9的4.x分支,遵循3.x与2.x的相同策略,我们将有4.x=3.x+Java 9的功能。

Once 4.0 is officially released we will likely drop 2.x active development but keep accepting PRs as we do not have the capacity of maintaining 3 versions in sync, I mean by that we report any changes from n.x version to the n+1.x version, so adding something in 2.x would need to reported both in 3.x and 4.x and that is too much work at the moment.

一旦4.0正式发布,我们可能会放弃2.x的积极开发,但继续接受PR,因为我们没有能力维持3个版本的同步,我的意思是,我们将n.x版本的任何变化报告给n+1.x版本,所以在2.x中添加的东西将需要在3.x和4.x中报告,这在目前是太多工作。