5.2.2. Suggestion: Use Lombok?

The section is dedicated to automating the generation of Java code for data values. Unclear if you are comfortable adding dependencies but Lombok automates a lot of this template code. Might want to point people to it?

package com.craftinginterpreters.lox;

abstract class Expr { 
  @Value
  static class Binary extends Expr {
    final Expr left;
    final Token operator;
    final Expr right;
  }

Edit: Looked more closely at the section and I would change this feedback to remove the emphasis on the tool that generates the java code. In favor of... "Model your expressions as data types. E.g. Type1, Type2. I used (link to script) to generate the java code."

Disclaimer: I'm in tourist mode reading the book at 1am.

Unclear if you are comfortable adding dependencies but Lombok automates a lot of this template code

It's an explicit goal of the book to have no external dependencies. From the introduction:

We’re about crafting interpreters, so this book contains real code. Every single line of code needed is included, and each snippet tells you where to insert it in your ever-growing implementation.

Many other language books and language implementations use tools like Lex and Yacc, so-called compiler-compilers that automatically generate some of the source files for an implementation from some higher level description. There are pros and cons to tools like those, and strong opinions—some might say religious convictions—on both sides.

We will abstain from using them here. I want to ensure there are no dark corners where magic and confusion can hide, so we’ll write everything by hand. As you’ll see, it’s not as bad as it sounds and it means you really will understand each line of code and how both interpreters work.

I'm not morally opposed to them personally, but a primary goal of the book was to dispell the mystery around programming languages, and external dependencies are counter to that.

munificent / craftinginterpreters

5.2.2. Suggestion: Use Lombok? #837