profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/prb/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

prb/bigbird 28

An attempt to create a Twitter-like beastie backed by big data storage.

leithaus/Rosette 25

Reflective actor-based language

prb/perpubplat 6

Experimental Haskell blog publishing.

GollumEvent

created repositoryjstrachan/jx-demo-minikube

created time in 2 days

GollumEvent
GollumEvent
GollumEvent

issue commentFasterXML/jackson-jr

Deserializes "null" to "0.0" in big-D Double

Hmmh. On this particular problem, I realized that this is bit trickier because deserializer side does not currently track primitive/tracker difference: internally there are numeric constants like ValueLocatorBase.SER_NUMBER_INTEGER which cover both primitive and wrapper variants (mostly since Reflection only deals with wrapped version), and thereby SimpleValueReader is passed the same int constant value for both. So that needs to be changed to separate handling. Not a big deal, just more work.

bill-phast

comment created time in 3 days

issue commentFasterXML/jackson-jr

Deserializes "null" to "0.0" in big-D Double

Thanks! Yes I can see the other side of it. I may write that pull request, it doesn't look like it would be too hard.

bill-phast

comment created time in 3 days

issue commentFasterXML/jackson-jr

Deserializes "null" to "0.0" in big-D Double

@bill-phast exactly. There are two quite different philosophies... and some people find it difficult to believe there is the "other side", too. :)

In this case behavior is definitely not intentional but oversight. But over time even unintended behavior becomes sort of de fact specification.

BTW, if you would like to get exception for "null for primitives" case, I'd be happy to add that as a JSON.Feature -- not sure if I have time to implement it immediately, but if you or anyone else wants to contribute a PR I do my best to help and get it merged. And at very least if you'd like to see it, please create a separate issue? We can mark it as "good first issue", too, as there are some devs who are looking for easier things to work on and this would be such, I think.

bill-phast

comment created time in 3 days

push eventFasterXML/jackson-jr

Tatu Saloranta

commit sha c29ed5ddc28e330d357ba2e0080006bccb71ef08

Add a link to: "Enable support for java.time.* with Jackson-jr" post

view details

Tatu Saloranta

commit sha 3f2ba4911f739cd99f1df9250ac2ee1957e0c6a6

Add failing tests wrt #78

view details

Tatu Saloranta

commit sha ef388573b180a3635d3518dfea20eb16dc425b1d

Merge branch '2.12' into 2.13

view details

push time in 3 days

push eventFasterXML/jackson-jr

Tatu Saloranta

commit sha c29ed5ddc28e330d357ba2e0080006bccb71ef08

Add a link to: "Enable support for java.time.* with Jackson-jr" post

view details

Tatu Saloranta

commit sha 3f2ba4911f739cd99f1df9250ac2ee1957e0c6a6

Add failing tests wrt #78

view details

push time in 3 days

issue commentFasterXML/jackson-jr

Deserializes "null" to "0.0" in big-D Double

Since I have my workaround in place I'm OK with waiting until 2.13. Thanks for listening.

I'm always in favor of strictness in serialization/deserialization; if I have a little-d double, and get a null, I'd rather see an exception thrown (since this means my schema doesn't match the data) than see it quietly turned into 0.0. But I know other people prefer the "do whatever it takes to shove the data into the bean" approach.

bill-phast

comment created time in 3 days

issue commentFasterXML/jackson-jr

Deserializes "null" to "0.0" in big-D Double

Yes, I agree that nulls should be preserved for wrapper types by default (and if there was a coercion, that'd be separate setting).

But I now realize that there's definitely the backwards-compatibility angle to consider... meaning that the change in behavior may need to wait until 2.13.0 (patch releases should minimize regression likelihood for users, and this is one of those possibly "bug or feature?" cases).

bill-phast

comment created time in 3 days

push eventFasterXML/jackson-jr

Tatu Saloranta

commit sha dd1b1fecc2a00416eea44a9940ac2371774cdaab

Minor fix to work with 3.0 jackson-core again

view details

push time in 3 days

issue commentFasterXML/jackson-jr

Deserializes "null" to "0.0" in big-D Double

Yes, it is. I found a workaround; add a reader/writer provider that provides this object when a reader for Double.class is needed:

    /**
     * Jackson Jr. by default converts null to 0.0. We need to keep it as null.
     */
    private static final ValueReader DOUBLE_READER = new ValueReader(Double.class) {
        @Override
        public Object read(JSONReader reader, JsonParser jsonParser) throws IOException {
            return jsonParser.currentToken() == JsonToken.VALUE_NULL ? null : jsonParser.getValueAsDouble();
        }
    };

But it seems it would be best to make this workaround unnecessary, to just preserve nulls. (I have verified that yes, Integer, and Float, and Character, all have this problem, all can be fixed by the same workaround technique. I guess I have some of complex beans.)

bill-phast

comment created time in 3 days

issue commentFasterXML/jackson-jr

Deserializes "null" to "0.0" in big-D Double

Thank you for reporting this, it does sound like a bug. I assume this is with 2.12.2?

bill-phast

comment created time in 3 days

push eventFasterXML/jackson-jr

Tatu Saloranta

commit sha eb68b6ffbbbded6fe53f6f8da3193dfb5e92fe35

...

view details

Tatu Saloranta

commit sha 0e38f1b5f890631bfca92f2731d028cf1ff54ff5

...

view details

Tatu Saloranta

commit sha 58b39e6a0b50e5b31aff3585f43896beb0ed2534

Merge branch '2.12' into 2.13

view details

Tatu Saloranta

commit sha 041286a283c1e0540f66ee7d6dc4bd7f14b67e2a

Merge branch '2.13'

view details

Tatu Saloranta

commit sha fe2d38d230dda75198846d7f7559992019f1844e

...

view details

push time in 3 days

push eventFasterXML/jackson-jr

Tatu Saloranta

commit sha 0e38f1b5f890631bfca92f2731d028cf1ff54ff5

...

view details

Tatu Saloranta

commit sha 58b39e6a0b50e5b31aff3585f43896beb0ed2534

Merge branch '2.12' into 2.13

view details

push time in 3 days

push eventFasterXML/jackson-jr

Tatu Saloranta

commit sha 0e38f1b5f890631bfca92f2731d028cf1ff54ff5

...

view details

push time in 3 days

issue commentFasterXML/jackson-jr

Deserializes "null" to "0.0" in big-D Double

Found out that big-B Booleans have the same problem. Most likely Integer, etc. as well.

bill-phast

comment created time in 3 days

issue openedFasterXML/jackson-jr

Deserializes "null" to "0.0" in big-D Double

When a bean has a big-d Double, and the value is null, it gets decoded as 0.0 instead. The two are not equivalent.

This code shows the problem:

package test;

import com.fasterxml.jackson.jr.ob.JSON;

import java.util.List;

public class DoubleTest {

    private Double value;

    public static void main(String[] args) throws Exception {
        for (var testInput: List.of(
            "{\"value\": 1.0}", "{\"value\": 0.0}", "{}", "{\"value\": null}")) {
            System.out.println("Input JSON: " + testInput + "  -  Output bean: " + JSON.std.beanFrom(DoubleTest.class, testInput));
        }
    }

    public Double getValue() {
        return value;
    }

    public void setValue(Double value) {
        this.value = value;
    }

    public @Override String toString() {
        return "DoubleTest[" + value + "]";
    }
}

Output:

Input JSON: {"value": 1.0}  -  Output bean: DoubleTest[1.0]
Input JSON: {"value": 0.0}  -  Output bean: DoubleTest[0.0]
Input JSON: {}  -  Output bean: DoubleTest[null]
Input JSON: {"value": null}  -  Output bean: DoubleTest[0.0]

The fourth JSON object should be deserialized the same as the third.

created time in 3 days

fork jstrachan/tekton-client-plugin

Trigger Tekton Pipelines from Jenkins

fork in 4 days

GollumEvent

push eventFasterXML/jackson-datatype-hibernate

Tatu Saloranta

commit sha 77c58df1d0a2987f2e54b5273a8db7f5cc11bdc6

Fixed #139: drop hibernate3 support

view details

push time in 4 days

issue closedFasterXML/jackson-datatype-hibernate

Drop support for Hibernate 3.x from Jackson 2.13

As per title: usage of jackson-datatype-hibernate3 is very low compared to hibernate4 and (especially) hibernate5. It also does not have all the functionality. Given this, there is little point in maintaining this variant so we'll drop it from Jackson 2.13.

closed time in 4 days

cowtowncoder
GollumEvent
GollumEvent
GollumEvent

startedtrinodb/trino

started time in 4 days

GollumEvent

startedFmstrat/youtube-dl-api

started time in 4 days