The old implementation tried to emit only the canonical values in the 'chunked' ranges and then emit aliases separately at the top level, which led to a number of problems including:
- On reflective lookup, it indexed into the values() array based on the all-value-index but that array only contained canonical-values. This is fixed to match the non-Large implementation where the public values() still returns only canonicals, but there's a second private array which contains all values for index-based indexing.
- The static init dependency graph potentially had cycles which could leave values as null if they were touched in the 'wrong' order.
This changes switches it to instead chunk up all enum values based on the original index range, unrelated to if they the value is an aliases or not. The non-aliases remain constructed as normal, the aliases are declared in their index-order but name the corresponding canonical value directly by its chunk (eg the SomeEnum2 chunk could have something like `public static final SomeEnum X_ALIAS = SomeEnum0.X`).
Since the definition of alias is "the lowest index of a given value is the canonical one and any higher index with same value are aliases", this should avoid init cycles since the aliases will only point to some chunk which is <= its own chunk.
PiperOrigin-RevId: 815717989
* FileJavaPackage - matches C++, no ambiguity
* FileClassName - matches C++ and our new style
* BytecodeClassName - returns the fully qualified java names using '$' separators for inner classes. C++ will be similarly renamed from JavaClassName
* QualifiedClassName - returns the fully qualified java names using '.' sepators for inner classes. C++ will be similarly renamed from ClassName
PiperOrigin-RevId: 814414729
There appear to be no callers of this.
I'm removing this in preparation to try to offer a more performant
java.lang.ClassValue replacement for the ConcurrentHashMap.
Removing this method means I don't have to reimplement it for ClassValue.
PiperOrigin-RevId: 814272309
Introduces a new annotation that can be used specifically for hiding Kotlin generated functions that cause name collisions in Objective-C.
PiperOrigin-RevId: 814251585
Empirically in 2025 this appears to be faster than our implementation that tries to hand roll this and avoid a string copy and use sun.misc.Unsafe (and much faster in the case of ascii strings).
The JDK implementation is able to leverage the internal representation of the strings when encoding, including that it can have a very fast path for "internal representation is Latin1 and the string happens to be ascii, then it is already utf8". The exposed Java API unfortunately demands us have a temporary copied array here, but it empirically doesn't show up as a regression to have this shortlived object and copy.
This delta is only changing UnsafeProcessor path which is currently held back from Android, so its OK that this was only benchmarked on server and we don't need to worry about a regression on Android at this time.
PiperOrigin-RevId: 813904984
The reason to change this back is that one purpose of this method to provide a good message when e.g. someone tries to use 4.33.0 gencode against 4.30 runtime. The 4.30 runtime only has the `String` argument method, so by having new gencode try to call the `Class` one it will result in ABI behavior of a NoSuchMethodError instead of getting the clean message when that 'bad direction skew' happens.
This partial-rollback tries to retain the benefit of avoiding the small cost of the .class.getName() call by having new gencode simply emit the name as a string literal like `"MyMessageProto"` instead of `MyMessageProto.class.getName()` when calling the poison pill.
Because we didn't do any open source releases with this change quite yet, we can remove the `Class` overload here instead of it having to linger forever.
PiperOrigin-RevId: 813433985
Before this, the poison pill intended to require exact match including suffix if there were suffixes on either gencode or runtime.
After this change:
- If gencode is suffixed, it must be exact match to runtime (including suffix).
- If runtime is suffixed and gencode is not suffixed, the gencode must be a strictly lower major.minor.point (4.32.1-rc1 runtime must be on <= 4.32.0 gencode). We log a warning once if this allowed inequality state happens.
This change also fixes a bug where a lower minor version was allowed if it did have the same suffix (4.33.0-rc1 runtime accidentally accepted 4.32.0-rc1 gencode while still rejecting 4.32.0).
PiperOrigin-RevId: 813286207
The information doesn't seem very useful for debugging, and it isn't possible to have the char+index be accurate while allowing for fast-failure paths that can know an input string won't fit but can't possibly know the exact character that is at the boundary without doing a lot of expensive work instead.
The unit test already reflected the oddity that what it printed wasn't consistent/predictable depending on if it was going to hit a fast-path or not, and that test is fixed to shown the consistency after this change.
PiperOrigin-RevId: 810954092
Having overloads of the subtypes is unnecessary for source compatibility (where javac will resolve the type to the base type method), but removal of them an ABI break if .class files compiled against PBJ 3.x are used with PBJ 4.x.
PiperOrigin-RevId: 805035553
This just sets up the transform and implements one piece of it. Specifically, it updates the edition to 2024 and migrates feature dependencies to `import option`. Further transforms will be added in later changes.
PiperOrigin-RevId: 803656952
The logic is duplicated across both. Rather than have both, we just optimize `inferLegacyProtoFeatures()` to only return a new instance when the features would be set. This ensures there is only one source of truth and we do not need to worry about the two functions coming out of sync.
PiperOrigin-RevId: 803146647
This is just a cleanup which more closely enforces the fact that a field descriptor can either reference a message type or enum type, never both.
PiperOrigin-RevId: 802550883
94a2a44851
Having overloads of the subtypes is unnecessary for source compatibility (where javac will resolve the type to the base type method), but removal of them an ABI break if .class files compiled against PBJ 3.x are used with PBJ 4.x.
PiperOrigin-RevId: 800614750
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
When setting a repeated field to an empty list, clear the corresponding entry in the `FieldSet`. Otherwise the resulting message wouldn't be treated as equal to an empty message, even though it is.
Generated messages already have the same behavior.
PiperOrigin-RevId: 795044555
This is in line with the larger goal of making `CodedOutputStream` not depend on specific message representations, which `LazyFieldLite` is.
PiperOrigin-RevId: 793672999
Updates tests to avoid setting java features on this proto, since its used frequently in custom pools in unit tests (descriptor_unittest.cc, command_line_interface_unittest.cc) which would require adding the addl. dep in a bunch of places.
PiperOrigin-RevId: 791866799
Generated code from this range is covered by CVE-2022-3171 and potentially vulnerable to a Denial of Service issue.
JavaProto 4.x previously dropped compatibility with the potentially vulnerable generated code, having the behavior of:
* The vulnerable generated code was source-incompatible with new runtime (would not compile when built from source)
* The vulnerable generated code was ABI-incompatible with new runtime (when using a .class file compiled against old runtime, a NoSuchMethodException would be thrown at parse time).
After this change, instead:
* The vulnerable generated code is now source-compatible (will compile).
The first time each potentially vulnerable type is parsed, an error message will be logged noting that potentially vulnerable generated code is in use and the name of the corresponding type.
* Environment variables may be set to either throw an exception instead (-Dcom.google.protobuf.error_on_unsafe_pre22_gencode) or to entirely silence the logged messages (-Dcom.google.protobuf.use_unsafe_pre22_gencode)
This change was made based on community feedback regarding the difficulty in identifying and quickly remediating stale gencode in their transitive dependencies weighed against a careful evaluation of the realistic risk exposure of DoS (with no risk of other concerns including information leak or RCE).
We strongly recommend that any users who observe the log messages to regenerate the corresponding code with a newer protoc. We recommend that any security-conscious services opt into error_on_unsafe_pre22_gencode to preclude any risk of a Denial of Service surface area being exposed.
A future release may flip the default behavior to error by default as a measure to further help the ecosystem avoid the Denial of Service risks.
PiperOrigin-RevId: 790798112
