[Bug] UnsafeDeserializer does not honor field default initializations

[edoclin]

Pre-check

• I am sure that all the content I provide is in English.

Search before asking

• I had searched in the issues and found no similar issues.

Apache Dubbo Component

Java SDK (apache/dubbo)

Dubbo Version

Apache dubbo： 3.3.4, java 8, hessian-lite 4.0.3

Steps to reproduce this issue

hessian-lite/src/main/java/com/alibaba/com/caucho/hessian/io/UnsafeDeserializer.java#instantiate
hessian-lite/src/main/java/com/alibaba/com/caucho/hessian/io/JavaDeserializer.java#instantiate

Migrating from dubbo2 to dubbo3, some entity classes still initialize default values, for example:

public class Example { private String all = "all"; }

UnsafeDeserializer constructs objects via allocateInstance; in certain scenarios, the deserialized object ends up with obj.all = null rather than the default obj.all = "all".

Using the startup parameter -Dcom.caucho.hessian.unsafe=false switches the deserializer to hessian-lite/src/main/java/com/alibaba/com/caucho/hessian/io/JavaDeserializer.java, which effectively solves the field default value issue.

However, when JavaDeserializer deserializes BigInteger with a null constructor argument, it throws an NPE (compared to dubbo2.7: com.alibaba.com.caucho.hessian.io.BigIntegerDeserializer provides a dedicated compatibility class).

Is there a method to make UnsafeDeserializer honor field default initializations, or a way to make JavaDeserializer compatible with BigInteger deserialization?

What you expected to happen

Provide a plan for ensuring deserialization compatibility during the migration process.

Anything else

No response

Are you willing to submit a pull request to fix on your own?

• Yes I am willing to submit a pull request on my own!

Code of Conduct

• I agree to follow this project's Code of Conduct

[RainYuY]

As an unsafe model, I don't think we should change the default initialization action. Because this will also cause some compatibility problems, but I think maybe we can add BigIntegerDeserializer back. @AlbumenJ

[zrlw]

As an unsafe model, I don't think we should change the default initialization action. Because this will also cause some compatibility problems, but I think maybe we can add BigIntegerDeserializer back. @AlbumenJ

Not only BigInteger, but also EnumSet, SimpleTimeZone, AbstractChronologyHandle ... have the same problem if you add -Dcom.caucho.hessian.unsafe=false to the mvn test command of dubbo-hessian-lite.

[zrlw]

UnsafeDeserializer constructs objects via allocateInstance; in certain scenarios, the deserialized object ends up with obj.all = null rather than the default obj.all = "all".

@edoclin could you provide an unit test? i can't reproduce what you said with such codes based on SerializeTestBase of dubbo-hessian-lite (https://github.com/apache/dubbo-hessian-lite/blob/master/java-8-test/src/test/java/com/alibaba/com/caucho/hessian/io/base/SerializeTestBase.java) :

import com.alibaba.com.caucho.hessian.io.base.SerializeTestBase;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;

import java.io.IOException;
import java.io.Serializable;
import java.math.BigInteger;
public class SampleTest extends SerializeTestBase {
   @Test
    void testSample() throws IOException {
        Sample sample = new Sample();
        Sample result = baseHessian2Serialize(sample);
        Assertions.assertEquals(sample.bigInteger, result.bigInteger);
        Assertions.assertEquals(sample.all, result.all);
    }

    private static class Sample implements Serializable {
        private BigInteger bigInteger = new BigInteger("1234567890");
        private String all = "all";
    }
}

[edoclin]

could you provide an unit test? i can't reproduce what you said with such codes based on SerializeTestBase of dubbo-hessian-lite

@zrlw

Unit tests cannot reproduce this issue. In real business scenarios, there is a Dubbo invocation where the consumer relies on version 1.0.0 , with the parameter defined as:

public class MsgGetReq implements Serializable {
    private short appId;
}

However, the provider has upgraded its dependency to version 1.0.1, where the parameter is defined as:

public class MsgGetReq implements Serializable {
    // To accommodate certain changes in business requirements, we adopt adding default values to ensure compatibility with calls from version 1.0.0.
    private short type = 1;
    private short appId;
}

Because the consumer’s serialized data does not include the type parameter, the provider, during deserialization, does not trigger Unsafe initialization for the type field, causing its default value to remain null .

[zrlw]

You might encounter other trouble if you set -Dcom.caucho.hessian.unsafe=false since there are many deserializations of dubbo hessian lite depend on it.
maybe your provider should be refactored like this:

public class MsgGetReq implements Serializable {
    private short type;
    private short appId;
    public MsgGetReq() {
        type = 1;
    }
}