Sets the Java package where classes generated from this .proto will be placed. By default, the proto package is used, but this is often inappropriate because proto packages do not normally start with backwards domain names.
If set, all the classes from the .proto file are wrapped in a single outer class with the given name. This applies to both Proto1 (equivalent to the old "--one_java_file" option) and Proto2 (where a .proto always translates to a single class, but you may want to explicitly choose the class name).
If set true, then the Java code generator will generate a separate .java file for each top-level message, enum, and service defined in the .proto file. Thus, these types will *not* be nested inside the outer class named by java_outer_classname. However, the outer class will still be generated to contain the file's getDescriptor() method as well as any top-level extensions defined in the file.
If set true, then the Java code generator will generate equals() and hashCode() methods for all messages defined in the .proto file. This increases generated code size, potentially substantially for large protos, which may harm a memory-constrained application.
If set true, then the Java2 code generator will generate code that throws an exception whenever an attempt is made to assign a non-UTF-8 byte sequence to a string field. Message reflection will do the same. However, an extension field still accepts non-UTF-8 byte sequences. This option has no effect on when used with the lite runtime.
Sets the Go package where structs generated from this .proto will be placed. If omitted, the Go package will be derived from the following:
Should generic services be generated in each language? "Generic" services are not specific to any particular RPC system. They are generated by the main code generators in each language (without additional plugins). Generic services were the only kind of service generation supported by early versions of google.protobuf.
Generic services are now considered deprecated in favor of using plugins that generate code specific to your particular RPC system. Therefore, these default to false. Old code which depends on generic services should explicitly set them to true.
Is this file deprecated? Depending on the target platform, this can emit Deprecated annotations for everything in the file, or it will be completely ignored; in the very least, this is a formalization for deprecating files.
Enables the use of arenas for the proto messages in this file. This applies only to generated classes for C++.
Sets the objective c class prefix which is prepended to all objective c generated classes from this .proto. There is no default.
Namespace for generated classes; defaults to the package.
The parser stores options it doesn't recognize here. See above.
Enables the use of arenas for the proto messages in this file.
Enables the use of arenas for the proto messages in this file. This applies only to generated classes for C++.
Should generic services be generated in each language? "Generic" services are not specific to any particular RPC system.
Should generic services be generated in each language? "Generic" services are not specific to any particular RPC system. They are generated by the main code generators in each language (without additional plugins). Generic services were the only kind of service generation supported by early versions of google.protobuf.
Generic services are now considered deprecated in favor of using plugins that generate code specific to your particular RPC system. Therefore, these default to false. Old code which depends on generic services should explicitly set them to true.
Namespace for generated classes; defaults to the package.
Is this file deprecated? Depending on the target platform, this can emit Deprecated annotations for everything in the file, or it will be completely ignored; in the very least, this is a formalization for deprecating files.
Sets the Go package where structs generated from this .
Sets the Go package where structs generated from this .proto will be placed. If omitted, the Go package will be derived from the following:
If set true, then the Java code generator will generate equals() and hashCode() methods for all messages defined in the .
If set true, then the Java code generator will generate equals() and hashCode() methods for all messages defined in the .proto file. This increases generated code size, potentially substantially for large protos, which may harm a memory-constrained application.
If set true, then the Java code generator will generate a separate .
If set true, then the Java code generator will generate a separate .java file for each top-level message, enum, and service defined in the .proto file. Thus, these types will *not* be nested inside the outer class named by java_outer_classname. However, the outer class will still be generated to contain the file's getDescriptor() method as well as any top-level extensions defined in the file.
If set, all the classes from the .
If set, all the classes from the .proto file are wrapped in a single outer class with the given name. This applies to both Proto1 (equivalent to the old "--one_java_file" option) and Proto2 (where a .proto always translates to a single class, but you may want to explicitly choose the class name).
Sets the Java package where classes generated from this .
Sets the Java package where classes generated from this .proto will be placed. By default, the proto package is used, but this is often inappropriate because proto packages do not normally start with backwards domain names.
If set true, then the Java2 code generator will generate code that throws an exception whenever an attempt is made to assign a non-UTF-8 byte sequence to a string field.
If set true, then the Java2 code generator will generate code that throws an exception whenever an attempt is made to assign a non-UTF-8 byte sequence to a string field. Message reflection will do the same. However, an extension field still accepts non-UTF-8 byte sequences. This option has no effect on when used with the lite runtime.
Sets the objective c class prefix which is prepended to all objective c generated classes from this .
Sets the objective c class prefix which is prepended to all objective c generated classes from this .proto. There is no default.
The parser stores options it doesn't recognize here.
The parser stores options it doesn't recognize here. See above.
Sets the Java package where classes generated from this .proto will be placed. By default, the proto package is used, but this is often inappropriate because proto packages do not normally start with backwards domain names.
If set, all the classes from the .proto file are wrapped in a single outer class with the given name. This applies to both Proto1 (equivalent to the old "--one_java_file" option) and Proto2 (where a .proto always translates to a single class, but you may want to explicitly choose the class name).
If set true, then the Java code generator will generate a separate .java file for each top-level message, enum, and service defined in the .proto file. Thus, these types will *not* be nested inside the outer class named by java_outer_classname. However, the outer class will still be generated to contain the file's getDescriptor() method as well as any top-level extensions defined in the file.
If set true, then the Java code generator will generate equals() and hashCode() methods for all messages defined in the .proto file. This increases generated code size, potentially substantially for large protos, which may harm a memory-constrained application.
If set true, then the Java2 code generator will generate code that throws an exception whenever an attempt is made to assign a non-UTF-8 byte sequence to a string field. Message reflection will do the same. However, an extension field still accepts non-UTF-8 byte sequences. This option has no effect on when used with the lite runtime.
Sets the Go package where structs generated from this .proto will be placed. If omitted, the Go package will be derived from the following:
Should generic services be generated in each language? "Generic" services are not specific to any particular RPC system. They are generated by the main code generators in each language (without additional plugins). Generic services were the only kind of service generation supported by early versions of google.protobuf.
Generic services are now considered deprecated in favor of using plugins that generate code specific to your particular RPC system. Therefore, these default to false. Old code which depends on generic services should explicitly set them to true.
Is this file deprecated? Depending on the target platform, this can emit Deprecated annotations for everything in the file, or it will be completely ignored; in the very least, this is a formalization for deprecating files.
Enables the use of arenas for the proto messages in this file. This applies only to generated classes for C++.
Sets the objective c class prefix which is prepended to all objective c generated classes from this .proto. There is no default.
Namespace for generated classes; defaults to the package.
The parser stores options it doesn't recognize here. See above.