Prefix: jvm_.
A census of the classes available on the declared compile classpath: the classes themselves, their public methods and parameters, their record components and supertypes. When the schema names Java code, this census is what the name is checked against. Presence says nothing about purpose; a class earns its row by being on the classpath, not by being used.
Where to start
- jvm_class
-
A class exists on the declared compile classpath: the module’s own output, its reactor siblings, and the dependencies the module declares itself.
- jvm_method
-
A public method exists on a class in the census.
- jvm_record_component
-
A record component of a record class in the census, read from the classfile RecordAttribute rather than from any bytecode; backs record-mapping facts.
How this family meets the others
store_-
1 foreign key from this family’s rows into that one.
Why the name is right
What the classfiles on the declared compile classpath declare: the module’s own output, its reactor siblings, and the dependencies the module declares itself, never a transitive-only jar. Not extension_: naming a family for a presumed role is what this name replaces, because an ObjectMapper on the classpath extends nothing yet still earns a row.
jvm_class
A class exists on the declared compile classpath: the module’s own output, its reactor siblings, and the dependencies the module declares itself. Filtered: public, non-synthetic, top-level (a simple name containing $ is skipped, so nested classes are absent), outside the generated jOOQ package, and not from a transitive-only dependency (a jar no declared coordinate carries is never opened). A resolution detection over this relation reads those filters as absence, so they are stated rather than implied; in particular the codegen loader resolves transitive and nested classes this relation deliberately omits, and the build-side nameability check is what polices naming them.
Primary key: (source_name, class_name). Foreign key: (source_name) references store_source (source_name). Check: "CLASS_KIND" IN('CLASS', 'INTERFACE', 'ENUM', 'RECORD', 'ANNOTATION').
source_name(CHARACTER VARYING, not null)-
the classpath entry it was read from; the partition this row belongs to and the key’s leading dimension. Within one run a class present under more than one entry is captured once, at the entry that comes first in classpath order, which is where a classloader would resolve it; store-wide, two runs' entries are two partitions that coexist by design, so one class name may legitimately appear under several sources
class_name(CHARACTER VARYING, not null)-
fully qualified binary name
class_kind(CHARACTER VARYING, not null)-
the classfile’s declared form; the domain is closed over classfile shapes, so a violation is a capture bug
jvm_class_supertype
A supertype a class in the census declares: its extends clause and its implements list, as the classfile spells them. These are the edges an assignability closure is taken over, and assignability is the one rule a walk over accessor and return types could not state without a live loader; the classfile declares its own supertypes and the scan simply was not reading them. Nothing closes over them today, which is the census’s ordinary posture rather than an orphaned relation: a captured fact is recorded ahead of the derivation that will read it. The closure that was here answered every pair as a view and cost seconds on a real census, for an answer no consumer had asked for. Two constraints hold for whatever reinstates one, both of them measured rather than reasoned: recurse over the pairs these rows denote and never over the rows themselves, two entries declaring one class name being duplicate rows that double the frontier at every hop under UNION ALL; and seed the recursion from the names a consumer asks about rather than closing every pair, the census growing sideways in unrelated classes and not upward through java.util.List. java.lang.Object is deliberately absent, on the same terms the census states its other filters: the JVM writes it as the superclass of every class that declared no extends clause and of every interface, so a row would assert a declaration the source never made, and the closure would gain an edge every reference type already has. A supertype name outside the census is still a row, and at the end of a chain that is the ordinary case: the scan drops nested classes and the generated jOOQ package, and nothing ships the JDK as a classpath entry, while what a closure needs is the name a classfile declares. The chain terminates at such a name, so a derivation reads a missing hop as not-known-to-be-assignable rather than as not-assignable; org.jooq.Result reaching java.util.List is one hop within the census and resolves, a method declared to return java.util.ArrayList does not. Declaration order of the implements list is not carried, no consumer asking which interface came first.
Primary key: (source_name, class_name, supertype_name). Foreign key: (source_name, class_name) references jvm_class (source_name, class_name). Check: "DECLARED_VIA" IN('EXTENDS', 'IMPLEMENTS').
source_name(CHARACTER VARYING, not null)-
the declaring class’s classpath entry, as on jvm_class; the key’s leading dimension
class_name(CHARACTER VARYING, not null)-
the fully-qualified binary name of the declaring class
supertype_name(CHARACTER VARYING, not null)-
the fully-qualified binary name the classfile declares as the supertype, a nested one spelled with the $ the JVM uses. Deliberately not a foreign key and frequently not a census row at all; see this relation’s comment
declared_via(CHARACTER VARYING, not null)-
EXTENDS or IMPLEMENTS: which clause of the source declaration the name came from, which is a different question from what the supertype’s own declared form is. Read from the declaring class’s kind rather than from which classfile slot held the name, the JVM storing an interface’s super-interfaces in the same array as a class’s implements list while the source writes them after extends. Carried rather than derived because it is not recoverable: reading it off the supertype’s class_kind needs the supertype to have a census row, and the names that do not are exactly the ones this relation exists to record
jvm_method
A public method exists on a class in the census. Filtered: public and non-synthetic, constructors and class initializers excluded. The method’s types are carried in both forms, erased and declared, because neither is a function of the other: erasure maps a type variable to its bound, which the declared form does not name, and the declared form names a container’s element type, which the erasure does not. A surface testing a type’s identity reads the erasure and one spelling a signature for an author reads the declared form.
Primary key: (source_name, class_name, method_name, descriptor). Foreign key: (source_name, class_name) references jvm_class (source_name, class_name).
source_name(CHARACTER VARYING, not null)-
the owning class’s classpath entry, as on jvm_class; the key’s leading dimension
class_name(CHARACTER VARYING, not null)-
the fully-qualified Java class name as written
method_name(CHARACTER VARYING, not null)-
the method name; not a key on its own, overloads share it
descriptor(CHARACTER VARYING, not null)-
raw JVM descriptor; the overload discriminator that keeps this key natural
return_type(CHARACTER VARYING, not null)-
erased source-form return type: what the JVM descriptor carries, package dropped. The form a check on a type’s identity compares against
declared_return_type(CHARACTER VARYING, not null)-
the return type as the source declared it, package dropped and type arguments kept (List<Film>, Field<String>, T). Read from the classfile Signature attribute, and equal to return_type wherever the compiler emitted no attribute, which it does only where erasure loses nothing. Never NULL and never coalesced by a reader: whether a classfile stored the declared form separately is an encoding detail, not a fact about the method, so the census answers the question once. This is the column an accessor walk follows, a container’s element type being exactly what the erasure drops
returns_condition(BOOLEAN, not null)-
matched on the un-erased org.jooq.Condition descriptor, so a consumer’s own Condition type does not false-match
jvm_method_parameter
An ordered parameter of a captured method. Deliberately no parameter-source column: which ParamSource a parameter binds to is decided per directive application, not per method, so it is a derived relation keyed by the application coordinate and lands with its first consumer.
Primary key: (source_name, class_name, method_name, descriptor, position). Foreign key: (source_name, class_name, method_name, descriptor) references jvm_method (source_name, class_name, method_name, descriptor).
source_name(CHARACTER VARYING, not null)-
the owning class’s classpath entry, as on jvm_class; the key’s leading dimension
class_name(CHARACTER VARYING, not null)-
the fully-qualified Java class name as written
method_name(CHARACTER VARYING, not null)-
the owning method name
descriptor(CHARACTER VARYING, not null)-
the owning method’s raw JVM descriptor
position(INTEGER, not null)-
0-based parameter position
parameter_name(CHARACTER VARYING, nullable)-
NULL when the consumer compiled without -parameters
parameter_type(CHARACTER VARYING, not null)-
erased source-form parameter type, on the same terms as jvm_method.return_type
declared_parameter_type(CHARACTER VARYING, not null)-
the parameter type as the source declared it, on the same terms as jvm_method.declared_return_type. Falls back to the erasure for every parameter of the method, not just this one, where the signature’s argument list and the descriptor’s differ in length: a compiler-synthesised parameter appears in one and not the other, and pairing by position past that point would name the wrong type
jvm_method_parameter_type_ref
The classes a parameter’s declared type names, one row per position, on exactly the terms jvm_method_return_type_ref states. Captured with its siblings rather than deferred to a first consumer, unlike the parameter-source question this relation’s owner defers: that one is decided per directive application and genuinely belongs to a later keying axis, where this is the same decomposition of the same declared form by the same rule, and a census that resolved a return type but not a parameter type would be answering an accident rather than a question. Where the method’s signature and descriptor disagree on argument count the parameter rows fall back to the erasure wholesale, and these rows follow that reading, so they decompose whatever the parameter row itself reports.
Primary key: (source_name, class_name, method_name, descriptor, position, type_path). Foreign key: (source_name, class_name, method_name, descriptor, position) references jvm_method_parameter (source_name, class_name, method_name, descriptor, position). Check: "VARIANCE" IN('NONE', 'EXTENDS', 'SUPER').
source_name(CHARACTER VARYING, not null)-
the owning class’s classpath entry, as on jvm_class; the key’s leading dimension
class_name(CHARACTER VARYING, not null)-
the fully-qualified Java class name as written
method_name(CHARACTER VARYING, not null)-
the owning method name
descriptor(CHARACTER VARYING, not null)-
the owning method’s raw JVM descriptor
position(INTEGER, not null)-
the owning parameter’s 0-based position, as on jvm_method_parameter; a parameter position, which type_path’s digits are not
type_path(CHARACTER VARYING, not null)-
the position within the declared type; the grammar is stated on jvm_method_return_type_ref.type_path
referenced_class(CHARACTER VARYING, not null)-
the fully-qualified binary name of the class named at this position; the omission rules are stated on jvm_method_return_type_ref.referenced_class
variance(CHARACTER VARYING, not null)-
NONE, EXTENDS or SUPER, as on jvm_method_return_type_ref.variance
jvm_method_return_type_ref
The classes a method’s declared return type names, one row per position in the type. The census’s other type columns are display forms with the package dropped, which is what they were added for and what makes them unusable for identity: a walk following a return type has to tell org.jooq.Result from another package’s Result, and that is the collision jvm_method.descriptor exists to avoid at the method level. This relation is where a declared type becomes resolvable. It decomposes rather than qualifies because a declared type is a tree and not a name: Map<String, List<Film>> names four classes at four positions, and a single qualified column could answer for the outermost only, leaving the element type (which is the position a walk is actually after) still unresolvable. The rows are read off the classfile Signature attribute where one is present and off the descriptor where it is not, which is the same rule the declared display columns follow; a non-generic method carries no Signature attribute at all, so the descriptor reading is the common case rather than a fallback. The path grammar and the omission rules are stated on the type_path and referenced_class columns and hold for all three type-reference relations.
Primary key: (source_name, class_name, method_name, descriptor, type_path). Foreign key: (source_name, class_name, method_name, descriptor) references jvm_method (source_name, class_name, method_name, descriptor). Check: "VARIANCE" IN('NONE', 'EXTENDS', 'SUPER').
source_name(CHARACTER VARYING, not null)-
the owning class’s classpath entry, as on jvm_class; the key’s leading dimension
class_name(CHARACTER VARYING, not null)-
the fully-qualified Java class name as written
method_name(CHARACTER VARYING, not null)-
the owning method name
descriptor(CHARACTER VARYING, not null)-
the owning method’s raw JVM descriptor
type_path(CHARACTER VARYING, not null)-
the position within the declared type, as a dot-separated sequence of steps read outside in. The empty string is the type itself; a digit is a 0-based type-argument index;
[]is an array’s component. So List<Film> names its element at0, Map<String, List<Film>> names Film at1.0, and Film[] names Film at[]. A path descends only through positions the source wrote, so it is stable against anything the erasure does referenced_class(CHARACTER VARYING, not null)-
the fully-qualified binary name of the class named at this position, a nested one spelled with the $ the JVM uses. Deliberately not a foreign key, on the same terms as jvm_class_supertype.supertype_name: the scan drops nested classes and the generated jOOQ package and nothing ships the JDK, so a named class frequently has no census row and that is the ordinary case. A position naming no class has no row rather than a row with a placeholder, which covers a primitive, an array (whose component is the next step down), a type variable, and an unbounded wildcard. The type-variable case is the one worth stating twice: the erasure reads Object where the declaration names nothing, and this relation follows the declaration, so a method returning T has a return_type of Object and no row here
variance(CHARACTER VARYING, not null)-
NONE, EXTENDS or SUPER: the wildcard bound the position was written with, NONE where the source named the type directly. Carried rather than dropped because the three declare different things and the class name alone cannot tell them apart, so a consumer peeling an element type out of
? super Filmwould otherwise read it asFilmand be silently wrong about which direction the values flow. Always NONE at the root, a wildcard being a type-argument form
jvm_record_component
A record component of a record class in the census, read from the classfile RecordAttribute rather than from any bytecode; backs record-mapping facts.
Primary key: (source_name, class_name, component_name). Foreign key: (source_name, class_name) references jvm_class (source_name, class_name).
source_name(CHARACTER VARYING, not null)-
the owning class’s classpath entry, as on jvm_class; the key’s leading dimension
class_name(CHARACTER VARYING, not null)-
the fully-qualified Java class name as written
component_name(CHARACTER VARYING, not null)-
the record component name
position(INTEGER, not null)-
component position in the record header
display_type(CHARACTER VARYING, not null)-
erased display form of the component type, on the same terms as jvm_method.return_type
declared_type(CHARACTER VARYING, not null)-
the component type as the source declared it, on the same terms as jvm_method.declared_return_type. Read from the component’s own Signature attribute rather than from the accessor method the record generates, the component being where the declaration is
jvm_record_component_type_ref
The classes a record component’s declared type names, one row per position, on exactly the terms jvm_method_return_type_ref states. Its own relation beside its owner rather than a shared one discriminated by a member-kind column, which is the same reading the walk reach relations take: the three owners are three keys, a method return being keyed by a descriptor, a parameter adding a position and a component named on its own, so one relation would carry a column that is NULL by kind and could carry no foreign key at all. A reader whose question is uniform across the owners (the accessor hop, which stands on a member slot and does not care which arm produced it) unions them in a view, which is the layer where a reader’s question belongs.
Primary key: (source_name, class_name, component_name, type_path). Foreign key: (source_name, class_name, component_name) references jvm_record_component (source_name, class_name, component_name). Check: "VARIANCE" IN('NONE', 'EXTENDS', 'SUPER').
source_name(CHARACTER VARYING, not null)-
the owning class’s classpath entry, as on jvm_class; the key’s leading dimension
class_name(CHARACTER VARYING, not null)-
the fully-qualified Java class name as written
component_name(CHARACTER VARYING, not null)-
the owning record component’s name, as on jvm_record_component
type_path(CHARACTER VARYING, not null)-
the position within the declared type; the grammar is stated on jvm_method_return_type_ref.type_path
referenced_class(CHARACTER VARYING, not null)-
the fully-qualified binary name of the class named at this position; the omission rules are stated on jvm_method_return_type_ref.referenced_class
variance(CHARACTER VARYING, not null)-
NONE, EXTENDS or SUPER, as on jvm_method_return_type_ref.variance
jvm_scalar_type_field
A public static field whose declared type is exactly graphql.schema.GraphQLScalarType (backs @scalarType resolution). Filtered by that descriptor, which is why the selector is in the name: a total-sounding name for every static field would mislead about the contents. final is deliberately not required, the reflective resolver binding a non-final field just as well, so these are not necessarily constants.
Primary key: (source_name, class_name, field_name). Foreign key: (source_name, class_name) references jvm_class (source_name, class_name).
source_name(CHARACTER VARYING, not null)-
the owning class’s classpath entry, as on jvm_class; the key’s leading dimension
class_name(CHARACTER VARYING, not null)-
the fully-qualified Java class name as written
field_name(CHARACTER VARYING, not null)-
the field name, matched on the exact GraphQLScalarType descriptor