fix: JavaBeanSerializeUtil handles null key in Map serialization

[waterWang]

What is the purpose of the change

Fixes #16432: JavaBeanSerializeUtil.serialize() throws IllegalArgumentException("Property name is null") when serializing a Map that contains a null key.

HashMap permits exactly one null key, so this is a legal input. The Map branch in serializeInternal explicitly handles null keys (key == null ? null : createDescriptorIfAbsent(...)), but the descriptor produced is then rejected by the notNull check in JavaBeanDescriptor.setProperty().

Root cause

In JavaBeanSerializeUtil.serializeInternal() Map branch:

map.forEach((key, value) -> {
    Object keyDescriptor = key == null ? null : createDescriptorIfAbsent(key, accessor, cache);
    Object valueDescriptor = value == null ? null : createDescriptorIfAbsent(value, accessor, cache);
    descriptor.setProperty(keyDescriptor, valueDescriptor);
});

When the map has a null key, keyDescriptor is null, and JavaBeanDescriptor.setProperty(null, value) throws because of the notNull(propertyName, "Property name is null") guard.

Fix

Relax the notNull guard in JavaBeanDescriptor.setProperty() for map-type descriptors only — a null key is a legal Map key and LinkedHashMap (the backing storage) supports it. Bean/array/collection/class/enum descriptors keep the original null check.

Verification

• Added testSerialize_MapWithNullKey (round-trip test: map with a null key serializes, deserializes, and preserves both key-value pairs)
• Existing JavaBeanSerializeUtilTest suite unaffected

Checklist

• I have read and agree to the Contributor Guidelines
• I have added tests that prove my fix is effective
• The PR targets the 3.3 branch

[codecov-commenter]

Codecov Report

❌ Patch coverage is 50.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 36.90%. Comparing base (6054104) to head (64f1c89).
⚠️ Report is 5 commits behind head on 3.3.

Files with missing lines	Patch %	Lines
...ache/dubbo/common/beanutil/JavaBeanDescriptor.java	50.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##                3.3   #16435      +/-   ##
============================================
- Coverage     36.93%   36.90%   -0.03%     
+ Complexity    11752    11744       -8     
============================================
  Files          1952     1952              
  Lines         89249    89250       +1     
  Branches      13389    13389              
============================================
- Hits          32961    32940      -21     
- Misses        51710    51724      +14     
- Partials       4578     4586       +8     

Flag	Coverage Δ
integration-tests-java21	32.08% <50.00%> (+<0.01%)	⬆️
integration-tests-java8	32.21% <50.00%> (+<0.01%)	⬆️
samples-tests-java21	32.17% <0.00%> (-0.01%)	⬇️
samples-tests-java8	29.80% <0.00%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[LI123456mo]

Hi @waterWang , Nice fix . I've gone through the both issue and PR ; confirmed the deserialize round-trip path doesn't hit this (it iterates properties directly via iterator(), bypassing getProperty/containsProperty). But since JavaBeanDescriptor is a public class, wouldn't calling getProperty(null) or containsProperty(null) directly on a map-type descriptor still throw, given they don't have the same isMapType() exemption? Worth applying the same exemption there for API consistency, even if nothing internal currently exercises that path.