On Sat, Nov 3, 2018 at 8:41 AM Tatu Saloranta <[email protected]> wrote:
>
> 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).
Turns out that yes, it does fail to compile (or at least IDE flags it).
And right after sending my reply, it occurred to me that `shared()`
public static JsonMapper shared() {
return LoaderClass.INSTANCE;
}
just might be the most obvious name to use?
> 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 +-
-+ 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.
