Package akka.protobuf

Class DescriptorProtos.FieldOptions.Builder

    • Method Detail

      • getDefaultInstanceForType

        public DescriptorProtos.FieldOptions getDefaultInstanceForType()
        Description copied from interface: MessageLiteOrBuilder
        Get an instance of the type with no fields set. Because no fields are set, all getters for singular fields will return default values and repeated fields will appear empty. This may or may not be a singleton. This differs from the getDefaultInstance() method of generated message classes in that this method is an abstract method of the MessageLite interface whereas getDefaultInstance() is a static method of a specific class. They return the same thing.
        Specified by:
        getDefaultInstanceForType in interface MessageLiteOrBuilder
        Specified by:
        getDefaultInstanceForType in interface MessageOrBuilder

      • mergeFrom

        public DescriptorProtos.FieldOptions.Builder mergeFrom​(Message other)
        Description copied from interface: Message.Builder
        Merge other into the message being built. other must have the exact same type as this (i.e. getDescriptorForType() == other.getDescriptorForType()). Merging occurs as follows. For each field:
        * For singular primitive fields, if the field is set in other, then other's value overwrites the value in this message.
        * For singular message fields, if the field is set in other, it is merged into the corresponding sub-message of this message using the same merging rules.
        * For repeated fields, the elements in other are concatenated with the elements in this message. This is equivalent to the Message::MergeFrom method in C++.
        Specified by:
        mergeFrom in interface Message.Builder
        Overrides:
        mergeFrom in class AbstractMessage.Builder<DescriptorProtos.FieldOptions.Builder>

      • hasCtype

        public boolean hasCtype()
        optional .google.protobuf.FieldOptions.CType ctype = 1 [default = STRING]; 
         The ctype option instructs the C++ code generator to use a different
 representation of the field than it normally would.  See the specific
 options below.  This option is not yet implemented in the open source
 release -- sorry, we'll try to include it in a future version!
        Specified by:
        hasCtype in interface DescriptorProtos.FieldOptionsOrBuilder

      • getCtype

        public DescriptorProtos.FieldOptions.CType getCtype()
        optional .google.protobuf.FieldOptions.CType ctype = 1 [default = STRING]; 
         The ctype option instructs the C++ code generator to use a different
 representation of the field than it normally would.  See the specific
 options below.  This option is not yet implemented in the open source
 release -- sorry, we'll try to include it in a future version!
        Specified by:
        getCtype in interface DescriptorProtos.FieldOptionsOrBuilder

      • setCtype

        public DescriptorProtos.FieldOptions.Builder setCtype​(DescriptorProtos.FieldOptions.CType value)
        optional .google.protobuf.FieldOptions.CType ctype = 1 [default = STRING]; 
         The ctype option instructs the C++ code generator to use a different
 representation of the field than it normally would.  See the specific
 options below.  This option is not yet implemented in the open source
 release -- sorry, we'll try to include it in a future version!

      • clearCtype

        public DescriptorProtos.FieldOptions.Builder clearCtype()
        optional .google.protobuf.FieldOptions.CType ctype = 1 [default = STRING]; 
         The ctype option instructs the C++ code generator to use a different
 representation of the field than it normally would.  See the specific
 options below.  This option is not yet implemented in the open source
 release -- sorry, we'll try to include it in a future version!

      • hasPacked

        public boolean hasPacked()
        optional bool packed = 2; 
         The packed option can be enabled for repeated primitive fields to enable
 a more efficient representation on the wire. Rather than repeatedly
 writing the tag and type for each element, the entire array is encoded as
 a single length-delimited blob.
        Specified by:
        hasPacked in interface DescriptorProtos.FieldOptionsOrBuilder

      • getPacked

        public boolean getPacked()
        optional bool packed = 2; 
         The packed option can be enabled for repeated primitive fields to enable
 a more efficient representation on the wire. Rather than repeatedly
 writing the tag and type for each element, the entire array is encoded as
 a single length-delimited blob.
        Specified by:
        getPacked in interface DescriptorProtos.FieldOptionsOrBuilder

      • setPacked

        public DescriptorProtos.FieldOptions.Builder setPacked​(boolean value)
        optional bool packed = 2; 
         The packed option can be enabled for repeated primitive fields to enable
 a more efficient representation on the wire. Rather than repeatedly
 writing the tag and type for each element, the entire array is encoded as
 a single length-delimited blob.

      • clearPacked

        public DescriptorProtos.FieldOptions.Builder clearPacked()
        optional bool packed = 2; 
         The packed option can be enabled for repeated primitive fields to enable
 a more efficient representation on the wire. Rather than repeatedly
 writing the tag and type for each element, the entire array is encoded as
 a single length-delimited blob.

      • hasLazy

        public boolean hasLazy()
        optional bool lazy = 5 [default = false]; 
         Should this field be parsed lazily?  Lazy applies only to message-type
 fields.  It means that when the outer message is initially parsed, the
 inner message's contents will not be parsed but instead stored in encoded
 form.  The inner message will actually be parsed when it is first accessed.

 This is only a hint.  Implementations are free to choose whether to use
 eager or lazy parsing regardless of the value of this option.  However,
 setting this option true suggests that the protocol author believes that
 using lazy parsing on this field is worth the additional bookkeeping
 overhead typically needed to implement it.

 This option does not affect the public interface of any generated code;
 all method signatures remain the same.  Furthermore, thread-safety of the
 interface is not affected by this option; const methods remain safe to
 call from multiple threads concurrently, while non-const methods continue
 to require exclusive access.


 Note that implementations may choose not to check required fields within
 a lazy sub-message.  That is, calling IsInitialized() on the outher message
 may return true even if the inner message has missing required fields.
 This is necessary because otherwise the inner message would have to be
 parsed in order to perform the check, defeating the purpose of lazy
 parsing.  An implementation which chooses not to check required fields
 must be consistent about it.  That is, for any particular sub-message, the
 implementation must either *always* check its required fields, or *never*
 check its required fields, regardless of whether or not the message has
 been parsed.
        Specified by:
        hasLazy in interface DescriptorProtos.FieldOptionsOrBuilder

      • getLazy

        public boolean getLazy()
        optional bool lazy = 5 [default = false]; 
         Should this field be parsed lazily?  Lazy applies only to message-type
 fields.  It means that when the outer message is initially parsed, the
 inner message's contents will not be parsed but instead stored in encoded
 form.  The inner message will actually be parsed when it is first accessed.

 This is only a hint.  Implementations are free to choose whether to use
 eager or lazy parsing regardless of the value of this option.  However,
 setting this option true suggests that the protocol author believes that
 using lazy parsing on this field is worth the additional bookkeeping
 overhead typically needed to implement it.

 This option does not affect the public interface of any generated code;
 all method signatures remain the same.  Furthermore, thread-safety of the
 interface is not affected by this option; const methods remain safe to
 call from multiple threads concurrently, while non-const methods continue
 to require exclusive access.


 Note that implementations may choose not to check required fields within
 a lazy sub-message.  That is, calling IsInitialized() on the outher message
 may return true even if the inner message has missing required fields.
 This is necessary because otherwise the inner message would have to be
 parsed in order to perform the check, defeating the purpose of lazy
 parsing.  An implementation which chooses not to check required fields
 must be consistent about it.  That is, for any particular sub-message, the
 implementation must either *always* check its required fields, or *never*
 check its required fields, regardless of whether or not the message has
 been parsed.
        Specified by:
        getLazy in interface DescriptorProtos.FieldOptionsOrBuilder

      • setLazy

        public DescriptorProtos.FieldOptions.Builder setLazy​(boolean value)
        optional bool lazy = 5 [default = false]; 
         Should this field be parsed lazily?  Lazy applies only to message-type
 fields.  It means that when the outer message is initially parsed, the
 inner message's contents will not be parsed but instead stored in encoded
 form.  The inner message will actually be parsed when it is first accessed.

 This is only a hint.  Implementations are free to choose whether to use
 eager or lazy parsing regardless of the value of this option.  However,
 setting this option true suggests that the protocol author believes that
 using lazy parsing on this field is worth the additional bookkeeping
 overhead typically needed to implement it.

 This option does not affect the public interface of any generated code;
 all method signatures remain the same.  Furthermore, thread-safety of the
 interface is not affected by this option; const methods remain safe to
 call from multiple threads concurrently, while non-const methods continue
 to require exclusive access.


 Note that implementations may choose not to check required fields within
 a lazy sub-message.  That is, calling IsInitialized() on the outher message
 may return true even if the inner message has missing required fields.
 This is necessary because otherwise the inner message would have to be
 parsed in order to perform the check, defeating the purpose of lazy
 parsing.  An implementation which chooses not to check required fields
 must be consistent about it.  That is, for any particular sub-message, the
 implementation must either *always* check its required fields, or *never*
 check its required fields, regardless of whether or not the message has
 been parsed.

      • clearLazy

        public DescriptorProtos.FieldOptions.Builder clearLazy()
        optional bool lazy = 5 [default = false]; 
         Should this field be parsed lazily?  Lazy applies only to message-type
 fields.  It means that when the outer message is initially parsed, the
 inner message's contents will not be parsed but instead stored in encoded
 form.  The inner message will actually be parsed when it is first accessed.

 This is only a hint.  Implementations are free to choose whether to use
 eager or lazy parsing regardless of the value of this option.  However,
 setting this option true suggests that the protocol author believes that
 using lazy parsing on this field is worth the additional bookkeeping
 overhead typically needed to implement it.

 This option does not affect the public interface of any generated code;
 all method signatures remain the same.  Furthermore, thread-safety of the
 interface is not affected by this option; const methods remain safe to
 call from multiple threads concurrently, while non-const methods continue
 to require exclusive access.


 Note that implementations may choose not to check required fields within
 a lazy sub-message.  That is, calling IsInitialized() on the outher message
 may return true even if the inner message has missing required fields.
 This is necessary because otherwise the inner message would have to be
 parsed in order to perform the check, defeating the purpose of lazy
 parsing.  An implementation which chooses not to check required fields
 must be consistent about it.  That is, for any particular sub-message, the
 implementation must either *always* check its required fields, or *never*
 check its required fields, regardless of whether or not the message has
 been parsed.

      • hasDeprecated

        public boolean hasDeprecated()
        optional bool deprecated = 3 [default = false]; 
         Is this field deprecated?
 Depending on the target platform, this can emit Deprecated annotations
 for accessors, or it will be completely ignored; in the very least, this
 is a formalization for deprecating fields.
        Specified by:
        hasDeprecated in interface DescriptorProtos.FieldOptionsOrBuilder

      • getDeprecated

        public boolean getDeprecated()
        optional bool deprecated = 3 [default = false]; 
         Is this field deprecated?
 Depending on the target platform, this can emit Deprecated annotations
 for accessors, or it will be completely ignored; in the very least, this
 is a formalization for deprecating fields.
        Specified by:
        getDeprecated in interface DescriptorProtos.FieldOptionsOrBuilder

      • setDeprecated

        public DescriptorProtos.FieldOptions.Builder setDeprecated​(boolean value)
        optional bool deprecated = 3 [default = false]; 
         Is this field deprecated?
 Depending on the target platform, this can emit Deprecated annotations
 for accessors, or it will be completely ignored; in the very least, this
 is a formalization for deprecating fields.

      • clearDeprecated

        public DescriptorProtos.FieldOptions.Builder clearDeprecated()
        optional bool deprecated = 3 [default = false]; 
         Is this field deprecated?
 Depending on the target platform, this can emit Deprecated annotations
 for accessors, or it will be completely ignored; in the very least, this
 is a formalization for deprecating fields.

      • hasExperimentalMapKey

        public boolean hasExperimentalMapKey()
        optional string experimental_map_key = 9; 
         EXPERIMENTAL.  DO NOT USE.
 For "map" fields, the name of the field in the enclosed type that
 is the key for this map.  For example, suppose we have:
   message Item {
     required string name = 1;
     required string value = 2;
   }
   message Config {
     repeated Item items = 1 [experimental_map_key="name"];
   }
 In this situation, the map key for Item will be set to "name".
 TODO: Fully-implement this, then remove the "experimental_" prefix.
        Specified by:
        hasExperimentalMapKey in interface DescriptorProtos.FieldOptionsOrBuilder

      • getExperimentalMapKey

        public java.lang.String getExperimentalMapKey()
        optional string experimental_map_key = 9; 
         EXPERIMENTAL.  DO NOT USE.
 For "map" fields, the name of the field in the enclosed type that
 is the key for this map.  For example, suppose we have:
   message Item {
     required string name = 1;
     required string value = 2;
   }
   message Config {
     repeated Item items = 1 [experimental_map_key="name"];
   }
 In this situation, the map key for Item will be set to "name".
 TODO: Fully-implement this, then remove the "experimental_" prefix.
        Specified by:
        getExperimentalMapKey in interface DescriptorProtos.FieldOptionsOrBuilder

      • getExperimentalMapKeyBytes

        public ByteString getExperimentalMapKeyBytes()
        optional string experimental_map_key = 9; 
         EXPERIMENTAL.  DO NOT USE.
 For "map" fields, the name of the field in the enclosed type that
 is the key for this map.  For example, suppose we have:
   message Item {
     required string name = 1;
     required string value = 2;
   }
   message Config {
     repeated Item items = 1 [experimental_map_key="name"];
   }
 In this situation, the map key for Item will be set to "name".
 TODO: Fully-implement this, then remove the "experimental_" prefix.
        Specified by:
        getExperimentalMapKeyBytes in interface DescriptorProtos.FieldOptionsOrBuilder

      • setExperimentalMapKey

        public DescriptorProtos.FieldOptions.Builder setExperimentalMapKey​(java.lang.String value)
        optional string experimental_map_key = 9; 
         EXPERIMENTAL.  DO NOT USE.
 For "map" fields, the name of the field in the enclosed type that
 is the key for this map.  For example, suppose we have:
   message Item {
     required string name = 1;
     required string value = 2;
   }
   message Config {
     repeated Item items = 1 [experimental_map_key="name"];
   }
 In this situation, the map key for Item will be set to "name".
 TODO: Fully-implement this, then remove the "experimental_" prefix.

      • clearExperimentalMapKey

        public DescriptorProtos.FieldOptions.Builder clearExperimentalMapKey()
        optional string experimental_map_key = 9; 
         EXPERIMENTAL.  DO NOT USE.
 For "map" fields, the name of the field in the enclosed type that
 is the key for this map.  For example, suppose we have:
   message Item {
     required string name = 1;
     required string value = 2;
   }
   message Config {
     repeated Item items = 1 [experimental_map_key="name"];
   }
 In this situation, the map key for Item will be set to "name".
 TODO: Fully-implement this, then remove the "experimental_" prefix.

      • setExperimentalMapKeyBytes

        public DescriptorProtos.FieldOptions.Builder setExperimentalMapKeyBytes​(ByteString value)
        optional string experimental_map_key = 9; 
         EXPERIMENTAL.  DO NOT USE.
 For "map" fields, the name of the field in the enclosed type that
 is the key for this map.  For example, suppose we have:
   message Item {
     required string name = 1;
     required string value = 2;
   }
   message Config {
     repeated Item items = 1 [experimental_map_key="name"];
   }
 In this situation, the map key for Item will be set to "name".
 TODO: Fully-implement this, then remove the "experimental_" prefix.

      • clearUninterpretedOption

        public DescriptorProtos.FieldOptions.Builder clearUninterpretedOption()
        repeated .google.protobuf.UninterpretedOption uninterpreted_option = 999; 
         The parser stores options it doesn't recognize here. See above.

      • removeUninterpretedOption

        public DescriptorProtos.FieldOptions.Builder removeUninterpretedOption​(int index)
        repeated .google.protobuf.UninterpretedOption uninterpreted_option = 999; 
         The parser stores options it doesn't recognize here. See above.

      • getUninterpretedOptionBuilder

        public DescriptorProtos.UninterpretedOption.Builder getUninterpretedOptionBuilder​(int index)
        repeated .google.protobuf.UninterpretedOption uninterpreted_option = 999; 
         The parser stores options it doesn't recognize here. See above.

      • addUninterpretedOptionBuilder

        public DescriptorProtos.UninterpretedOption.Builder addUninterpretedOptionBuilder()
        repeated .google.protobuf.UninterpretedOption uninterpreted_option = 999; 
         The parser stores options it doesn't recognize here. See above.

      • addUninterpretedOptionBuilder

        public DescriptorProtos.UninterpretedOption.Builder addUninterpretedOptionBuilder​(int index)
        repeated .google.protobuf.UninterpretedOption uninterpreted_option = 999; 
         The parser stores options it doesn't recognize here. See above.

      • getUninterpretedOptionBuilderList

        public java.util.List<DescriptorProtos.UninterpretedOption.Builder> getUninterpretedOptionBuilderList()
        repeated .google.protobuf.UninterpretedOption uninterpreted_option = 999; 
         The parser stores options it doesn't recognize here. See above.