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.
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
illegal reflective access operation: AccessibilityChanger #1325
Comments
Not sure if this helps, but I'm seeing the same issue in a different project. We've tracked it down to spying on types from the package org.triplea;
import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.arrayContaining;
import static org.mockito.Mockito.when;
import java.io.File;
import org.junit.jupiter.api.Test;
import org.mockito.Mockito;
public final class MockitoJava9Test {
@Test
public void spyReportsIllegalReflectiveAccess() {
final File directory = Mockito.spy(new File("path"));
// NB: using a mock instead of a spy does not report illegal reflective access
// final File directory = Mockito.mock(File.class);
final File file1 = new File("file1");
final File file2 = new File("file2");
when(directory.listFiles()).thenReturn(new File[] {file1, file2});
assertThat(directory.listFiles(), arrayContaining(file1, file2));
}
} Running the test as-is reports the following warnings to the console:
Commenting out the initialization using the spy and uncommenting the initialization using the mock produces no warnings. |
Hi, Found another similar issue running OpenJDK 11:
|
Same here: [info] Mockito can only mock non-private & non-final classes. |
I'm also seeing this warning using jdk11 and mockito-core 2.24.0, the latest stable version at the time of this writing:
Is there any hope of this being addressed in the near future? I don't have a good sense from the referenced issue about how much of a commitment it is to fix this on Mockito's side. |
Another illegal reflective access, this time to Any plans for a fix? (I should add I am using Mockito 3.0.4 on OpenJDK 11.0.4.) |
Changed the project's assigned JDK from 11 to 8 and it worked. Also made sure the jdk folder was not locked. |
Hi, Any updates about this issue? Thanks |
I agree with MarceloMariduena. Changing the JDK works. |
I have the same issue and changing the JDK is not an option for me. Any updates? |
Looks like version 1.9.3's
|
Ooo.. we have a culprit.. hopefully this leads to a resolution? |
In my case, changing the dependency from |
I am with @omnipitous This issue happens to me when I use @SPY annotation. |
I am also experiencing this in JDK 13 with mockito-all version 1.10.19. Discovered it while bootstrapping a new pet-project. Example test:
Output:
|
|
I'm also experiencing this when using a spy with JDK 14 and |
The issues seems to be still present in
|
Issue still present in 3.3.3 with any JDK 9+. It does happen everytime we use a
|
This comes from a call to java.lang.reflect.AccessibleObject#isAccessible, which is deprecated in Java 9+. The javadoc suggests to use #canAccess instead:
Unfortunately this method is only available from Java 9, which would make Mockito incompatible with Java 8. |
Using OpenJDK11 and facing the same issue with mockito-core 3.2.4 WARNING: An illegal reflective access operation has occurred |
I'm seeing the same issue under:
Error message:
Any updates on this? |
I think we fixed this issue in Mockito 3.5.0. Can you upgrade 3.5.5 and confirm it is indeed fixed? |
Oh and you will probably need the inline mockmaker (e.g. |
I still get a warning with mockito 3.5.5, but the warning has changed. Running the following test on JDK 14:
With mockito-core:3.5.5 I get the following output:
And with mockito-inline:3.5.5 :
|
That's curious. I probably have overlooked something. I'll look into it. |
Okay, the check for a module's openness does of course not work as expected when unnamed modules are involved. I fixed the check and this should hopefully be fixed in 3.5.6. |
Hi, @TimvdLippe , I tried it with:
... But that didn't help. Any further advice? (I'm using JDK11). |
* Added `mockito-inline` which will have to be upgraded (in #48) in the future, once mockito/mockito#1325 has been fixed.
Thanks, |
Just to give feedback for everyone: using the 2 dependencies with Java 11 and mockito 3.5.15 mockito-core Successfully removes the warning. If I don't add the mockito-inline dependency, the warning continues. |
Great, thanks for the feedback. I tested it pretty thoroughly this time and even when prohibiting access, Mockito seems to work without any issues on the inline mock maker. There's one edge cases when mocking a generated class without any constructor but that I don't believe many will run into. |
I am still seeing this error with 3.7.7:
|
Are you using mockito-inline? |
We are using:
|
There's nothing we can do with the standard mock maker. You'd need to use the inline-mock-maker for that. |
Thanks! After switching to the inline mock maker I'm getting this warning instead:
Is it WAI? |
I still have the issue:
I get version 4.0.0 from Spring Boot dependencies - https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-dependencies/2.6.7 |
Hi.
I'm using IntelliJ Community 2017.3 and when I run junit tests using "Menu>Run>Run All In Owner" in my project (https://github.com/lviggiano/owner/) I get the following warning at the console:
I cannot identify the problematic test, since I have hundreds and this happens when I run them all at once. But eventually if I find the problematic one, I'll update this issue.
I'm using mockito-core 2.15.0; java 9.0.1, Maven 3.3.9, Mac OS X 10.13.3
Thanks & Best regards,
L.
The text was updated successfully, but these errors were encountered: