Open sbernard31 opened 3 days ago
Makes sense - if protected JavaType parseType(MyTokenizer tokens, int nestingAllowed)
is protected and we allow users to subclass com.fasterxml.jackson.databind.type.TypeParser then MyTokenizer needs to be public or protected. There are a number of other protected methods in TypeParser that take a MyTokenizer instance as input too.
I would prefer if a lot more of jackson-databind was private. Making so many methods protected has consequences. It requires that a lot of other code needs to be public or protected.
In this case, it could be viewed as breaking binary compatibility but I think the MyTokenizer should be made private or left as package private and the API methods that take MyTokenizer inputs could be changed to have StringTokenizer as the param type instead. MyTokenizer extends StringTokenizer.
Ok. Here's my perspective: I think these kinds of items are almost waste of time. I see rather modest benefits from possible changes; moderate chance of regression; and a high chance of bike shedding.
As a result I have no interest in changes for 2.x BUT if others are more interested in making changes, am perfectly fine with changes to upcoming 3.0 (branch master
).
So PR(s) against master
may be accepted.
I'm using revapi, to check I respect semantic versioning in my project.
But it also checks some code smell about API. When building my project, it report something wrong with jackson (which is one of my dependencies)
Report :
nonPublicPartOfAPI
is described here.I copy/paste the
exampleUseChainInNewApi
here because this is the most important part to understand the issue :Solution ?
I think
MyTokenizer
should be protected instead of package ?(issue found with 2.15.3 and also tested with 2.17.1)