1. I vote "vanilla" over standard.
2. In my own code, I follow the pattern that objects SafeObjectReader and
UncheckedObjectReader would be opposites. The first will never throw an
exception from its own code and will trap any exception from calling code
and not propagate it. The "unchecked" variant can throw. If Jackson 3.0 is
open to the world of passing handlers around, something like the following
gives a nice hook:
mapper.safeRead(aString, MyObject.class, ex -> {
// do some logging
// do whatever else I need
// construct and return a suitable, typesafe value
});
Thanks,
Ben Vesco
On Thu, Jan 10, 2019 at 10:14 PM Tatu Saloranta <[email protected]>
wrote:
> On Tue, Jan 8, 2019 at 11:42 PM Lovro Pandzic <[email protected]>
> wrote:
>
>> Hi all,
>>
>> a little bit late to the party, but regarding IOException(s), are you
>> aware that since Java 8 there's
>> https://docs.oracle.com/javase/8/docs/api/java/io/UncheckedIOException.html?
>> I've been using it extensively when wrapping of IOE is needed.
>>
>
> Thank you for pointing it out. Yes, I am aware of it, and have considered
> it as one possibility as possible base type of exceptions for jackson 3.
>
> I am leaning towards not using it, however, since once we get away from
> `IOException` which can be exposed as-is (in case of low-level I/O), there
> are many other opportunities for improvements, so use of JDK-defined type
> doesn't seem to have many benefits.
> But one specific problem is that constructing one requires passing of
> `IOException` so this might result in most of the time nesting two
> exceptions (or creating bogus instance to wrap).
>
> -+ Tatu +-
>
>
>>
>> Lovro
>>
>> On Saturday, November 3, 2018 at 4:46:25 PM UTC+1, Tatu Saloranta wrote:
>>>
>>> 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.
>>
> --
> 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.
