Unused code generated in TypeClasses

[jwharm]

Every Java class that Java-GI generates for a GObject class or interface, contains an accompanying (inner) class to model the GTypeClass or GTypeInterface for that type. (In GIR data this is referred to as the “glib-type-struct”.) These helper classes represent native structs and contain accessor methods to read/write their fields. Most typeclasses contain a pointer to the parent class and (zero or more) function pointers for virtual methods. Java-GI generates callbacks for the function pointers that enable overriding them using a lambda (@FunctionalInterface object) or alternatively a java.lang.reflect.Method object. The output of this is a LOT of code: for every virtual method, Java-GI generates a field, three methods, and an interface that also contains three methods.

As a result, for most GObject classes and interfaces Java-GI generates a lot of code that is useful for just one purpose: overriding virtual methods.

The Java-GI function Types.register() that automatically registers a Java class in the GObject type system (including method overrides), calls the callback-override code with the java.lang.reflect.Method argument. The possibility to override a virtual method with a lambda (i.e. a @FunctionalInterface object) is not used here. Moreover, it is highly unlikely that this API is used by Java-GI users.

There are, however, two places in Java-GI where the lambda-based method override is used:

• when registering custom properties, the GObject::getProperty and GObject::setProperty virtual methods are overridden with lambdas;
• when registering a Gtk composite template class, GObject::dispose is overridden with a lambda.

If these three overrides are implemented directly (not using generated code), the lambda-based method-override functionality for typeclasses becomes redundant. It is relatively simple to change the RecordGenerator so it will not generate this code anymore.

As a result, almost 30K lines of code will not be generated anymore, which amounts to about 5% of all generated code.

On a related note, the readParentClass() and writeParentClass() methods can also be removed. There are other ways to find the parent type, and directly updating this field is a terrible idea. Removing these accessor methods will also slightly reduce the amount of generated code.