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.
