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
I also considered using Collections.emptyNavigableMap(), which I thought might
use a specialized allocation free empty iterator, but it allocates, and its
clone() method isn't nicely exposed.
PiperOrigin-RevId: 630234849
Instead of _builder.getFoo() and _builder.setFoo(value), the generated code now uses _builder.foo and _builder.foo = value. When compiling against the Java Proto API, this makes no difference, since the Kotlin compiler treats Java methods getFoo/setFoo as defining a Kotlin property foo. But if a compatible proto API is implemented in Kotlin then there is no such equivalence. Such an implementation would have to define either both forms or just the one that the DSL uses. For a Kotlin API it is more natural to use properties.
Similarly, the generated Java methods getFoosList(), getFoosCount(), getFoosMap(), and getEnumValue() are accessed via property names (foosList, foosCount, foosMap, enumValue).
(This is the second application of this change. The first had to be rolled back because it didn't handle conflict-resolution names correctly.)
PiperOrigin-RevId: 629807104
Provide a specialization for ListAdapter that avoids boxing ints into Integers.
Use this for repeated enum accessors.
In practice, the ints for most enums will fit into the JDK's "boxed int cache", avoiding extra allocations. For large enum numbers, they won't fit, and would allocate. Removing the boxing should also slightly speed up code.
PiperOrigin-RevId: 629583247
Instead of `_builder.getFoo()` and `_builder.setFoo(value)`, the generated code now uses `_builder.foo` and `_builder.foo = value`. When compiling against the Java Proto API, this makes no difference, since the Kotlin compiler treats Java methods `getFoo`/`setFoo` as defining a Kotlin property `foo`. But if a compatible proto API is implemented in Kotlin then there is no such equivalence. Such an implementation would have to define either both forms or just the one that the DSL uses. For a Kotlin API it is more natural to use properties.
Similarly, the generated Java methods `getFoosList()`, `getFoosCount()`, `getFoosMap()`, and `getEnumValue()` are accessed via property names (`foosList`, `foosCount`, `foosMap`, `enumValue`).
PiperOrigin-RevId: 629220383
Previously, these List.get methods returned Object, forcing boxing, and (if not in the primitive's box cache) allocation, with all the cost that entails.
I've taken the approach of duplicating methods to specialise for primitives, like BinaryWriter does for non-lite protos.
I initially considered checking the class of the list on every iteration of the
loop, but that feels wasteful, when we can
check it once at the start of the loop. This also means we have the same
behaviour as serverside protos. At the cost of a few more methods, but
hopefully they're trivially inlineable, so hopefully leading to a small dex increase without really increasing the method count.
Given this is a public API, I don't think we can remove the List<Long> overloads either.
PiperOrigin-RevId: 627183583
Once an edition is released these should be fixed forever. On the other hand, the fixed defaults may see new features included as we change legacy behaviors in future editions.
PiperOrigin-RevId: 625842071
The new fields fixed_features and overridable_features can be simply merged to recover the old aggregate defaults. By splitting them though, plugins and runtimes get some extra information about lifetimes for enforcement.
PiperOrigin-RevId: 625527117
The only public target here is the edition defaults helper macro, which can be used by external runtimes and plugins. None of this code is C++-specific though, and should be organized higher up. Appropriate aliases are also placed at the top level for public targets
PiperOrigin-RevId: 625392504
Protobuf Team Bot
Protobuf Team Bot
Mark Hansen
Mike Kruskal
Sandy Zhang
Éamonn McManus
Mike Kruskal