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.
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] > <javascript:>> wrote: > > > > On Sat, Nov 3, 2018 at 2:23 AM 'Michel Krämer' via jackson-dev > > <[email protected] <javascript:>> 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] > <javascript:>> 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] <javascript:>. > > > > 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] <javascript:>. > > > 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.
