On Mon, May 8, 2017 at 5:00 PM, Jeff Schnitzer <[email protected]> wrote: > Is there anything about making ObjectMapper immutable in the works? The api > is a bit messy for making new objectmappers derived from old objectmappers. > > (sorry if this question has already been asked/answered, I’m intermittent)
No, although it would make sense to do one of two things: 1. Remove all readValue()/writeValue() calls from ObjectMapper, and consider it strictly as factory for ObjectReaders and ObjectWriters 2. Create ObjectMapper builder/factory, which is configurable, but require construction of immutable mapper for actual use (if so, it'd be redundant with ObjectReader/ObjectWriter) I agree in that at this point ObjectMapper is bit stuck between two worlds: one where it is to be used directly (original state), and one where it's merely a factory. Division (or not) of reading/writing side is also tricky: - On plus side, separating the two simplifies respective APIs and allows easier identification of which features matter where - On down side it is more difficult to pass 2 things through frameworks like JAX-RS or Spring, and they much prefer getting ObjectMapper One thing I have no interest in doing, but that has been proposed, is adding some kind of flag to indicate that ObjectMapper can not be configured again: I don't think that approach works well either from user or implementation perspective. -+ Tatu +- > > Jeff > > > > On Mon, May 8, 2017 at 11:58 AM, Jeff Maxwell <[email protected]> > wrote: >> >> Streamify ObjectMapper and ObjectReader >> >> ObjectMapper and Object Reader methods that return Iterators should have >> associated *AsStream methods. >> >> Note that users will have to close the returned Streams to avoid leaking >> resources. >> >> Below are potential methods to add: >> >> <T> Stream<T> readValuesAsStream(byte[]) >> DoubleStream readValuesAsDoubleStream(byte[]) >> IntStream readValuesAsIntStream(byte[]) >> LongStream readValuesAsLongStream(byte[]) >> >> <T> Stream<T> readValuesAsStream(byte[], int, int) >> DoubleStream readValuesAsDoubleStream(byte[], int, int) >> IntStream readValuesAsIntStream(byte[], int, int) >> LongStream readValuesAsLongStream(byte[], int, int) >> >> <T> Stream<T> readValuesAsStream(DataInput) >> DoubleStream readValuesAsDoubleStream(DataInput) >> IntStream readValuesAsIntStream(DataInput) >> LongStream readValuesAsLongStream(DataInput) >> >> <T> Stream<T> readValuesAsStream(File) >> DoubleStream readValuesAsDoubleStream(File) >> IntStream readValuesAsIntStream(File) >> LongStream readValuesAsLongStream(File) >> >> <T> Stream<T> readValuesAsStream(InputStream) >> DoubleStream readValuesAsDoubleStream(InputStream) >> IntStream readValuesAsIntStream(InputStream) >> LongStream readValuesAsLongStream(InputStream) >> >> <T> Stream<T> readValuesAsStream(JsonParser) >> DoubleStream readValuesAsDoubleStream(JsonParser) >> IntStream readValuesAsIntStream(JsonParser) >> LongStream readValuesAsLongStream(JsonParser) >> >> <T> Stream<T> readValuesAsStream(JsonParser, Class) >> <T> Stream<T> readValuesAsStream(JsonParser, Class<T>) >> <T> Stream<T> readValuesAsStream(JsonParser, JavaType) >> <T> Stream<T> readValuesAsStream(JsonParser, ResolvedType) >> <T> Stream<T> readValuesAsStream(JsonParser, TypeReference) >> <T> Stream<T> readValuesAsStream(JsonParser, TypeReference<?>) >> >> <T> Stream<T> readValuesAsStream(Reader) >> DoubleStream readValuesAsDoubleStream(Reader) >> IntStream readValuesAsIntStream(Reader) >> LongStream readValuesAsLongStream(Reader) >> >> <T> Stream<T> readValuesAsStream(String) >> DoubleStream readValuesAsDoubleStream(String) >> IntStream readValuesAsIntStream(String) >> LongStream readValuesAsLongStream(String) >> >> <T> Stream<T> readValuesAsStream(URL) >> DoubleStream readValuesAsDoubleStream(URL) >> IntStream readValuesAsIntStream(URL) >> LongStream readValuesAsLongStream(URL) >> >> >> >> On Tuesday, February 21, 2017 at 8:53:03 PM UTC-6, Tatu Saloranta wrote: >>> >>> Quick note: I collected existing ideas on my notes to a single wiki page: >>> >>> https://github.com/FasterXML/jackson-future-ideas/wiki/Jackson3-Changes >>> >>> and intend to evolve that on short term, possibly dividing into more >>> granular pages. >>> Eventually should split those into issues, but before that a lot more >>> needs to happen; including question of whether there should be new >>> repo for Jackson 3 core components. >>> But I thought it's better to start collecting ideas. >>> >>> Another related wiki page is this: >>> >>> >>> https://github.com/FasterXML/jackson-future-ideas/wiki/Major-Design-Issues >>> >>> and it contains (an incomplete) list of major unsolved issue regarding >>> Jackson core design, especially in areas that we have had to postpone >>> from 2.9. >>> >>> -+ 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.
