I was developing a new functionality into Java::Geci to make it less prone to code reformatting. The current release of the code will overwrite an otherwise identical code if it was reformatted. It is annoying since it is fairly easy to press the reformatting key shortcut and many projects even require that developers set their editor to automatically format the code upon save. In those cases, Java::Geci cannot be used because as soon as the code is reformatted, the generator thinks that the code it generates is not the same as the one already in the source file, updates it, and signals the change of the code failing the unit tests.
The solution I was crafting compares the Java source files — first, converting them to a list of lexical elements. That way, you can even reformat the code inserting new lines, spaces, etc., so long as long the code remains the same. To do that, I needed a simplified lexical analyzer for Java. Writing a lexical analyzer is not a big deal, I created several for different reasons since I first read the Dragon Book in 1987. The only thing I really needed is the precise definition of what are the string, character, number literals, the keywords, and so on. In short, what is the definition of the Java language on the lexical level and how is it processed. Fortunately, there is a precise definition for that, the Java Language Specification, which is not only precise but also readable and has examples. So, I started to read the corresponding chapters.