This is a performance optimisation that avoids us going through from
AbstractList.add(E) to LazyStringArrayList.add(int index, String) and then
having to call the index-based add in ArrayList, which has more bookkeeping
around moving elements across if necessary.
We can avoid that bookkeeping by adding this overload.
Also, group together overloads to squash a style warning.
PiperOrigin-RevId: 650089286
This should slightly speed things up.
Should be safe: these operations don't change the number of entries inside the loop.
PiperOrigin-RevId: 650087172
I've made a new name for the interface, ExtensionSerializer, so we can keep ExtensionWriter in the same place for backwards-compatibility for a little while.
PiperOrigin-RevId: 644172922
These classes are deprecated and will be removed in the next breaking change. Users should update gencode to >= 4.26.x which uses GeneratedMessage instead of GeneratedMessageV3.
Tested with //compatibility:java_conformance_v3.25.0 which builds the runtime against 3.25.0 gencode.
PiperOrigin-RevId: 644136172
This extends previous workaround for java features in unknown fields, to include features extensions that are known but use a mismatched descriptor.
This can happen when users bring their own descriptors via buildFrom.
PiperOrigin-RevId: 644013578
This was introduced by the previous fix for delimited inheritance, and was never released. This fix removes all getType() calls from crosslink, where it's not safe to inspect the message type, which is still a placeholder, until after crosslinking. Using the inferred type is not necessary since we treat messages and groups the same during crosslink.
PiperOrigin-RevId: 643394981
This was previously fixed in C++ (https://github.com/protocolbuffers/protobuf/issues/16549), but not ported to other languages. Delimited field encoding can be inherited by fields where it's invalid, such as non-messages and maps. In these cases, the encoding should be ignored and length-prefixed should be used.
PiperOrigin-RevId: 642792988
Use old-style for loop instead.
This should speed up processes that serialize many unknown fields, and reduce some GC pressure.
PiperOrigin-RevId: 638889708
This should not be needed for generated code, but may be needed for user calls to the public buildFrom method. FileDescriptorProto should really be parsed with java features in the extension registry (like other extensions), but we can handle this in Java runtime to ease editions adoption.
PiperOrigin-RevId: 638715579
This should speed up serializing Extendable Messages (messages with extension ranges declared in their schema) if those message instances have no extensions set inside them at runtime.
PiperOrigin-RevId: 638087120
It's always set to 16 in production code.
Except for when it's set to 0 for the immutable empty SmallSortedMap, but the number doesn't change anything for that immutable empty map (it's always empty, it will never hit the max).
This should save 4 bytes of memory per SmallSortedMap.
PiperOrigin-RevId: 636035193
This reduces our code weight by a little (3 classes).
Collections.emptySet also has a singleton empty iterator, so it doesn't allocate.
PiperOrigin-RevId: 633667264
This prevents shadowing of `java.lang` package commonly used in protobuf gencode. Existing extensions named `java` may or may not previously fail to compile depending on if the contents of their .proto result in gencode using `java.lang`. This is needed to fix `java_features.proto` lite gencode since enum gencode uses `java.lang`. Fields named `java` should already be escaped.
*Warning: This may break user code for existing protos with extensions named `java`. References to the extension should be renamed to use `java_` e.g. registry.add(GeneratedClassName.java_)*
PiperOrigin-RevId: 632508249
Mark Hansen
Protobuf Team Bot
Sandy Zhang
Mike Kruskal
Éamonn McManus
Protobuf Team Bot