#code-generation
Posts
-
Digging into Gradle's Source 4: The Service Registry — the DI Container Inside Gradle
Who puts a FileSystemOperations into your task when you mark its constructor with @Inject? This post reads DefaultServiceRegistry, one per scope, which looks services up through its parents; the rules for declaring services with @Provides methods and decorators; lazy singletons created on first lookup; ServiceScopeValidator, which keeps services in their proper scope; GradleModuleServices, through which 57 modules add services to every scope; and the _Decorated classes that fill in abstract getters. We use the registry directly outside a build and print the stack of a task being created to check it all against the source.
-
Digging into Gradle's Source 6: Projects and Build Scripts — How build.gradle.kts Gets Run
What does one build.gradle.kts file turn into inside Gradle? We follow the code that builds DefaultProject from the descriptors settings left behind, the evaluator chain that runs under a project lock with its beforeEvaluate and afterEvaluate states, the selector that picks Groovy or Kotlin by the end of the file name, the two DSLs that cut out plugins {} and compile twice, the generated accessors that make tasks.compileJava possible, and the class loader scopes that run from settings down to subprojects, running the same script in both DSLs and printing a stack trace to check each step against the source.
-
Digging into Kafka's Source 3: The Wire Protocol — Requests and Responses Generated from JSON Schemas
The bytes a producer and a broker exchange over TCP always have one shape, [4-byte length][request header][body]. We follow in the source how 203 JSON schemas that define that shape become 391 Java classes at build time, how the ApiVersions exchange picks a version, and how flexible versions and tagged fields let old and new versions live together, then check the bytes ourselves with an example that sends requests over a raw socket using nothing but the generated classes.
-
Digging into MariaDB's Source 6: The Parser — How an SQL Statement Becomes LEX and Item Trees
We follow one SQL statement from a plain string through the lexer (Lex_input_stream), where it becomes tokens, into the rule actions of the Bison-generated parsers (MYSQLparse and ORAparse), where it becomes LEX, SELECT_LEX, TABLE_LIST and Item trees. We look at the build rule that turns one grammar file into two parsers, the keyword table and state_map, and the place the "near '...' at line N" error comes from, then print the trees the parser leaves behind with a Bison trace and gdb.
-
Digging into Tomcat's Source 13: Jasper — How a JSP Becomes a Servlet
What happens inside Tomcat the first time you request hello.jsp? We follow the Jasper source as JspServlet takes the request, reads the JSP file into a node tree, writes it out as Java source, compiles it with ecj, leaves a .class in the work directory, and then calls that class like any servlet. We open the generated .java file, and use examples to see when an edited JSP gets recompiled (development, modificationTestInterval, checkInterval).