2.10 : JPMS java.base/java.time does not open to jackson

[GedMarc]

When running in strict naming, java.time package is not exposed

com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Invalid type definition for type java.time.LocalDate: Failed to construct BeanSerializer for [simple type, class java.time.LocalDate]: (java.lang.reflect.InaccessibleObjectException) Unable to make field private final int java.time.LocalDate.year accessible: module java.base does not "opens java.time" to module com.fasterxml.jackson.databind

[GedMarc]

@cowtowncoder I've gone through a few variations here -

Simple answer is the best solution with no requirements needed on the developers end for this library is simply just to stop using field access.

What are your feelings of going a property access route only.

[GedMarc]

For this one in particular because it is a java.base library and not an external source, the module declarations are fixed and non-changeable, This means using this addon with JPMS currently requires either opening the running module

open module my.package.application{}

or adding command line property to expand the module chart -

add-opens=java.base/java.time:com.jackson.datatypes

[cowtowncoder]

Hiya. Apologies for slow response.

Yes, without looking at this case, I do not think field access should be required, and it sounds like it might be side-effect of something not working as expected. I'll see if I can spot where such access would occur -- I thought none would be needed by Java 8 date/time module.

However, if there is any way to get more information (like stack trace maybe?), that'd be great. I assume error occurs dynamically during either value serialization or type introspection.

[cowtowncoder]

@GedMarc actually, reading back the first message here: are you actually registering the date/time module? BeanSerializer should never be constructed for LocalDate, as there is specific LocalDateSerializer; and serializing it as POJO does not make too much sense in general.

Beyond that, however, I do think there is the question of if and how to avoid attempts at accessing non-accessible accessors from known JDK types -- it is possible some JDK types just happen to be working with Java 8 and below, due to use of things like 1-arg constructors, static valueOf() methods. So it'd be good to find examples of where this could be problematic, to improve handling. I am thinking, for example, that visibility rules should be overridden for classes under "java." (knowing it is reserved namespace and access won't typically work, nor should be required).

[GedMarc]

OH, yes, p.s. this was because I didn't include the jdk 8 library - It actually isn't a problem