This page aims to address terms, acronyms, abbreviations, expressions, etc. and define them within as broad a scope as possible without describing technicalities or how to use them. It is complementary to actual documentation on how to use the tools and subsystem of Mixin and should only be used to get a quick, general idea of what a term means in the context of Mixin usage and learning. This glossary should also be taken with a grain of salt, as much as feedback will try to be used to make the definitions as accurate as possible, it can be as unreliable as any Wiki page.
It is advised to read the Introduction to Mixins (WIP) page.

Seeing as this page is likely to change a lot with time as terms, both official and common usage ones, may vary over time and need many amendments as both Mixin and associated libraries evolve and get used in different contexts; it feels wise to add a section on best practices for contributing to this page in the long run.

If you wish to contribute it is appreciated to use references to external sources whenever possible, preferably the official Mixin Wiki, the Mixin javadoc and the official MixinExtras Wiki. If not, base your definitions on feedback from experienced devs and be willing to be scrutinized.
Due to the amount of potential areas that could be edited, it would also be appreciated to always specify which definitions you're adding or editing in your edit summary messages. If necessary, split your edit into different smaller edits to be able to more clearly indicate which definitions were modified.

When you are doubtful on a term's definition, add a FIXME above the relevant text with text in italics until a more confident definition can be found. Definitions should generally take the form of itemized lists with the term above the list's first items. Synonyms should be grouped together. Footnotes references describing the same resource and so on should use the exact same text so that they both redirect to the same footnote.

TODO notes should always describe what should be added there and should ideally be in italics

This is under heavy construction and probably contains inaccuracies, likely redundancies, certainly inefficient definitions and most definitely is missing relatively important terms

1. When used as a single term in the form of a proper noun, references the Mixin Subsystem as a whole. Mixin is a subsystem with the primary purpose of allowing a developer to describe modifications to be made at runtime using code. See Introduction to Mixins (WIP)
2. “a Mixin” or “a Mixin Class” references instances of classes or interfaces that are annotated with @Mixin, and will be merged with a target class as a means to modify it.

1. In the context of a Mixin class being merged into a target class, it means adding new members and interfaces from the Mixin class into the target class's bytecode.

1. A companion library for the Mixin subsystem primarily authored by Llamalad7. MixinExtras focuses on giving more versatile, precise and compatible injectors and general Mixin usage utility. MixinExtras is bundled with Fabric since Loader version 0.15; MixinExtras 0.5.0 has been bundled with Fabric since Loader version 0.17.0; See the MixinExtras Wiki.

1. Expressions referring to using Mixin to modify a target. For instance, “mixing into ServerLevel” would mean using a Mixin to modify the ServerLevel class.

1. References the IntelliJ Minecraft Development Plugin. It is very frequently used for Mixin development due to the added convenience, autocompletion and error detection it provides. See the plugin's home page.

1. Bytecode is a set of less readable, computer-oriented instructions, which code running on the Java Virtual Machine will be compiled into. Mixin works with bytecode as opposed to “Source” code, both for the Mixins to be applied and the code to target, “source” code being the decompiled/pre-compilation code, and as such, whilst source code can be used to infer bytecode, one should always prioritize bytecode for precise targeting or for certain targets which may not be reliably in the same position or order in the bytecode compared to a decompilation. See Reading the Minecraft source's relevant section on bytecode.

1. A class signature encodes type information about a class or interface declaration. It describes any type parameters of the class or interface, and lists its direct superclass and direct superinterfaces, if any. A type parameter is described by its name, followed by any class bound and interface bounds.
2. A method signature encodes the name, modifiers and type information about a method declaration. It describes any type parameters of the method, the types of any formal parameters, the return type, and the types of any exceptions declared in the method's throws clause.
3. A field signature encodes the name and the type of a field, formal parameter, local variable, or record component declaration.

1. A field descriptor represents the type of a field, parameter, local variable, or value.
2. See the below table for possible field descriptors.

1. A method descriptor contains zero or more parameter descriptors, representing the types of parameters that the method takes, and a return descriptor, representing the type of the value that the method returns. Note this does not include the name.
2. For example the descriptor of

   Object method(int i, double d, Thread t) {...}

   is

   (IDLjava/lang/Thread;)Ljava/lang/Object;

1. In Java, synthetic members and constructs refers to constructs added by the Java compiler into the compiled bytecode that do not have a source code equivalent. For instance, an anonymous class is given synthetic final fields which are used to be able to reference values of the enclosing method the anonymous class is declared in.
   • Synthetic members can be targeted by Mixin as Mixin targets bytecode rather than source.

Technical article on callback injectors, Mixin Wiki: Advanced Mixin Usage; Callback Injectors
MixinExtras Wiki: MixinExtras Wiki Home Page

1. Most commonly, references a “callback injector”. This consists of a “handler method” or “handler”, which is the annotated method to inject. The method will be annotated in order to specify where and how to inject a “callback” to the handler. This callback is a set of instructions added to the target method's bytecode that will call back to the merged handler method.

1. In the context of Mixins, a method decorated by an injector annotation that will be merged and then invoked/called within a series of “callback” instructions that will be injected based on the annotation's information.

1. A series of injected instructions that will invoke the associated handler method based on that method's injection point definition.

1. An injection point is the primary value used by Mixin to determine where to insert the callback instructions for a given injector. Injection points are typically passed in the @At annotation's value field. Certain injection points are self-sufficient, such as “HEAD” as it will simply try and target the earliest possible point in the target method, whilst others may necessitate more discriminators to have a specific target like “INVOKE” which will need a . Injection points are used to search for specific Bytecode operations within the boundaries of the target method.
   1. The injection point “reference” refers to the documentation of Mixin's built-in injection points. See the Mixin Wiki's injection point reference page.
2. In some cases, injection point may refer to the specific point an injector's callback will be inserted, resulting both from an injection point and other discriminators.