JDK17 compatibility #3168
Comments
|
Unfortunately most if not all remaining issues that surface with that rather non-descriptive warning are due to dynamic introspection for various JDK types and depend on actual usage. Jackson core itself does not force access to JDK, but to access fields, getters, setters, constructors, introspection is used. So unfortunately this is not as easy as (for example) replacing use of So what tends to be necessary are user reports for specific usage that triggers these issues: this helps figure out how to prevent specific problems. I am not confident there is a general simple solution; although more and more general improvements can be developed when finding patterns common to reported problems. |
|
@cowtowncoder, thank you for clarification, fully agree! I was about to update the description that this is not solvable by jackson itself. A way to deal with it is to expose such illegally accessed packages with --add-opens. |
|
@nmandrescu Agreed! And this is one area that I really hope we can get improvements on, from better diagnostics to tooling perhaps. One thing that has been unfortunate is that from what I have seen, stack traces do not always seem to identify context in which problem occurs: while it is |
|
This is something that I am specifically looking at - The problem is closer to usage, than implementation though, through devious attempts of resolution -
For now I think Jackson caters perfectly for modularization, and adheres to all encapsulation limitations placed - The user however must be aware of the new encapsulation rules (which are correct) and bend accordingly to them. We can perhaps improve on the time-jsr a bit more to assist users move across properly, but right now, I am looking at the jakarta module split, and seeing what's happening in Version 3. Outcome Analysis - |
|
Good overview @GedMarc. One specific area where we can probably make progress is to start preventing what must be illegal accesses into |
|
If it helps and possible to do anything about, here are some For |
|
Thank you @nmandrescu! It'd be great to know the path through which these came about (for reproduction), but this is helpful as-is. |
|
Not sure if this is helpful but you can pass |
|
Please take a look at my new article that explain how to export all modules to all modules at runtime in Java 16 and later without using any JVM parameter |
|
Look at the new frameworks for how write modular and encapsulated applications, something like guicedee.com, that works completely on proper encapsulation. You don't "Solve" this problem with --add-exports and add-modules, or any other temporary work around in order to give people time to adapt, you Adapt to the shift in language by just doing it properly, so you can get all the benefits from it, which far out way and out perform any classpath-based application, by miles. I apologize for the below tone but..... in order to get my facial expression across xD (in jest please) |
|
Could these details help me in my specific case: with this sample code: the error is on this line : |
|
So do we support JDK 17 now? |
|
Yep - including full support for jpms |
|
Thank you! We've used successfully several |
|
Can Anyone Help Me to resolved thw following error |
The fastest solution is to export all modules to all modules at runtime |
|
@Aksh125 please provide a little more detail |
Please stop down-voting working solutions even if they use some hack because they might be interpreted as broken solutions. And very often people don't have time to fix problems caused by new implementations of the jdk |
|
@Roberto-Gentilli As the developer for the modularization of the Jackson library and assisting with the usage of modules, unfortunately no - Giving the impression to say, new developers, that that process is acceptable is giving the wrong guiding and direction entirely - Reference : https://stackoverflow.com/questions/68867895/in-java-17-how-do-i-avoid-resorting-to-add-opens |
You can tell people that there are better solutions, but if you vote against a solution it might appear that the solution doesn't work. I can assure that the solution proposed by @JJBRT works perfectly (except on Android) and I can also assure you that people's frustration when they see that their software no longer works with the new jdk implementation is often very high |
|
@GedMarc @Roberto-Gentili when my spring boot application running on JDK 11 its show the warning |
|
@Aksh125 A stack trace please, and which version of Jackson are you using? :) |
|
@Aksh125 can you please log it against the afterburner project? |
If you need a fast solution and you are not developing on Android you need only to add this to your pom: <dependency>
<groupId>org.burningwave</groupId>
<artifactId>core</artifactId>
<version>12.62.0</version>
</dependency>... And then you need only to call the method public class MainClass {
static {
org.burningwave.core.assembler.StaticComponentContainer.Modules.exportAllToAll();
}
public static void main(String[] args) {
... Do the stuff
}
}if you see a lot of logs, they can be disabled |
|
and only if it's not enterprise, and if it is enterprise, only if the burningwave is on the approved dependencies list for that organisation... |
if this is a solution to @Aksh125's problem, I'd let him decide |
|
Rather just learn how JPMS works and just fix it, Classpath mode is fading away - all of these -- hacks --- at one point will stop working, each Java major release adds another layer of modular security, and the benefit's of modularization far outweighs the push-back against it. |
Ok, you made it clear, but let him decide which solution to adopt especially when your library is the first to use illegal reflection operations |
|
Only on private field-access properties - which is against strict-encapsulation, but we want to keep that option available for backwards compatibility...... It could just be as simple as an opens clause in their module-info file, or proxying the classes referenced from afterburner.... |
|
Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to unnamed module @1d8b0500 Getting the above error while upgrading from jdk 11 to 17. Could you please help here? |
|
When calling Java command, you can add an |
|
@Vishal-0319 that error message would not be enough to help, fwtw, as it does not show which class is being problematic (or reproduction to figure it out). You also did not include Jackson version. Going forward it'd make sense to add more information as well as file a separate issue. |
|
I will try out and get back with the info if it doesnt workout, thanks. |
Problem
JEP 403 targeted for JDK 17 (release planned for Sept 2021) will remove
--illegal-accessflag. That will be equivalent to--illegal-access=deny.Running with
--illegal-access=warnapps using jackson-databind and other jackson modules reported here #2856 (comment) can discover issues likeWARNING: Illegal reflective access by com.fasterxml.jackson.databind.util.ClassUtilWorkaround
For illegal reflective access pointing to jackson use --add-open for the package containing the restricted field.
Update
Not related to jackson library, since JDK 9 a number of standard replacements are provided for the most commonly used internal elements of the JDK.
The text was updated successfully, but these errors were encountered: