This only changes the sort order in an obscure edge case of map-keys which sort differently in Utf8 and Utf16, meaning a mix of certain characters that are "very high code point but still single char" and "utf16 surrogate pairs".
PiperOrigin-RevId: 922768203
JsonFormat used 'reader.setLenient(false)' to try to get spec JSON behavior out of GSON. However, this mode was still not actually spec JSON. In ~2024 GSON deprecated setLenient(), made that behavior LEGACY_STRICT and added a new level STRICT which is intended to be spec.
Switching unilaterally would be a breaking change for Protobuf: this change just adds the option for users to ask us to use GSON in strict mode. At a later date we will consider flipping the default of this (letting people opt into LEGACY_STRICT if they want to).
PiperOrigin-RevId: 921432331
## Summary
`BigDecimal(String)` has O(N²) time complexity for N-digit strings on JDK versions before 18 ([JDK-8291514](https://bugs.openjdk.org/browse/JDK-8291514)). Five JSON parser methods — `parseInt32`, `parseInt64`, `parseUint32`, `parseUint64`, and `parseDouble` — pass user-controlled strings directly to `new BigDecimal()` without length validation.
A single JSON numeric value with 1,000,000 digits takes ~13 seconds to parse on JDK 17. This can be used to DoS any service that parses protobuf JSON messages with numeric fields from untrusted input.
### Benchmark (JDK 17, x86-64 Linux)
| Digits | BigDecimal construction time |
|--------|-----|
| 1,000 | 1.8 ms |
| 10,000 | 6.3 ms |
| 100,000 | 133 ms |
| 1,000,000 | **13.1 seconds** |
### Fix
Added a `parseBigDecimal()` helper that rejects strings longer than 1000 characters before constructing `BigDecimal`. This is generous — valid protobuf numeric values never exceed ~350 characters (Double.MAX_VALUE in non-scientific notation is ~309 digits).
### Affected JDK versions
- JDK 8, 11, 17 (all current LTS releases): **Vulnerable** — no built-in string length limit in BigDecimal
- JDK 18+: JDK itself limits BigDecimal string input to 1100 characters by default (JDK-8291514), but the protobuf-level check is still worthwhile as defense-in-depth
### Test
Added `testParserRejectOverlyLongNumericStrings` covering all 5 affected field types.
Closes#26908
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/26908 from MindflareX:fix/java-bigdecimal-length-check a461d0edc6
PiperOrigin-RevId: 904988136
This fixes as issue where extension names were incorrectly printed using their short name which prevents parsing and can lead to ambiguous or duplicate json keys.
This feature is gated by a boolean options printingFullyQualifiedExtensionNames and printingShortExtensionNames for testing. These methods are held back from the public API for now.
PiperOrigin-RevId: 875322649
This change adds base tests case for printing proto2 extensions. It highlights a known issue with parsing extensions as short names and duplicated field names.
PiperOrigin-RevId: 873022900
The pyi generator now includes Kythe annotations for:
* Extension field constants (e.g., `EXTENSION_FIELD`).
* Field number constants (e.g., `STRING_FIELD_FIELD_NUMBER`).
* `Create` methods in generated Stubby client classes.
These annotations allow the Python indexer to link these generated symbols back to their definitions in the `.proto` files.
PiperOrigin-RevId: 852971617
The annotations will be handled in a subsequent change.
The change to use java.lang.String.split() instead of Guava's Splitter does introduce behavior changes in the case of handling of degenerate/malformed FieldMask paths (paths like `a///`). The handling of malformed paths shape are already arbitrary and inconsistent between the different methods in this file, and callers should not construct such paths. In a future change we may consider validating and throwing an IllegalArgumentException on such malformed paths more explicitly.
https://github.com/protocolbuffers/protobuf/issues/21173
PiperOrigin-RevId: 795126095
Existing FieldMaskUtil#trim method behavior remains the same: unset primitive fields specified in the field mask will be explicitly set to their default values after trimming.
PiperOrigin-RevId: 754114689
Otherwise, protobuf_maven_dev may provide a different version from a transitive dep, which can result in the wrong version being selected (e.g. when used for bazel-generated maven artifacts).
Also updates protobuf_util_bundle to use protobuf_maven instead of protobuf_maven_dev which is probably more appropriate since its control the deps in the pom.xml file for maven users (though this is functionally the same rn).
Fixes https://github.com/protocolbuffers/protobuf/issues/20710
PiperOrigin-RevId: 738887165
This method has existed since Java 8, released in 2014.
Also adjust the tests so that they verify unsigned integer values that are too big for the signed counterpart (for example, 4294967295 which fits in `uint32` but not `int32`).
We don't use the parallel `Long.parseUnsignedLong` because the existing code handles inputs like `"1.0"`.
PiperOrigin-RevId: 723945649
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
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
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
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
