New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Drop Java 7 support #833

Merged

codecholeric merged 22 commits into TNG:main from marknp:drop-java7-support

May 5, 2022

Contributor

marknp commented Mar 12, 2022 •

edited by codecholeric

Loading

This will make Java 8 the minimum required Java version to run ArchUnit tests. We also refactored many internals to use Java 8 streams and lambdas instead of anonymous classes and replaced ArchUnit's own Function, Predicate, Optional and Supplier by the standard JDK ones. Furthermore, we upgraded most dependencies that were only hold back to be Java 7 compatible (like Guava and AssertJ).

Note that this is obviously a breaking change which will make ArchUnit unusable in Java 7 projects and will break all user code that depend on the mentioned ArchUnit types that were replaced by standard types. Thus, this change will only be released with version 1.0.0.

marknp force-pushed the drop-java7-support branch 6 times, most recently from 8f9d2eb to a90f39f Compare

March 18, 2022 16:39

codecholeric force-pushed the drop-java7-support branch 2 times, most recently from ff1d701 to 98f6286 Compare

April 9, 2022 10:48

codecholeric mentioned this pull request

Let @AnalyzeClasses default to scan the package of the annotated class #719

Closed

codecholeric changed the title ~~Drop java7 support~~ Drop Java 7 support

codecholeric force-pushed the drop-java7-support branch 2 times, most recently from 6e74bd5 to 5283d33 Compare

April 10, 2022 15:51

marknp added 2 commits

April 22, 2022 22:48


          remove JDK 7 tests from CI

7f9f862

Signed-off-by: Marion Knopp <marion.knopp@gmail.com>


          set minimum supported Java version to 1.8

7ac4fb0

Signed-off-by: Marion Knopp <marion.knopp@gmail.com>

codecholeric force-pushed the drop-java7-support branch 3 times, most recently from 60e293f to fb1d8d1 Compare

April 23, 2022 16:04

Contributor Author

marknp commented May 2, 2022

there are two commits to update mockito - should we not join this to one?

marknp commented

View reviewed changes

archunit/src/main/java/com/tngtech/archunit/core/domain/JavaClass.java Outdated Show resolved Hide resolved

Collaborator

codecholeric commented May 3, 2022

Oh, those two Mockito-commits are some artifact from rebasing 🙈 The former one should be squashed into the Guava-upgrade, because it has nothing to do with Mockito 😬 Good catch! 👍

codecholeric and others added 10 commits

May 3, 2022 14:02


          upgrade Guava to latest JRE version

3e3205c

We needed the Android version to be Java 7 compatible. Using a Java 8 compatible version now gives us some benefits (like a `Collector` for `Immutable{List/Set}`).
Note that some `@Nullable` annotation in Guava made it necessary to refactor some code a little, where Spotbugs now complained about possible nullability.

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>


          upgrade Log4J to latest version

19f0f2c

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>


          upgrade Mockito to latest version

6621da5

We could not use a newer major version because of being Java 7 compatible. Now we can upgrade to the latest version.

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>


          upgrade AssertJ{-Guava} to latest version

02e57f3

These dependencies were hold back by the necessity to be Java 7 compatible. Now that we do not need this anymore we can finally upgrade to the latest version.
Note that some `@Nullable` annotation in Guava made it necessary to refactor some code a little, where Spotbugs now complained about possible nullability.

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>


          avoid unnecessary copying of raw access records

95a1165

By replacing the getters by an API that takes a `Consumer` to iterate over the internal collections we can avoid copying the internal sets to `ImmutableSet` and still keep an immutable API of `ClassFileImportRecord`.

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>


          replace ArchUnit Optional by java.util.Optional

1e39337

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>


          replace ArchUnit Function by java.util.Function

519bce0

Signed-off-by: Marion Knopp <marion.knopp@gmail.com>


          replace ArchUnit Supplier by java.util.function.Supplier

41b0e1f

The main usage was ArchUnit's own `Optional` type, so now almost all usages are already gone.

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>


          replace ArchUnit Predicate by java.util.function.Predicate

eb4663f

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>


          replace anonymous classes by lambdas/method references

3819a84

Signed-off-by: Marion Knopp <marion.knopp@gmail.com>
Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>

codecholeric added 10 commits

May 3, 2022 14:02


          replace Collection.sort() by Stream.sort()

787ea8a

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>


          replace Guava Supplier by java Supplier

24c9965

The only reason where we specifically use a Guava supplier is to leverage the Guava utility class `Suppliers`. From this in turn we only use `memoize` and `ofInstance`. The former one we can simply wrap into an ArchUnit utility class and the latter one does not really provide much value, since `() -> value` is way shorter to read than `Suppliers.ofInstance(value)` anyway.

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>


          replace for loops by stream operations

abf7275

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>


          replace Guava Function by Java Function

efa3066

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>


          replace Guava Predicate by Java Predicate

4becc47

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>


          replace old functional Guava patterns

2ba24e6

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>


          remove Guava utility class

723ffbe

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>


          replace //* by /+ in NormalizedUri Regex

39521ef

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>


          fix possible resource leaks due to unclosed JAR files

65a5cc4

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>


          replace Iterable in user APIs by Collection

122c0aa

Since the API to create a `Stream` from an `Iterable` is so much less user-friendly we should try to offer `Collection` in the API where reasonable. APIs that consume from the user should take `Iterable` if there is no reason for a more narrow type. But APIs that offer to the user should offer `Collection` instead of `Iterable` to make the `Stream` processing simpler.

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>

codecholeric force-pushed the drop-java7-support branch from de39fa6 to 122c0aa Compare

May 3, 2022 07:02

codecholeric mentioned this pull request

[How to] Detect reference for field in methods #857

Closed

codecholeric merged commit a96bf1e into TNG:main

codecholeric added this to the 1.0.0 milestone

codecholeric added the breaking change label

hankem mentioned this pull request

Feature/issue 641 filtering env props #899

Closed

Contributor

perlun commented Feb 8, 2023 •

edited

Loading

@hankem @codecholeric - I stumbled into this because of the 122c0aa commit. Since ArchCondition#init(Iterable<T>) was previously a part of the public API and is now replaced by ArchCondition#init(Collection<T>), this is actually a breaking change even for projects which are already on Java 8+. 🤔 (that's what got me looking into this in the first place; we have a subclass of ArchCondition which tried to override the old init() signature => compilation error)

Perhaps we could make this more discoverable by adding it to https://github.com/TNG/ArchUnit/releases/tag/v1.0.0-rc1? 🤔 Just a list below the ArchUnit now needs at least Java 8 to run (see https://github.com/TNG/ArchUnit/pull/833) line with something like this could do:

Iterable in user APIs like ArchCondition has now been replaced by Collection

There might be other things worth mentioning there as well, I'll leave it up to your good judgment to decide on that. 👍 The ArchUnit Optional to java.util.Optional is clearly one such case, but #634 is helpful in this (= as I mentioned elsewhere, if people have upgraded to 0.23.1 before they attempt to upgrade to 1.0.0, they are typically much better off, seeing the deprecations before it's "too late")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

breaking change