Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create JsonReadFeature to move JSON-specific JsonParser.Features to #467

Closed
cowtowncoder opened this issue Jun 26, 2018 · 0 comments
Closed
Labels

Comments

@cowtowncoder
Copy link
Member

Currently JsonParser serves dual role of being both base parser/decoder API and its JSON-backed implementation. Ideally we would split it into 2 parts (similar to how JsonFactory was changed to extend TokenStreamFactory, new API, and become just implementation), but due to wide-spread usage in mapper api this is impractical.

But one aspect we can improve is to split JsonParser.Feature entries: most of them are strictly JSON-specific, and only couple have general applicability.
While we could half-ass this change, too, we probably need to do full change in 3 distinct parts:

  1. New JSON-specific feature, like JsonReadFeature (for most entries). For 2.10, has to duplicate entries; for 3.x can actually move. 2.10 probably has to map these to JsonParser.Feature
  2. New general-purpose feature, maybe StreamReadFeature (for couple of general purpose ones). For 2.10, could simply map to existing JsonParser.Features (implementation-wise); for 3.x, probably want to reverse.
  3. JsonParser.Feature itself; entries to be deprecated (perhaps even in 2.10?).

It also seems likely that although we can forward-proof API to a degree with 2.10, implementation probably differs so that:

  • 2.10 will map new features into old flags, and basically not add much internally aside from delegation
  • 3.0 should map deprecated JsonParser.Feature shared flags (since they are more widely used), but can just drop JSON-specific ones as delegation might get tricky. This is backwards-incompatible but probably better than attempts at hybrid; most common case is probably that of comment-enabling.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant