An illegal reflective access

[tarikelbannany]

java version : OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.5+10)

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.fasterxml.jackson.databind.util.ClassUtil (file:/home/tarik/.m2/repository/com/fasterxml/jackson/core/jackson-databind/2.9.8/jackson-databind-2.9.8.jar) to field sun.nio.ch.ChannelInputStream.ch
WARNING: Please consider reporting this to the maintainers of com.fasterxml.jackson.databind.util.ClassUtil
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

[cowtowncoder]

Unfortunately this is not much to go about. Do you have anything else to help trigger the issue? Code to reproduce, stack trace? Without this, all I know is that yes, module system can complain about reflection access used to introspect accessors for value types when reading/writing json.

[tarikelbannany]

Sure, Sure
working with spring boot 2.1.2,
java version : jdk 11.0.5

config

**
spring:
jackson:
serialization:
FAIL_ON_EMPTY_BEANS: false
visibility:
FIELD: any
**

I need to upload a file to a remote server using restemplate

private HttpEntity<MultiValueMap<String, Object>> multiPartHeader(MultipartFile image) throws IOException { HttpHeaders headers = this.header(); headers.add("Content-Type", "multipart/form-data"); MultiValueMap<String, Object> body = new LinkedMultiValueMap<>(); body.add("media[file]", image.getInputStream()); return new HttpEntity<>(body, headers); }

then i got two errors :

1. The reflective access warning

2. Infinite recursion (StackOverflowError) (through reference chain: java.io.FileDescriptor["parent"]
   Infinite recursion (StackOverflowError) (through reference chain: java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io.FileInputStream["fd"]->java.io.FileDescriptor["parent"]->java.io

[cowtowncoder]

This:

body.add("media[file]", image.getInputStream())

will not work: a value or property of type InputStream can not be serialized as it is a transient object.

If you would like to serialize contents of such input source, you will need to read them, and add as byte[] or ByteBuffer.

[pjfanning]

this looks very similar to #2626

[cowtowncoder]

Yes, sort of: basically most JDK types should not be introspected as POJOs and this warning tends to show that either:

1. Type in question should not be serialized, or
2. There is a JDK type not yet explicitly supported by Jackson (POJO approach rarely works, even if excluding access problems)

[cowtowncoder]

Since as per @pjfanning this is I think same as #2626, will close this as dup just because that one has bit more specific info (usually would keep older).

[pjfanning]

It's almost like the 3rd party code is using jackson to serialize a class instance where the class has a member that is an InputStream. Maybe, I don't understand the use case - but serializing such a class should be set up to ignore the input stream because this will consume the stream. It seems to me that custom code should be written when you need to produce json based on reading an inputs stream.

[cowtowncoder]

Right, I think many of these cases are for types that should not be serialized.
Question there is whether there are some common enough cases (esp. for JDK types) where maybe Jackson could add explicit failing deserializer to let dev know that type is typically not to be handled or not. Could include info on how to ignore; I am not necessarily comfortable with automatically just hiding types as that tends to hide real root causes (often these dependencies are something that sneak in, expose other issues).