@carterkozak I think I may run it once or twice -- I have occasionally run FindBugs at least. I am against running most of similar tools with every builds, due to noisiness, but +1 for adding profile to make it easy to occasionally run. I think these tools are good for regular checking: first time you run it for new project, often find issues
I've gotten all my tests passing on the 2.12-rc2 snapshots on an internal project. I've found a couple changes that required code modification:
- Some RuntimeExceptions are no longer wrapped in JsonMappingException, despite the WRAP_EXCEPTIONS feature being enabled (default). It's not clear if this was intentional or not, I don't think it's problematic, but it did require some code changes. Not all paths are modified, possibly only deserialization using builders (unsubstantiated). It's possible a mapper is used with wrap-exceptions disabled and a bug was simply fixed between 2.11 and 2.12.
- Beans with a single string (or string-ish) field could be created from a json string in 2.11, however 2.12 requires an object. I consider this an improvement, but it did require adding string-based jsoncreators on a few types to avoid backcompat breaks.
7 replies
Or any other idea how to speed it up
@GedMarc I don't think it's that easy. You cannot just e.g. replace forEachOrdered with forEach. How do you synchronize the output of each thread?
@flix- "How do you synchronize the output of each thread?" I think that's really the problem, isn't it? If you need to write a lot of data to one place, it's often the I/O that's far more expensive than the serialization work. Splitting serialization across threads means you end up spending cpu cycles orchestrating threads and memory (or additional I/O) buffering serialized data that's not ready to be written to the final location yet.
but as to changing behavior; you'd probably need to reimplement it on your own -- serialization is fundamentally single-threaded operation and even if access was changed to parallel, output must be serial (in order). If you wanted to go through that rat hole, you'd have to have parallel output, and then something to stitch together output in synchronized manner.
basically, what @carterkozak said :)
@GedMarc one last (? :) ) question on jakarta-changes to jaxb, jax-rs modules: I assume there can't be collisions between 2 types, as one can only have dependency to one of qualified types? So that all dependencies are to "default" (no qualifier) version of, say,
jackson-module-jaxb-annotations, but user can explicitly override it with qualifier on dependency
1 reply
Good evening (at least in California :-)). I'm looking for a way to read YAML files in Kotlin and Jackson seems to be the way. I've looked at others like Hoplite, but most of the libraries assume I want databinding. I actually don't need databinding, I just want a large map structure so I can do the complex object work myself. Is there a way to do this in Jackson (no databinding)
4 replies
@carterkozak Not intentional. Would be good to get test case for 2.11 vs 2.12 here, if possible. I think that coercion is at databind (not parser) level which at least gives enough control to enforce coercion allowance or not. Actually, there is probably both "coerce from token
NaN" and "coerce from String value "NaN"" -- former is controlled by parser settings, latter by databind
unsure how the binary protocols would interpret that sort of thing
I'll have a test ready shortly
@cowtowncoder It looks really good for the Jakarta namespaces - even the shaded moditect jaxrs seems to have gotten done (which is unexpected, but welcome)
Also got confirmation that nothing more than dependency version setting is all that is needed for JAXB (https://github.com/FasterXML/jackson-modules-base/issues/112#issuecomment-729042778)
JAX-RS is fine as it is right now as long as it's not java native imaging, i'm trying to see if i can fix that for jlink on the service loader provides clause - otherwise - really good
1 reply
Hi Guys - Sorry for spamming!!! xD
I have a SubTypes deserializing beautifully, but when serializing a sub type, it isn't populating the key specied, is there a step that i'm missing?
@JsonTypeInfo(use = JsonTypeInfo.Id.NAME,
property = "pxObjClass",
include = JsonTypeInfo.As.EXTERNAL_PROPERTY)
@JsonSubTypes.Type(value = Payslip.class,
name = "Data-Payslip"),private Payslip payslip;payslip type determinator pxObjClass field is null on serialization :(
1 reply
when i run a standalone use case, the JSON is generated as expected. When run through jackson-jaxrs provider.. i’m getting the “@“ prefixes. I have several other jax-rs service using similar patterns for models and this behavior is not observed
data comes out like this… { "@name”:"testName”, … }
so perhaps JAX-RS implementation is not configured with JAckson but Jettison or ... what was the name of that Oracle's JAXB implementation that also tries to do json....
ah. MOXy. It's fine for xml but due to xml background, not that good for json (IMO of course :) ).
@cowtowncoder that was is
damn transitive dependencies
thanks!
@sharipovshoxrux that is not enough to know much about your situation, but I guess it might be this: FasterXML/jackson-databind#2900
I try to use a mixin to use a custom deserializer for a class (Lets say
Pet) . Inside of the custom deserializer, I deserialize the class with a regular BeanDeserializer and then set an additional value, which I retrieve from an annotation. Deserializing Pet with a BeanDeserializer, causes a BeanDeserializer to be cached for the typ Pet.class. From this point on, the custom deserializer from the mixin is simply ignored. Is this supposed to be like that?
3 replies