On Sat, Nov 3, 2018 at 2:23 AM 'Michel Krämer' via jackson-dev
<[email protected]> wrote:
>
> Hi Tatu,
>
> ## Regarding the "vanilla mapper":
>
> Thanks for the brief description, but I'm not sure if I understand what the
> vanilla() or std() methods would do. Would they create a single instance of
> JsonMapper with default values? In this case, I would actually prefer std()
> or even instance(). vanilla() is not really meaningful in this case in my
> very humble opinion. I would also prefer default() but I'm not sure if this
> causes problems with the keyword (I guess not).
It would return a lazily-created (on first access) globally
(per-ClassLoader) shared instance with default configuration.
So basically replacing "private final static ObjectMapper MAPPER = new
ObjectMapper()" pattern, for non-DI use cases.
Use case, I think, would mostly be:
1. Reading as `Map`s ("untyped")
2. Reading as `JsonNode`s (tree)
3. Writing of Maps, JsonNodes as POJOs
> ## UncheckedObjectReader
>
> Do you have examples from other libraries offering the same kind of
> flexibility? I think this approach is really unusual and you should probably
> stick to one or the other. I don't have a strong opinion which one to chose
> actually but there's a trend towards unchecked exceptions in the community.
I do not recall seeing this elsewhere (but need to go google now!),
but the idea has been floated around for years for Jackson at least:
https://github.com/FasterXML/jackson-databind/issues/779
which was created in 2015.
But I guess it is a fair point: alternative would be to rebase
`JsonProcessingException` as `RuntimeException`.
And the reason this has not been possible to do before is that it is a
major-version change, and that has not been available
for a while. But it now is.
Changes might not have to be quite as extensive as I first thought,
either, since the only places where IOException comes into
play are couple of low-level buffer-filling read methods. And
conversion from those is much less work than having to wrap all
access points.
It would even be possible I suppose to add exception converters so
users could choose alternate unchecked exceptions
for IOExceptions, and maybe even translation/wrapping of
`JsonProcessingException`, for convenience (to match framework they
use
or something). But that's just possibility.
> I hope this helps!
Sure did!
-+ Tatu +-
>
> Michel
>
>
> > On 3. Nov 2018, at 03:07, Tatu Saloranta <[email protected]> wrote:
> >
> > Ok but seriously this is important. I have 2 things to name, for Jackson
> > 3.0:
> >
> > 1. Term to use for "standard" or "vanillla" JsonMapper
> > 2. Term to use for "ObjectReader"/"ObjectWriter"s that do not throw
> > exceptions ("safe", "unchecked"?)
> >
> > ## One: "vanilla mapper"
> >
> > Unlike many other json libraries, Jackson does not provide a "default"
> > ObjectMapper instance.
> > This because of statefulness (mutability) of ObjectMapper: as a
> > general rule, Stateful JVM-wide Singletons are Bad.
> >
> > But.... With Jackson 3.0, mappers are no longer mutable at all, as
> > they are built using builder() pattern. So while there is some actual
> > state for caching of handlers, there is no user-tweakable or visible
> > mutable state.
> >
> > This open door for something like:
> >
> > String json = JsonMapper.vanilla().writeValueAsString(pojo);
> > // yes: there's still `ObjectMapper`... but that's base class, with
> > format-specific impls
> >
> > which is something that works well for some uses, and is something
> > `jackson-jr` does:
> >
> > String json = JSON.std.asString(map);
> >
> > This leaves naming. While "std" is short for "standard", it has other
> > connotations too as abbreviation. "default" is one possibility, except
> > that it's now a keyword in Java 8 (isn't it?).
> > I sort of like "vanilla" personally.
> > What do you think?
> >
> > ## Two: "SafeObjectReader", "UncheckedObjectReader"
> >
> > Another big pain point that I get annoyed by myself nowadays is the
> > fact that most Jackson read/write methods expose checked exceptions.
> > While I would otherwise prefer checked over unchecked (yes, I am Old
> > Skool), this wreaks havoc on Java 8 Streams, chaining, closures.
> > So... there is value in having something that does NOT throw them.
> > At the same time, I am not sure I want to throw out existing exception
> > hierarchy,... mostly because due to actual reading/writing, we'll
> > always have `IOException`s to deal with.
> >
> > So: assuming we will keep `JsonProcessingException` and others
> > extending `IOException`,
> > there is another possibility: create subtypes of `ObjectReader` and
> > `ObjectWriter` that do NOT throw checked exceptions, but simply handle
> > them differently (throw unchecked exceptions, typically, or maybe call
> > a handler, pass failure some other way).
> > The only things of note really are that:
> >
> > 1. There's a subtype, with naming prefix ("XxxObjectReader",
> > "XxxObjectWriter")
> > 2. One gets instances from "ObjectMapper" same to regular
> > reader/writer, passing optional handler for `IOException` subtypes (or
> > if not passed, use default one that constructs RuntimeException of
> > some kind that nests original one)
> > 3. Resulting instances behavior is otherwise identical to default
> > readers, writers
> >
> > So, naming: my initial naming ideas would be:
> >
> > * "SafeObjectReader", "SafeObjectWriter"
> > * "UncheckedObjectReader", "UncheckedObjectWriter"
> >
> > but neither feels exactly accurate. There isn't anything particularly
> > safe there (... but there are other libraries that use this
> > connotation...). And "Unchecked" is, well, bit too technically
> > accurate, yet sort of awkward.
> > Or put different way: these are neither more safe nor less checked:
> > handling is the same, only error reporting is bit different.
> >
> > What say you?
> >
> > -+ Tatu +-
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "jackson-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to [email protected].
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "jackson-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"jackson-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
