Andrew Guibert

The discussion about integrating with some sort of MP/Jakarta Config spec is good, but I want to point out that it should be considered separately from this issue. I've raised...

Wanted to post an update on this issue, as I think it is one of the most important issues to address in JSON-B vNext. # Proposed solution example Consider that...

> 1. Isn't it an adapter and something we already have in terms of API? If you think impl today, you can already do that. Valid question. While you can...

I still think that the customization approach has value because it is flexible for any JSON-B annotation and gives the user what they want for this use case: the ability...

> you can register it on the nested jsonb instance globally so no big deal. Yes, but sometimes users don't want to register an adapter/serializer/deserializer globally, or they can't because...

The reflection/visitor pattern you mention seems like it would be even more code overhead than the Adapter approach. For simple customizations like this I think the visitor pattern is overkill....

Given the field/method visibility restrictions added in Java 9, I do not think it would be a good idea to encourage users to expose non-accessible fields/methods which would require reflection...

> It's still possible to access private fields in JDK > 8. It is only possible in JDK > 8 because `--illegal-access=warn` is enabled by default. Illegal access will not...

true... all of my experience with Java modules has been about compatibility and making things work as-is, but once java modules are more properly adopted then people will have the...

> 2 works but violates java bean standard so not sure it is a good thing. Can we at least adjust it this way: the visibility of the java property...