EsotericSoftware/kryo

Support for JDK17

Open

#885 opened on Feb 18, 2022

View on GitHub
 (24 comments) (0 reactions) (0 assignees)HTML (6,052 stars) (816 forks)batch import
help wantedquestion

Description

Describe the bug It seems that Kryo is currently not compatible with JDK17. When calling the default constructor it fails with:

java.lang.reflect.InaccessibleObjectException: Unable to make private java.nio.DirectByteBuffer(long,int) accessible: module java.base does not "opens java.nio" to unnamed module @61322f9d
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
	at java.base/java.lang.reflect.Constructor.checkCanSetAccessible(Constructor.java:188)
	at java.base/java.lang.reflect.Constructor.setAccessible(Constructor.java:181)
	at com.esotericsoftware.kryo.unsafe.UnsafeUtil.<clinit>(UnsafeUtil.java:100)
	at java.base/java.lang.Class.forName0(Native Method)
	at java.base/java.lang.Class.forName(Class.java:467)
	at com.esotericsoftware.kryo.util.Util.<clinit>(Util.java:47)
	at com.esotericsoftware.kryo.serializers.OptionalSerializers.addDefaultSerializers(OptionalSerializers.java:38)
	at com.esotericsoftware.kryo.Kryo.<init>(Kryo.java:230)
	at com.esotericsoftware.kryo.Kryo.<init>(Kryo.java:168)

To Reproduce Kryo kryo = new Kryo();

Environment:

  • JDK Version: OpenJDK 17.0.2 (Corretto-17.0.2.8.1)
  • Kryo Version: 5.3.0

Additional context In my case I am also registering some standard classes. It seems to work for classes like:

  • java.util.Locale
  • java.time.Instant
  • java.util.HashMap

But it fails for java.util.regex.Pattern due to:

java.lang.reflect.InaccessibleObjectException: Unable to make field private java.lang.String java.util.regex.Pattern.pattern accessible: module java.base does not "opens java.util.regex" to unnamed module @185a6e9

What would be the proper way to fix this?

Contributor guide

Tech stack
java
Domain
backend
Issue type
bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
4
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
3-5 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
Java programmingUnderstanding of Java module systemKryo internals
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
35
Research direction
The issue is caused by JDK 17's module system restricting reflective access. The fix may involve modifying UnsafeUtil.java to handle the InaccessibleObjectException, or using add opens JVM arguments. Alternative approach is to avoid using `setAccessible` on module restricted classes like DirectByteBuffer and Pattern. Investigate comments for proposed workarounds and patches. Consider using the ` add opens` flag in the build configuration for compatibility.