Conversation
java/fory-core/src/main/java/org/apache/fory/serializer/ArraySerializers.java
Outdated
Show resolved
Hide resolved
Co-authored-by: Shawn Yang <chaokunyang@apache.org>
...re/src/main/resources/META-INF/native-image/org.apache.fory/fory-core/reflection-config.json
Outdated
Show resolved
Hide resolved
...src/main/resources/META-INF/native-image/org.apache.fory/fory-core/serialization-config.json
Outdated
Show resolved
Hide resolved
...re/src/main/resources/META-INF/native-image/org.apache.fory/fory-core/reflection-config.json
Outdated
Show resolved
Hide resolved
java/fory-core/src/main/java/org/apache/fory/type/DispatchId.java
Outdated
Show resolved
Hide resolved
...re/src/main/resources/META-INF/native-image/org.apache.fory/fory-core/reflection-config.json
Outdated
Show resolved
Hide resolved
java/fory-core/src/test/java/org/apache/fory/serializer/Float16SerializerTest.java
Show resolved
Hide resolved
|
Could you also address those issues?
|
java/fory-core/src/main/java/org/apache/fory/serializer/Float16Serializer.java
Outdated
Show resolved
Hide resolved
| private void writeNullable(MemoryBuffer buffer, Float16[] value, int length) { | ||
| int bitmapSize = (length + 7) >>> 3; | ||
| int payloadSize = Integer.BYTES + bitmapSize + length * 2; | ||
| int encodedSize = (payloadSize << 1) | NULLABLE_ENCODING_FLAG; |
There was a problem hiding this comment.
This changes the FLOAT16_ARRAY wire layout when nulls are present, which will break cross-language readers that expect the normal length+payload format for type 53.
In xlang mode, other runtimes decode FLOAT16_ARRAY as plain [byte_length][2-byte elements]. Here we switch to an alternate encoded-size scheme for nullable arrays, so non-Java runtimes will misread the payload. Could we keep FLOAT16_ARRAY encoding stable and handle nullable cases another way (for example, fallback to LIST encoding when null is present)?
| public static final int EXT_UINT64 = 23; | ||
| public static final int EXT_VAR_UINT64 = 24; | ||
| public static final int STRING = 25; | ||
| public static final int FLOAT16 = 17; |
There was a problem hiding this comment.
Since FLOAT16 is now a basic dispatch id, FieldSkipper also needs a skip branch for it.
Right now FieldSkipper has no DispatchId.FLOAT16 case. In compatibility reads, skipping an unknown Float16 field will throw Unexpected basic dispatchId instead of advancing by 2 bytes. Please add FLOAT16 to the 2-byte skip branch.
| resolver.registerInternalSerializer(URI.class, new URISerializer(fory)); | ||
| resolver.registerInternalSerializer(Pattern.class, new RegexSerializer(fory)); | ||
| resolver.registerInternalSerializer(UUID.class, new UUIDSerializer(fory)); | ||
| resolver.registerInternalSerializer(Float16.class, new Float16Serializer(fory)); |
There was a problem hiding this comment.
Float16 gets registered twice (primitive serializer path and general serializers path).
This overrides the earlier registration and makes it harder to reason about which serializer is intended. It would be cleaner to keep a single registration point for Float16.
| if kind in (PrimitiveKind.FLOAT32,): | ||
| if kind in (PrimitiveKind.FLOAT16,): | ||
| comparisons.append( | ||
| f"({field_name} == null ? that.{field_name} == null : (that.{field_name} != null && {field_name}.equalsValue(that.{field_name})))" |
There was a problem hiding this comment.
Generated equals/hashCode for float16 now use numeric semantics, but Float16.equals/hashCode are bitwise.
With this change, +0 and -0 compare equal in generated messages, and NaN is not equal to NaN, while Float16 itself uses raw-bit equality. That mismatch is surprising in user code. Can we align generated message behavior with Float16.equals/hashCode (or make the rule explicit and consistent across runtimes)?
| return true; | ||
| } | ||
|
|
||
| public boolean add(float value) { |
There was a problem hiding this comment.
Float16List primitive methods still allocate Float16 objects on the hot path.
add(float), set(float), and getFloat(int) all go through Float16.valueOf/fromBits, so these paths allocate even though this is a primitive-style container. A static bits conversion helper would keep these methods allocation-free.
Why?
What does this PR do?
Related issues
Close #3205
Does this PR introduce any user-facing change?
Benchmark