Spying on ArrayList generates Illegal reflective access warning with Java 11

[szpak]

Spying on ArrayList generates Illegal reflective access warning with Java 11 (12):

WARNING: Illegal reflective access by org.mockito.internal.util.reflection.AccessibilityChanger (file:/home/foobar/.gradle/caches/modules-2/files-2.1/org.mockito/mockito-core/3.0.8/.../mockito-core-3.0.8.jar)
to field java.util.ArrayList.elementData
WARNING: Illegal reflective access by org.mockito.internal.util.reflection.AccessibilityChanger (file:/home/foobar/.gradle/caches/modules-2/files-2.1/org.mockito/mockito-core/3.0.8/.../mockito-core-3.0.8.jar)
 to field java.util.ArrayList.size
WARNING: Illegal reflective access by org.mockito.internal.util.reflection.AccessibilityChanger (file:/home/foobar/.gradle/caches/modules-2/files-2.1/org.mockito/mockito-core/3.0.8/.../mockito-core-3.0.8.jar)
 to field java.util.AbstractList.modCount

Sample code to reproduce the situation:

    @Test
    public void shouldNotCallOriginalMethod() {
        //given
        List<Integer> spiedList = spy(new ArrayList<>());
        willReturn(3).given(spiedList).get(0);
        //when
        Integer readValue = spiedList.get(0);
        //then
        assertThat(readValue).isEqualTo(3);
    }

Occurs with (at least):

• Mockito 3.0.0 and 3.0.8
• ByteBuddy 1.9.10 and 1.10.1
• Java 11 and 12 (modern versions)

It's just a warning right now, but it could be disallowed one day, so maybe there is some other way to do that with ArrayList (and probably also some other classes from JDK).

[TimvdLippe]

I reckon this is unrelated to ArrayList in particular, but more that https://github.com/openjdk/jdk/blob/a36b2af52b54f3c9b276555671971ae6ceca772b/src/java.base/share/classes/java/util/ArrayList.java#L138 and https://github.com/openjdk/jdk/blob/a36b2af52b54f3c9b276555671971ae6ceca772b/src/java.base/share/classes/java/util/AbstractList.java#L628 are supposed to be private. It also likely related to modules.

Could you construct a minimal example that uses modules and has a private field that would run into the same scenario? That would ease debugging.

[raphw]

This is very expected since we rely on accessing all fields with reflection.

There is not really a good way around it for us, we need to access these fields. We could attempt to generated classes and inject them but this can only be done legally if the module and packages are open which then would also allow reflection.

[TimvdLippe]

Closing per the above comment. We recommend using mockito-inline on more recent JDKs to avoid the illegal reflection access.