1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
|
## Summary of changes in version 4.13.2
# Rules
### [Pull request #1687:](https://github.com/junit-team/junit/pull/1687) Mark ThreadGroups created by FailOnTimeout as daemon groups
In JUnit 4.13 ([pull request #1517](https://github.com/junit-team/junit4/pull/1517)) an attempt was
made to fix leakage of the `ThreadGroup` instances created when a test is run with a timeout. That
change explicitly destroyed the `ThreadGroup` that was created for the time-limited test. Numerous
people reported problems that were caused by explicitly destroying the `ThreadGroup`.
In this change, the code was updated to call `ThreadGroup.setDaemon(true)` instead of destroying the
ThreadGroup.
### [Pull request $1691:](https://github.com/junit-team/junit/pull/1691) Only create ThreadGroups if FailOnTimeout.lookForStuckThread is true.
In JUnit 4.12 ([pull request #742](https://github.com/junit-team/junit4/pull/742)) the `Timeout`
Rule was updated to optionally display the stacktrace of the thread that appears to be stuck
(enabled on an opt-in basis by passing `true` to `Timeout.Builder.lookForStuckThread(boolean)`).
When that change was made, time-limited tests were changed to start the new thread in a new
`ThreadGroup`, even if the test did not call `lookForStuckThread()`. This subtle change in
behavior resulted in visible behavior changes to some tests (for example, tests of code that uses
`java.beans.ThreadGroupContext`).
In this change, the code is updated to only create a new `ThreadGroup` if the caller calls
`Timeout.Builder.lookForStuckThread(true)`. Tests with timeouts that do not make this call will
behave as they did in JUnit 4.11 (and more similar to tests that do not have a timeout). This
unfortunately could result in visible changes of tests written or updated since the 4.12
release. If this change adversely affects your tests, you can create the `Timeout` rule via the
builder and call `Timeout.Builder.lookForStuckThread(true)`.
# Exceptions
### [Pull request #1654:](https://github.com/junit-team/junit/pull/1654) Fix for issue #1192: NotSerializableException with AssumptionViolatedException
This change fixes an issue where `AssumptionViolatedException` instances could not be serialized
if they were created with a constructor that takes in an `org.hamcrest.Matcher` instance (these
constructors are used if you use one of the `assumeThat()` methods in `org.junit.Assume`).
|
