Open mtf90 opened 2 months ago
Lazy on-demand loading is better, we may be maintain a classname to class Id and serializer map in ClassResolver. This is also useful if some class doesn't existin some version but we need put a placeholder for class id in class resolver
Search before asking
Version
Fury 0.5.1, as released on Maven Central
Component(s)
Java
Minimal reproduce step
pom.xml
:module-info.java
:Application:
What did you expect to see?
The programm should run without any issues.
What did you see instead?
Anything Else?
As far as I can tell, this is issue comes down to the static initializations in the
TypeUtils
class which load the classesjava.sql.Date
andjava.sql.Timestamp
. You can workaround this issue by addingto the
module-info.java
. However, I would argue that Fury should not force users to add (even unsupported) dependencies to their project that are not actually needed. I'm not sure about the direct dependencies here (i.e., whether theUnsafe
stuff is only needed as a fallback since it doesn't findDate
in the first place).Given that the types are initialized via
TypeRef.of(Date.class)
andTypeDef.of(Timestamp.class)
(i.e., there does not happen any major background magic) the initializations may simply be removed as they can be easily added in user-land if needed?Alternatively, they could be added on-demand, e.g., only if user-land actually uses these types. Although this could be a little bit complicated given the static nature of the initialization.
A third idea may be to look at
java.util.Date
as potential substitute for at leastjava.sql.Date
.Edit: A fourth idea would be to actually declare
java.sql
andjdk.unsupported
as transitive dependencies of thefury.core
module. However, this would require Fury to support full JPMS modules and not justAutomatic-Module-Names
(cf. #1341).Are you willing to submit a PR?