Skip to content

Commit 08c0ba5

Browse files
Add guidance to not create java_package collisions in files with different .proto packages
PiperOrigin-RevId: 819921607
1 parent a076d89 commit 08c0ba5

File tree

1 file changed

+30
-0
lines changed

1 file changed

+30
-0
lines changed

content/best-practices/dos-donts.md

Lines changed: 30 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -271,6 +271,36 @@ A common practice is to generate your protos into a `proto` subpackage in your
271271
project that **only** contains those protos (that is, no hand-written source
272272
code).
273273

274+
## **Do** Derive Java Package from the .proto Package (if overridden) {#derive-java-package}
275+
276+
Setting the `java_package` can introduce fully-qualified name collisions in
277+
generated code that did not exist in the .proto semantics. For example, these
278+
two files may create collisions in the generated code despite the
279+
fully-qualified names not colliding in the original schema:
280+
281+
```proto
282+
package x;
283+
option java_package = "com.example.proto";
284+
message Abc {}
285+
```
286+
287+
```proto
288+
package y;
289+
option java_package = "com.example.proto";
290+
message Abc {}
291+
```
292+
293+
To avoid these problems, you should never set the same `java_package` in two
294+
files that have different .proto packages set.
295+
296+
The best practice is to establish a local naming pattern where the package name
297+
is derived from the .proto package. For example, a best practice file with
298+
`package y` might consistently set `option java_package =
299+
"com.example.proto.y"`.
300+
301+
This guidance also applies to any other language-specific options where package
302+
overrides are possible.
303+
274304
## Avoid Using Language Keywords for Field Names {#avoid-keywords}
275305

276306
If the name of a message, field, enum, or enum value is a keyword in the

0 commit comments

Comments
 (0)