Qodana Community for JVM

It seems all right 👌

No new problems were found according to the checks applied

💡 Qodana analysis was run in the pull request mode: only the changed files were checked

      - name: 'Qodana Scan'
        uses: JetBrains/[email protected]
        with:
          upload-result: true

Hey @scordio,

would it be possible to publish a new release including this change? The current version of byte-buddy does not support Java 21 yet :(

Compiling assertj from source and using assertj-core in a downstream project, I can verify that my tests are passing and
Java 21 (65) is not supported by the current version of Byte Buddy which officially supports Java 20 (64)
is gone.

Hi @NotMyFault, AssertJ no longer shades Byte Buddy (#2477) so it should be possible to override its version with an explicit declaration of the dependency.

Would that work for you?

AssertJ no longer shades Byte Buddy (#2477)

Oh, I wasn't aware of that! Currently, I'm using assertj-core 3.24.2, but apparently byte-buddy is a provided dependency still:

Compiling from source ships byte-buddy 1.14.7, as this PR updates to. Therefore, I was confident cutting a new release addresses the former issue:

Shouldn't it be the case that byte-buddy is no longer shipped/managed, according to your comment?

It is indeed a transitive dependency, but something like the following should work (assuming you use Maven):

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>net.bytebuddy</groupId>
      <artifactId>byte-buddy</artifactId>
      <version>1.14.7</version>
    </dependency>
  </dependencies>
</dependencyManagement>

<dependencies>
  <dependency>
    <groupId>org.assertj</groupId>
    <artifactId>assertj-core</artifactId>
    <version>3.24.2</version>
    <scope>test</scope>
</dependencies>

mvn dependency:tree yields:

[INFO] +- org.assertj:assertj-core:jar:3.24.2:test
[INFO] |  \- net.bytebuddy:byte-buddy:jar:1.14.7:test

(assuming you use Maven):

Yeah, I called mvn dependency:tree for the screenshots. Unfortunately, putting a per-repository overwrite in place doesn't seem bulletproof for ~90 repositories, depending on assertj-core directly.
I think a new release would facilitate updating and testing downstream projects on Java 21.

I'm not familiar with this project's release cycle, but Java 21 released to GA on September the 19th, and I don't want to push you on anything at this time, there are still ~3 weeks left.

I checked where we updated Byte Buddy to version 1.12.21 (23afe18) and we were already testing on Java 21 (https://github.com/assertj/assertj/actions/runs/3854187439/job/10479168806), which was working because of -Dnet.bytebuddy.experimental=true.

Might also be an option in case you can centralize such a setting.

I'm not familiar with this project's release cycle

We don't have a fixed release cycle but we're already working on finalizing 3.25.0. However, we cannot really promise anything better than Soon™ 🙂

Java 21 released to GA on September the 19th, and I don't want to push you on anything at this time, there are still ~3 weeks left.

Three weeks for work done during our free time is not a lot in the end 😅 however, we might consider dropping some topics from 3.25.0 to allow for better interoperability with Java 21 (cc @assertj/core).

Might also be an option in case you can centralize such a setting.

Unfortunately, assertj-core is not part of our parent pom 😔

Three weeks for work done during our free time is not a lot in the end 😅 however, we might consider dropping some topics from 3.25.0 to allow for better interoperability with Java 21 (cc @assertj/core).

No worries, I don't expect or rely on a release on - or until - that date 😄
I'm just testing our projects looking for issues with Java 21 to see where we're at, take all the time you need.

A friendly and responsive maintainer in OSS is already more than I can appreciate 🙏

@NotMyFault just FYI, we discussed internally that we'll shrink the scope of 3.25.0 and try to get it released as soon as we can.