FileOptions
=================================================================== Options
Each of the definitions above may have "options" attached. These are just annotations which may cause code to be generated slightly differently or may contain hints for code that manipulates protocol messages.
Clients may define custom options as extensions of the *Options messages. These extensions may not yet be known at parsing time, so the parser cannot store the values in them. Instead it stores them in a field in the *Options message called uninterpreted_option. This field must have the same name across all *Options messages. We then use this field to populate the extensions when we build a descriptor, at which point all protos have been parsed and so all extensions are known.
Extension numbers for custom options may be chosen as follows:
For options which will only be used within a single application or organization, or for experimental options, use field numbers 50000 through 99999. It is up to you to ensure that you do not use the same number for multiple options.
For options which will be published and used publicly by multiple independent entities, e-mail protobuf-global-extension-registry@google.com to reserve extension numbers. Simply provide your project name (e.g. Objective-C plugin) and your project website (if available) -- there's no need to explain how you intend to use them. Usually you only need one extension number. You can declare multiple options with only one extension number by putting them in a sub-message. See the Custom Options section of the docs for examples: https://developers.google.com/protocol-buffers/docs/proto#options If this turns out to be popular, a web service will be set up to automatically assign option numbers.
Properties
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. 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.
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.
Any features defined in the specific edition. WARNING: This field should only be used by protobuf plugins or special cases like the proto compiler. Other uses are discouraged and developers should rely on the protoreflect APIs for their client language.
This option does nothing.
If enabled, 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 wrapper class named by java_outer_classname. However, the wrapper class will still be generated to contain the file's getDescriptor() method as well as any top-level extensions defined in the file.
Controls the name of the wrapper Java class generated for the .proto file. That class will always contain the .proto file's getDescriptor() method as well as any top-level extensions defined in the .proto file. If java_multiple_files is disabled, then all the other classes from the .proto file will be nested inside the single wrapper outer class.
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.
A proto2 file can set this to true to opt in to UTF-8 checking for Java, which will throw an exception if invalid UTF-8 is parsed from the wire or assigned to a string field.
Sets the objective c class prefix which is prepended to all objective c generated classes from this .proto. There is no default.
Sets the php class prefix which is prepended to all php generated classes from this .proto. Default is empty.
Use this option to change the namespace of php generated metadata classes. Default is empty. When this option is empty, the proto file name will be used for determining the namespace.
Use this option to change the namespace of php generated classes. Default is empty. When this option is empty, the package name will be used for determining the namespace.
Returns the field-presence view for this com.google.protobuf.kotlin.FileOptions instance.
Use this option to change the package of ruby generated classes. Default is empty. When this option is not set, the package name will be used for determining the ruby package.
By default Swift generators will take the proto package and CamelCase it replacing '.' with underscore and use that to prefix the types/symbols defined. When this options is provided, they will use this value instead to prefix the types/symbols defined.
The parser stores options it doesn't recognize here. See the documentation for the "Options" section above.
Functions
Copies the original message, including unknown fields.