In data interchnage with Protocol Buffers, ensuring that certain fields are always present is critical for data integrity. While proto2 offered explicit required markers, proto3 removed them in favor of explicit application‑level validation. This article demonstrates robust patterns for enforcing mandatory fields in Java when working with protobuf.

Field Presence in Proto2 and Proto3

Using required in Proto2

If you are using proto2 syntax, fields can be declared as required directly in the .proto file. The generated Java code will throw an UninitializedMessageException if a required field is missing at serialization time.

// person.proto (proto2)
syntax = "proto2";

message Person {
  required string name = 1;
  required int32 age  = 2;
}

After generating the Java class with protoc, every builder invocation must supply both fields:

Person person = Person.newBuilder()
    .setName("Alice")
    .setAge(30)
    .build();

byte[] bytes = person.toByteArray();
Person restored = Person.parseFrom(bytes);

Omitting setName or setAge causes a build‑time or serialization‑time error, catching problems early.

Handling Mandatory Fields in Proto3

Proto3 eliminated required. All singular field are optional by default and have zero‑values if unset. To restore mandatory semantics, add custom validation after buliding the message.

Define a helper that checks for explicit presence:

import com.google.protobuf.Message;

public final class ProtobufValidator {
  public static <T extends Message> T requireFieldsSet(T message, String... fieldNames) {
    for (String field : fieldNames) {
      if (!message.hasField(message.getDescriptorForType().findFieldByName(field))) {
        throw new IllegalArgumentException(
            "Missing required field: " + field);
      }
    }
    return message;
  }
}

Apply the validator immediately after building:

Person person = requireFieldsSet(
    Person.newBuilder()
        .setName("Bob")
        .setAge(25)
        .build(),
    "name", "age"
);

This approach ensures required fields are populated before the message is serialized or forwarded, mimicking proto2’s compile‑time safety.

Complete Workflow in a Service

Consider a service that processes user profiles:

public byte[] serializeProfile(String name, int age) {
    Person profile = Person.newBuilder()
        .setName(name)
        .setAge(age)
        .build();
    
    // Enforce mandatory fields
    requireFieldsSet(profile, "name", "age");
    
    return profile.toByteArray();
}

public Person deserializeProfile(byte[] data) throws InvalidProtocolBufferException {
    Person profile = Person.parseFrom(data);
    
    // Optional: re‑validate after deserialization
    requireFieldsSet(profile, "name", "age");
    
    return profile;
}

Using a centralized validator makes the contract clear and testable. Unit tests can assert that missing fields throw the expected exceptions, guarding against regressions.

Summary of Recommendations

• Proto2: use required sparingly; prefer optional with application checks when flexibility is needed.
• Proto3: always validate mandatory fields right after building a message, using reflection or generated has* methods.
• Document which fields are logically required for your service, even if the .proto schema does not enforce them.

Applying these patterns helps maintain data quality and prevents subtle bugs caused by unset fields in Protocol Buffers communications.