Если вы разрабатываете корпоративные приложения, и не только, вероятно вы уже знакомы с протоколом сериализации Protocol Buffers от Google. В данной статье поговорим о его второй версии. И о том, что он заставляет писать много boilerplate кода, с которым мы и будем бороться.
Protobuff — это отличная штука — вы описываете состав вашего API в .proto файле, состоящий из примитивов, и можете сгенерировать исходный код для разных платформ — например сервер на Java и клиент на C# или наоборот. Так как чаще всего это API для внешних систем — логичнее делать его иммутабельным, собственно такой код и генерирует стандартный генератор для Java.
Рассмотрим пример:
В итоге получаем класс с таким интерфейсом:
Обратите внимание, что повсюду используются примитивы (что эффективно для сериализации и производительности). Но поле age у нас необязательное, но примитив всегда имеет дефолтное значение. Именно это и пораждает кучу boilerplate кода, с которым мы и будем бороться.
А ведь очень хочется написать:
Protocol Buffers имеет механизм расширения с помощью plugins, и его можно написать на Java, что мы и сделаем.
Что такое плагин для protobuf?
Это запускаемый файл, который читает из стандартного входящего потока объект PluginProtos.CodeGeneratorRequest, на его основе генерирует PluginProtos.CodeGeneratorResponse и записывает его в стандартный выходной поток.
Давайте рассмотрим подробнее, что мы можем сгененрировать?
PluginProtos.CodeGeneratorResponse содержит набор PluginProtos.CodeGeneratorResponse.File.
Каждый «file» — это новый класс, который мы генерируем самостоятельно. Он состоит из:
Самое важное для написания плагинов — мы не должны генерировать все классы заново — мы можем дополнять уже существующие классы используя insertionPoint. Если вернуться к сгенерированному интерфейсу выше — мы там увидим:
именно в эти места мы можем дописать свой код. Таким образом дописать в произвольный участок класса у нас не получится. От этого и будем отталкиваться. Как мы можем решить данную проблему? Мы можем сделать свой новый интерфейс с default методом —
а для класса Person добавить имплементацию не только PersonOrBuilder, но и PersonOptional
Теперь вернем из плагина код, который нужно сгенерировать
Как будем использовать наш новый плагин? — через maven, добавляем и настраиваем наш плагин:
Но можно и запустить его из консоли — здесь есть одна особенность запускать нужно не только наш плагин, а перед этим нужно вызвать стандарный java компилятор (но нужно создать исполняемый файл — protoc-gen-java8 (в моем случае просто bash-скрипт).
Исходный код можно посмотреть здесь.
Protobuff — это отличная штука — вы описываете состав вашего API в .proto файле, состоящий из примитивов, и можете сгенерировать исходный код для разных платформ — например сервер на Java и клиент на C# или наоборот. Так как чаще всего это API для внешних систем — логичнее делать его иммутабельным, собственно такой код и генерирует стандартный генератор для Java.
Рассмотрим пример:
syntax = "proto2";
option java_multiple_files = true;
package org.example.api;
message Person { //описываем объект с нужными нам полями
required int32 id = 1; // идентификатор, поле обязательное
required string name = 2; // имя, поле обязательное
optional int32 age = 3; // возраст, поле опциональное
}
В итоге получаем класс с таким интерфейсом:
public interface PersonOrBuilder extends
// @@protoc_insertion_point(interface_extends:org.example.api.Person)
com.google.protobuf.MessageOrBuilder {
boolean hasId();
int getId();
boolean hasName();
java.lang.String getName();
com.google.protobuf.ByteString getNameBytes();
boolean hasAge();
int getAge();
}
Обратите внимание, что повсюду используются примитивы (что эффективно для сериализации и производительности). Но поле age у нас необязательное, но примитив всегда имеет дефолтное значение. Именно это и пораждает кучу boilerplate кода, с которым мы и будем бороться.
Integer johnAge = john.hasAge() ? john.getAge() : null;
А ведь очень хочется написать:
Integer johnAge = john.age().orElse(null); // здесь age() - Возвращает Optional<Integer>
Protocol Buffers имеет механизм расширения с помощью plugins, и его можно написать на Java, что мы и сделаем.
Что такое плагин для protobuf?
Это запускаемый файл, который читает из стандартного входящего потока объект PluginProtos.CodeGeneratorRequest, на его основе генерирует PluginProtos.CodeGeneratorResponse и записывает его в стандартный выходной поток.
public static void main(String[] args) throws IOException {
PluginProtos.CodeGeneratorRequest codeRequest = PluginProtos.CodeGeneratorRequest.parseFrom(System.in);
PluginProtos.CodeGeneratorResponse codeResponse;
try {
codeResponse = generate(codeRequest);
} catch (Exception e) {
codeResponse = PluginProtos.CodeGeneratorResponse.newBuilder()
.setError(e.getMessage())
.build();
}
codeResponse.writeTo(System.out);
}
Давайте рассмотрим подробнее, что мы можем сгененрировать?
PluginProtos.CodeGeneratorResponse содержит набор PluginProtos.CodeGeneratorResponse.File.
Каждый «file» — это новый класс, который мы генерируем самостоятельно. Он состоит из:
String name; // имя файла, здесь должен быть путь к файлу с учетом его package
String content; // Собственно исходный код класса
String insertionPoint; // Точка вставки
Самое важное для написания плагинов — мы не должны генерировать все классы заново — мы можем дополнять уже существующие классы используя insertionPoint. Если вернуться к сгенерированному интерфейсу выше — мы там увидим:
// @@protoc_insertion_point(interface_extends:org.example.api.Person)
именно в эти места мы можем дописать свой код. Таким образом дописать в произвольный участок класса у нас не получится. От этого и будем отталкиваться. Как мы можем решить данную проблему? Мы можем сделать свой новый интерфейс с default методом —
public interface PersonOptional extends PersonOrBuilder {
default Optional<Integer> age() {
return hasAge() ? Optional.of(getAge()) : Optional.empty();
}
}
а для класса Person добавить имплементацию не только PersonOrBuilder, но и PersonOptional
Код для генерации нужного нам интерфейса
@Builder
public class InterfaceWriter {
private static final Map<DescriptorProtos.FieldDescriptorProto.Type, Class<?>> typeToClassMap = ImmutableMap.<DescriptorProtos.FieldDescriptorProto.Type, Class<?>>builder()
.put(TYPE_DOUBLE, Double.class)
.put(TYPE_FLOAT, Float.class)
.put(TYPE_INT64, Long.class)
.put(TYPE_UINT64, Long.class)
.put(TYPE_INT32, Integer.class)
.put(TYPE_FIXED64, Long.class)
.put(TYPE_FIXED32, Integer.class)
.put(TYPE_BOOL, Boolean.class)
.put(TYPE_STRING, String.class)
.put(TYPE_UINT32, Integer.class)
.put(TYPE_SFIXED32, Integer.class)
.put(TYPE_SINT32, Integer.class)
.put(TYPE_SFIXED64, Long.class)
.put(TYPE_SINT64, Long.class)
.build();
private final String packageName;
private final String className;
private final List<DescriptorProtos.FieldDescriptorProto> fields;
public String getCode() {
List<MethodSpec> methods = fields.stream().map(field -> {
ClassName fieldClass;
if (typeToClassMap.containsKey(field.getType())) {
fieldClass = ClassName.get(typeToClassMap.get(field.getType()));
} else {
int lastIndexOf = StringUtils.lastIndexOf(field.getTypeName(), '.');
fieldClass = ClassName.get(field.getTypeName().substring(1, lastIndexOf), field.getTypeName().substring(lastIndexOf + 1));
}
return MethodSpec.methodBuilder(field.getName())
.addModifiers(Modifier.DEFAULT, Modifier.PUBLIC)
.returns(ParameterizedTypeName.get(ClassName.get(Optional.class), fieldClass))
.addStatement("return has$N() ? $T.of(get$N()) : $T.empty()", capitalize(field.getName()), Optional.class, capitalize(field.getName()), Optional.class)
.build();
}).collect(Collectors.toList());
TypeSpec generatedInterface = TypeSpec.interfaceBuilder(className + "Optional")
.addSuperinterface(ClassName.get(packageName, className + "OrBuilder"))
.addModifiers(Modifier.PUBLIC)
.addMethods(methods)
.build();
return JavaFile.builder(packageName, generatedInterface).build().toString();
}
}
Теперь вернем из плагина код, который нужно сгенерировать
PluginProtos.CodeGeneratorResponse.File.newBuilder() // здесь мы не заполняем InsertionPoint, потому что это должен быть новый файл
.setName(String.format("%s/%sOptional.java", clazzPackage.replaceAll("\\.", "/"), clazzName))
.setContent(InterfaceWriter.builder().packageName(clazzPackage).className(clazzName).fields(optionalFields).build().getCode())
.build();
PluginProtos.CodeGeneratorResponse.File.newBuilder()
.setName(String.format("%s/%s.java", clazzPackage.replaceAll("\\.", "/"), clazzName))
.setInsertionPoint(String.format("message_implements:%s.%s", clazzPackage, clazzName)) // здесь мы задаем место - реализация message - добавляем ему имплементацию нового интерфейса
.setContent(String.format(" %s.%sOptional, ", clazzPackage, clazzName))
.build(),
Как будем использовать наш новый плагин? — через maven, добавляем и настраиваем наш плагин:
<plugin>
<groupId>org.xolstice.maven.plugins</groupId>
<artifactId>protobuf-maven-plugin</artifactId>
<version>0.6.1</version>
<extensions>true</extensions>
<configuration>
<pluginId>java8</pluginId>
<protoSourceRoot>${basedir}/src/main/proto</protoSourceRoot>
<protocPlugins>
<protocPlugin>
<id>java8</id>
<groupId>org.example.protobuf</groupId>
<artifactId>optional-plugin</artifactId>
<version>1.0-SNAPSHOT</version>
<mainClass>org.example.proto2plugin.OptionalPlugin</mainClass>
</protocPlugin>
</protocPlugins>
</configuration>
</plugin>
Но можно и запустить его из консоли — здесь есть одна особенность запускать нужно не только наш плагин, а перед этим нужно вызвать стандарный java компилятор (но нужно создать исполняемый файл — protoc-gen-java8 (в моем случае просто bash-скрипт).
protoc -I=./src/main/resources/ --java_out=./src/main/java/ --java8_out=./src/main/java/ ./src/main/resources/example.proto
Исходный код можно посмотреть здесь.
