Skip to content
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 warning when using java.lang.Void as value type #2197

Closed
rkschamer opened this issue Dec 6, 2018 · 5 comments

Comments

@rkschamer
Copy link

rkschamer commented Dec 6, 2018

I'm using Jackson (2.9.7) through Spring's RestTemplate:

ResponseEntity<Void> response = getRestTemplate().exchange(
		requestUrl,
		HttpMethod.PATCH,
		new HttpEntity<>(dto, authHeaders),
		Void.class
);

When Void is used to indicate that the ResponseEntity has no body, the following warning appears in the console:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.fasterxml.jackson.databind.util.ClassUtil (file:/<snip>repository/com/fasterxml/jackson/core/jackson-databind/2.9.7/jackson-databind-2.9.7.jar) to constructor java.lang.Void()
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

The problem disappears if String is used as generic type.

@GedMarc
Copy link

GedMarc commented Dec 6, 2018

This forms part of FasterXML/jackson-core#499

@rkschamer
Copy link
Author

Alright, I close the issue then. This was fast :)

@cowtowncoder
Copy link
Member

It probably also makes sense to add explicit handling for (nominal) type Void. Not much point in introspecting it as POJO. I'll actually re-open this to have a look.

@GedMarc
Copy link

GedMarc commented Dec 6, 2018

Hmm, This also definitely justifies open modules until version 3.

java.lang is part of the java.base module, But it is also strictly named.
Currently, in order to run these you have one of two options (Because they are not/never going to 'opens java.lang' in the java.lang module)

  1. You can append --add-opens java.base/java.lang=com.fasterxml.jackson.databind which is the strict module name, and the mechanism for downwards exposure. This has been simplified by creating an @arguments file, and executing that way. This is the Strict JPMS Encapsulation, and is where all the performance boosts come from

  2. This one I like currently, and I'll explain how it works and doesn't destroy the module pathing after

open module com.mypackage.myapp {
}

this does a few things but I'm only going to highlight the features,

  1. The java.base module is now com.mypackage.myapp, and your classes and libraries have been placed in the parent parent module layer. No changes between JRE 8 and JPMS will be felt (so long as your libraries are named. In automatic/unnamed/classpath mode, the module pathing is disabled.
  2. java.lang, java.xml, etc etc, as well as all your packages are opened and exported by default (allowing private field and class handlers like annotations/databind to do its thing without explicit definitions.
  3. The module pathing is still adhered to, and any other named libraries (except yours, because it is now java.base) will still be strictly enforced.

GedMarc added a commit to GedMarc/oss-parent that referenced this issue Dec 6, 2018
Enforce JDK 6 for Annotations and DataBinding
Clean the module pathing
OSS-Parent Update for plugin management
Exclude moditect from plugin version check

FasterXML/jackson-annotations#145
FasterXML/jackson-core#499
FasterXML/jackson-databind#2197
@cowtowncoder cowtowncoder changed the title illegal reflective access operation warning when using java.lang.Void Illegal reflective access operation warning when using java.lang.Void as value type Dec 7, 2018
@cowtowncoder
Copy link
Member

Ok: as an orthogonal thing, I added handling for Void as special type to avoid handling of type as POJO; this should prevent warning. There are already handlers for "always read/write asnull", as it happens, so not much additional work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants