File tree Expand file tree Collapse file tree 1 file changed +30
-0
lines changed Expand file tree Collapse file tree 1 file changed +30
-0
lines changed Original file line number Diff line number Diff line change @@ -271,6 +271,36 @@ A common practice is to generate your protos into a `proto` subpackage in your
271271project that ** only**  contains those protos (that is, no hand-written source
272272code).
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
276306If the name of a message, field, enum, or enum value is a keyword in the
 
 
   
 
     
   
   
          
    
    
     
    
      
     
     
    You can’t perform that action at this time.
  
 
    
  
    
      
        
     
       
      
     
   
 
    
    
  
 
  
 
     
    
0 commit comments