This fixes https://github.com/protocolbuffers/protobuf/issues/26058
Mechanically, this adds tracking to MessageSchema in the intArray to include bufferIndex offsets of one member of each oneof in a message. Then in the equals function, when iterating all fields, we skip the oneof fields and do a supplemental pass over the intArray to cover the representative members of the oneofs.
In the course of adding this, I noticed we no longer needed the intArray to track repeated fields so I removed that. This means that this change is likely a net improvement in memory usage for MessageSchemas too as the number of oneofs in the universe of proto is likely much smaller than the number of repeated fields.
PiperOrigin-RevId: 877446720
schemaFor is a very hot method, called for every message we process. We only fall through to creating the schema the first time for each class, thereafter, the hot path is just getting from the ConcurrentHashMap.
Avoid R8 inlining the slow (less common) path of schemaFor. The inlining blows up the stack frame size and slows down the hot path.
PiperOrigin-RevId: 874384247
This is a functional no-op but has fringe benefits.
Having having the constant in the Internal class makes it a static init property which has some small but undesirable implications. The specific prompt of making this change is that it was discovered that when appreduce is inline-eliminating an Internal.checkNotNull it still needs to emit the bytecode ensure that this static init is run, as the static init is an observable side effect of calling that method. The only actual side effect that this could have is if these threw an exception, which would actually be _extremely bad_ if it ever actually happened in reality, but never will throw with these particular string literals that we use, so slightly bloating bytecode just to maintain a "would break everything if its not a no-op" feels bad.
StandardCharsets was added in Java 7, and so this was not available to use when this design was initially set up.
PiperOrigin-RevId: 872430237
StreamDecoder now uses a minimum buffer size of 8 to ensure all fixed-width reads can be handled using the buffer. New tests are added to verify this behavior.
While here, create a test-only variant of ByteArrayInputStream that retains the same semantics as InputStream.read(byte[],int,int) for better test fidelity.
PiperOrigin-RevId: 868144899
For historical reasons, our internal copy of the codebase uses
`proto2_unittest` while the open source one uses `protobuf_unittest`. This adds
a lot of friction to syncing between the two, and there's no great reason to
keep maintaining this difference, so let's just go with `proto2_unittest`.
PiperOrigin-RevId: 721951543
The default name for the rules_jvm_external.maven rule is "maven". When not set, it defaults to "maven". For root modules also using rules_jvm_external, the name clash causes a warning:
```
DEBUG: $TMP/external/rules_jvm_external~/private/extensions/maven.bzl:154:14:
The maven repository 'maven' is used in two different bazel modules,
originally in '<my_workspace>' and now in 'protobuf'
```
Summarizing @shs96c in [1]:
> The common maven repo name allows rulesets to contribute to the user's JARs.
> However, this implies that maven is for the end user, not for transitive
> dependencies. If a ruleset needs private dependencies, it should use a custom
> namespace rather than the maven namespace.
Since protobuf is not contributing to user's JARs, we'll use a custom namespace. There's precedent for using a custom namespace for library modules:
- rules_jvm_external uses `rules_jvm_external_deps` instead of `maven`.
- rules_kotlin uses `kotlin_rules_maven` instead of `maven`.
[1]: https://github.com/bazel-contrib/rules_jvm_external/issues/916#issuecomment-1645527584Fixes#16839.
Closes#18641
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/18641 from jschaf:joe/protobuf-maven bd2c62f311
PiperOrigin-RevId: 684625084
We mostly use generated pom files in our release currently, so we can delete all the files that aren't used and the tools to update them.
Note, java/bom/pom.xml java/pom.xml and java/protoc/pom.xml are all still used at release and java/kotlin/pom.xml is used for documentation so all of those need to stay for now.
PiperOrigin-RevId: 659664012
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
They are not needed after the rules are move into protobuf repo.
Except for the reference to toolchain type, which is currently in rules_proto and can be moved after the implementation is moved into protobuf repo.
PiperOrigin-RevId: 622176865
This also fixes maven to package this correctly as google/protobuf/java_features.proto (same dir as WKT/descriptor.proto) instead of com/google/protobuf/java_features.proto.
Fixes https://github.com/protocolbuffers/protobuf/issues/16155
PiperOrigin-RevId: 619015714
GeneratedMessage, not GeneratedMessageV3.
Please rerun protoc on your .proto files to regenerate the binding code.
https://protobuf.dev/news/2023-12-05/https://protobuf.dev/support/cross-version-runtime-guarantee/
To fix source compatibility with surrounding code make these replacements:
GeneratedMessageV3 --> GeneratedMessage
SingleFieldBuilderV3 --> SingleFieldBuilder
RepeatedFieldBuilderV3 --> RepeatedFieldBuilder
PiperOrigin-RevId: 597642289
