-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Consistently use class literals for primitive types
To improve consistency and avoid confusion regarding primitive types and their wrapper types, this commit ensures that we always use class literals for primitive types. For example, instead of using the `Void.TYPE` constant, we now consistently use `void.class`.
- Loading branch information
Showing
7 changed files
with
26 additions
and
21 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
10a5879
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately this breaks backward compatibility. I.e. platform-1.11.0-M1 is no longer compatable with jupiter-5.10.2
I have a suite of regression tests to monitor modifications on junit-platform ...
mvn test -P jupiter_5.10.2 -P platform_latest
... where
platform_latest
has reached 1.11.0-M1. Now the test-suite is broken:It would be great help if we let
ReflectionUtils#returnsVoid(...)
hang around as@Deprecated
for a few more minor releases. Otherwise my test suite would also need to struggle with Jupiter milestone regressions (such as issue 3797) and the benefit of JUnit-5 modularization is diminished.10a5879
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kaipe
ReflectionUtils
is an internal class so we don't consider this a breaking change. Are you callingReflectionUtils#returnsVoid(...)
directly?10a5879
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We dont call it all. My concern is
junit-platform
backward compatibility withjunit-jupiter-engine
.I.e. version 1.11.0-M1 of junit-platform does not support
junit-jupiter-engine-5.10.2
, which is the most recent stable edition of junit-jupiter-engine.Partly because of issue 3797 I was hoping to try most recent junit-platform without upgrading junit-jupiter-engine.
10a5879
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was under impression that
junit-platform
shares its lifecycle with other components, likejunit-jupiter-engine
. Thus the version ofplatform
should match the one ofengine
. So for the most recent stable engine:5.10.2 it would be to stay at platform:1.10.2.10a5879
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, those versions should always be aligned, e.g. by importing the JUnit BOM.
10a5879
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. I'm aware of the shared lifecycle but I have thought it concerns development and release. With JUnit-Platform on release-numbers 1.x and JUnit-Jupiter on 5.x I have previously thought of JUnit-Jupiter as one engine implementation among many - and that JUnit-Platform would maintain backward compatibility with all engines. It's with some surprise I now realize this maintained backward compatibility is limited to 3rd-party engines, whereas Jupiter (and Vintage?) utilize some platform internals that are frequently modified.
But what you say is indeed documented in the user guide and my original practical concerns are no longer valid after the quick fix for issue 3797. I will now reconfigure my regression test suites to make sure they no longer will have separate properties
version.platform
andversion.jupiter
- and instead rely on that JUnit BOM.Thanks for your help!
10a5879
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Backwards compatibility is maintained for third-party engines as well but only for non-internal APIs such as
ReflectionSupport
, not internal ones such asReflectionUtils
.