Issues/2914 private lifecycle methods should cause exception

[mmerdes]

Overview

private lifecycle methods now cause an exception similar to the behavior for static methods.

(Not yet completely sure how to precisely define 'our' meaning of overridden/shadowed in this context.)

---

I hereby agree to the terms of the JUnit Contributor License Agreement.

---

Definition of Done

• There are no TODOs left in the code
• Method preconditions are checked and documented in the method's Javadoc
• Coding conventions (e.g. for logging) have been followed
• Change is covered by automated tests including corner cases, errors, and exception handling
• Public API has Javadoc and @API annotations
• Change is documented in the User Guide and Release Notes
• All continuous integration builds pass

[sbrannen]

private lifecycle methods now cause an exception similar to the behavior for static methods.

Implementation and tests look good.

(Not yet completely sure how to precisely define 'our' meaning of overridden/shadowed in this context.)

I'll ponder it a bit and get back to you if I come up with something.

[sbrannen]

(Not yet completely sure how to precisely define 'our' meaning of overridden/shadowed in this context.)

Using a thesaurus I came up with the following candidates.

• camouflaged
• cloaked
• obscured
• superseded
• suppressed
• "given precedence"

[mmerdes]

(Not yet completely sure how to precisely define 'our' meaning of overridden/shadowed in this context.)

Using a thesaurus I came up with the following candidates.

• camouflaged
• cloaked
• obscured
• superseded
• suppressed
• "given precedence"

Personally, I would prefer 'superseded'. To me, it conveys best what is going on without using the s-word.
Any other opinions?

[sbrannen]

Using a thesaurus I came up with the following candidates.

• camouflaged
• cloaked
• obscured
• superseded
• suppressed
• "given precedence"

Personally, I would prefer 'superseded'. To me, it conveys best what is going on without using the s-word. Any other opinions?

I think 'superseded' is a good choice.

[sbrannen]

Please update the PR to enforce that @BeforeAll and @AfterAll lifecycle methods are not allowed to be private as well.

[sbrannen]

I raised a question about superseded interface methods.

[sbrannen]

The changes look good!

All that's left is the following bullet point.

• Change is documented in the User Guide and Release Notes

[mmerdes]

The changes look good!

All that's left is the following bullet point.

• Change is documented in the User Guide and Release Notes

Yes, should be included in the release notes.
Not so sure about the user guide - after all it is a bug fix and the behaviour is now true to the one specified in the user guide...

[sbrannen]

Yes, should be included in the release notes.

I apologize for prematurely removing the "breaking changes" section for Jupiter in the 5.9 RC1 release notes, but that's where I'd put the note.

That's what we've done in the past, along the lines of "Fixed bug XYZ, though this is potentially a breaking change for some users in that the build will now fail..."

Not so sure about the user guide - after all it is a bug fix and the behaviour is now true to the one specified in the user guide...

I meant more along the lines of updating the wording currently in use.

For example, for @BeforeEach we currently state:

Such methods are inherited unless they are overridden.

Specifically, we need to update the following sections.

• https://junit.org/junit5/docs/snapshot/user-guide/#writing-tests-annotations
• https://junit.org/junit5/docs/snapshot/user-guide/#extensions-execution-order-wrapping-behavior