The java generator currently uses the enum-typed getters in mergeFrom for explicit presence fields, even for open enums. This results in buggy behavior where unknown enum values can trigger runtime exceptions during merges. It is reproducible in proto3 by using the `optional` keyword, but is more noticeable in edition 2023 due to the feature defaults.
PiperOrigin-RevId: 713780284
This brings it into conformance with our spec and other languages. Some parse paths already did this check, and all of them prohibit *nested* unmatched end-group tags.
PiperOrigin-RevId: 705225060
Fixes protocolbuffers#10697: UnsafeDirectNioDecoder modifies shared buffer instance when performing aliased read.
I've included a test-ish reproducer in form of a unit test that fails fairly reliably, let me know whether you'd want this merged.
Closes#19405
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/19405 from mernst-github:mernst/aliasing 1d972091c3
PiperOrigin-RevId: 703588369
The proto
message A {
SomeMessage text_field = 1;
SomeMessage text = 2;
}
will fail java compilation with a name clash: `method getTextFieldBuilder() is already defined in class...` This is because the `text` field creates a private method (`get{Text}{FieldBuilder}`) which conflicts with the public getter (`get{TextField}{Builder}`) for field 1.
Unlike some name clashes, this one is with a private method and we can just rename the method in this file. Other name clash issues:
- https://github.com/protocolbuffers/protobuf/issues/15411
- https://github.com/protocolbuffers/protobuf/issues/17367
There's some precedent for the `internal` prefix with the protected `internalGetFieldAccessorTable` method on GeneratedMessage.
PiperOrigin-RevId: 694108040
Technically these methods fail either if the field is primitive (non-message) or if the field is repeated. However it is confusing to have a repeated message field claim to be of type 'message' and then fail with an error message that claims you need a message type.
PiperOrigin-RevId: 693789370
Because not everything is supported in j2cl and j2objc some of the methods had to be marked as incompatible (reflection , String.format...)
PiperOrigin-RevId: 691368238
For most _native_ loads of Java rules (e.g. java_library), these can be automatically handled by Bazel 8's autoload feature.
However, this is not the case when the main repository (IOW, the repository currently being built) is a rule repo itself. In those cases, module dependencies are not automatically loaded.
This PR fixes a compatibility issue of OSS protobuf Bazel rules with other Bazel rule repositories such as bazelbuild/rules_android.
Without this PR, builds within rules repositories with Bazel 8 will fail like so:
```
external/protobuf+/java/core/BUILD.bazel:142:13: @@protobuf+//java/core:lite: no such attribute 'srcs' in 'java_library' rule
```
PiperOrigin-RevId: 690735533
The JVM regex engine allocates garbage on every match (especially when calling Matcher.usePattern!). Since there are expected to be a lot of tokens, this caused substantial GC overhead.
Direct char scanning also opens the possibility of other optimizations that aren't possible with regexes. For example:
- direct reads from a char[]
- streaming tokenization (rather than reading the complete source text)
PiperOrigin-RevId: 689230675
It's not used by generated code, contrary to the comment.
The 2-arg version of the method was used in gencode for one day (2025-04-08 through 09): cl/90574926 to cl/90648831.
PiperOrigin-RevId: 688268752
This fixes parsing of invalid second value long to throw the correct exception. Most users should already be handling ParseExceptions e.g. for invalid nanos
PiperOrigin-RevId: 686281774
Extend our Java OSGi library to have a version that works for Kotlin. Add a `protobuf_versioned_kt_jvm_library` that creates a bundle with the OSGi manifest and call that instead of `kt_jvm_library` for all our kotlin maven release targets.
Closes#18812
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/18812 from deannagarcia:kotlinOSGi 81bab06f61
PiperOrigin-RevId: 686220820
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
If the first check passed (we're an ArrayList) then we aren't a ProtobufArrayList, and there's no point checking.
Micro-optimisation.
PiperOrigin-RevId: 683793700
I think all these generics only change things at compile-time, not at runtime. So should be safe.
It's not a huge win; there's still some unchecked casts. But I was able to remove some unchecked casts, and some warning suppressions, so it's incrementally better.
PiperOrigin-RevId: 683793374
See godbolt for Android ART compiler: https://godbolt.org/z/M9dWhdqbf
This optimisation brings the implementation down from 284 bytes to 272 bytes.
- `GeneratedMessage$Builder SingleFieldBuilder.getBuilder() [284 bytes]`
- `GeneratedMessage$Builder SingleFieldBuilder.getBuilder__withLocalVariable() [272 bytes]`
It's not big. It's just a few instructions dropped. These were dropped just before the `ret`:
```
-mov x23, x1
-ldr w0, [x23, #8]
```
And this load dropped before calling `markClean`.
```
-ldr w1, [x23, #8]
```
PiperOrigin-RevId: 683619150
https://docs.oracle.com/javase/specs/jls/se10/html/jls-5.html#jls-5.1.3
The JLS guarantees this is the same:
> A narrowing conversion of a signed integer to an integral type T simply discards all but the n lowest order bits, where n is the number of bits used to represent type T. In addition to a possible loss of information about the magnitude of the numeric value, this may cause the sign of the resulting value to differ from the sign of the input value.
PiperOrigin-RevId: 683416604
https://docs.oracle.com/javase/specs/jls/se10/html/jls-5.html#jls-5.1.3
The JLS guarantees this is the same:
> A narrowing conversion of a signed integer to an integral type T simply discards all but the n lowest order bits, where n is the number of bits used to represent type T. In addition to a possible loss of information about the magnitude of the numeric value, this may cause the sign of the resulting value to differ from the sign of the input value.
In practice, Android's optimising compiler saw that this was unnecessary, and skipped generating 'and' instructions. So this isn't a performance boost, just a cleanup.
PiperOrigin-RevId: 683395327
Protobuf Team Bot
Xufei Tan
Protobuf Team Bot
Mike Kruskal
Matthias Ernst
Mark Hansen
Kurt Alfred Kluever
cpovirk
nickreid
Deanna Garcia
Ted Xie
Sandy Zhang
deannagarcia
Joe Schafer
Anuraag (Rag) Agrawal