>
> And right after sending my reply, it occurred to me that `shared()`
>
> just might be the most obvious name to use?
shared() sounds good to me! Good call!
Michel
>
>> 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.
--
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.
