Closed Thunderforge closed 5 months ago
You need to add '--add-opens java.base/java.lang=ALL-UNNAMED' fore unit tests to run. If I had to guess gradle has jacoco built in and jacoco removed that in recent versions so its now up to user to do so.
The root issue is cglib which is no longer supported but still works. Long term cglib needs pulled out of this project in favor of byte buddy. It would be nice to see a community attempt at raising a PR for byte buddy replacement which is also already in the project. Without that, it will be a long time until I personally start hitting the issue and I'm forced to make a change. Since there is a clear work around and one that was already present in earlier gradle for you, its more of an issue of just defining needs of your testing.
This project also does the same, see the pom.xml and search on java.lang. Look at commit history as well 28cb9e5fded3e6b8a0c5e24879a9947b7b771191
We do use Jacoco in our project, so that does appear to be the root cause.
Staying on Gradle 8.1.1 isn't a viable solution because we want Java 20 support (and eventually Java 21 support when it's released).
I don't think that adding --add-opens java.base/java.lang=ALL-UNNAMED
every time we run gradlew build
is an acceptable solution. We run builds locally on developer machines and in various ways through CI, and this would be an unnecessary burden.
Thanks for the information about cglib being the root cause. I don't think that we will be in a position to create a replacement with bytebuddy.
We'll continue looking for workarounds that are acceptable. If one isn't forthcoming, we'll have to consider removing Javabean Tester.
Not sure you understood fully. The add opens you add to your gradle build scripts so user doesn't do anything special. It's just there across platforms. Jacoco was doing this for users until their recent release to support latest jvms. It doesn't mean remove javabean tester. It's working fine through jdk 21 now. You will find the same issue with other libraries. It's rather routine to understand that with newer jdks. Any byte manipulation library is usual suspect to needing this. They do after all touch java internals in interesting ways. Libraries like error prone, lombok, and many others have very similar requirements. In example I gave here it's for maven Surefire, I'm sure you can config same for gradle since gradle claims they are superior. Do go to jacoco and look at their change logs. They do explain why they removed it, mostly because user should add themselves for clarity and they eventually rewrote away from their need.
As a quick patch here, I could look to just copy the code jacoco had but it may be just as quick to switch over fully to byte buddy which is also already in this library. It's not a critical issue though either way and simple to work with as is.
For what it's worth, I've been running this with jdk 20 at scale without issue for some time. This includes multiple ci systems, jenkins and github actions.
Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Androidhttps://aka.ms/AAb9ysg
From: Thunderforge @.> Sent: Saturday, August 26, 2023 5:56:46 PM To: hazendaz/javabean-tester @.> Cc: Jeremy Landis @.>; Comment @.> Subject: Re: [hazendaz/javabean-tester] Test passes under Gradle Wrapper 8.1.1, fails under 8.2 and later (Issue #712)
We do use Jacoco in our project, so that does appear to be the root cause.
Staying on Gradle 8.1.1 isn't a viable solution because we want Java 20 support (and eventually Java 21 support when it's released).
I don't think that adding --add-opens java.base/java.lang=ALL-UNNAMED every time we run gradlew build is an acceptable solution. We run builds locally on developer machines and in various ways through CI, and this would be an unnecessary burden.
Thanks for the information about cglib being the root cause. I don't think that we will be in a position to create a replacement with bytebuddy.
We'll continue looking for workarounds that are acceptable. If one isn't forthcoming, we'll have to consider removing Javabean Tester.
— Reply to this email directly, view it on GitHubhttps://github.com/hazendaz/javabean-tester/issues/712#issuecomment-1694508965, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAHODI54NQRJ4UWQYYIBVQTXXJWJ5ANCNFSM6AAAAAA33XWUOA. You are receiving this because you commented.Message ID: @.***>
this may help https://github.com/jacoco/jacoco/issues/1487 as it shows how to address with gradle.
I am looking at this further as well.
General scan of the 100+ projects I work on github shows same is exported in at least a dozen of them. Further looking into this, cglib bean copier is still best option. Further, spring even has a copy of it internally and they state to do the same. What I have done here for time being is stopped using cglib no dep which comes with embedded asm that is really old and does not support newer jdks well. Instead, I'm now letting it bring asm by itself at 9.5.
For now I think this is about all I can do. I'm considering pushing a release as-is like this as 2.6.0 with the asm change but will think on that a few more days.
I confirm that adding
test {
// Other stuff
jvmArgs += ["--add-opens", "java.base/java.lang=ALL-UNNAMED"]
}
does indeed fix this error under Gradle 8.3. But it sounds like your planned 2.6.0 version eliminates the need for this. Is that correct? If so and you are planing on releasing it in the next few days, we'll just wait for that instead of adding it to all of our 20 or so projects.
Best to use solution you have above. After reviewing cglib usage including springs, they are suggesting the same. What jacoco did originally I don't intend to try to add as too complicated.
closing as done per noted. User must add add opens as noted.
The following test passes under Gradle Wrapper 8.1.1 and fails under Gradle Wrapper 8.2 and 8.3 (using Javabean Tester 2.5.3, Java 17).
Under Gradle 8.2 and later, it fails with the following error: