Mixins
Nota
Esta página aplica-se a SpongeCommon, SpongeForge e SpongeVanilla, como esses três repositórios utilizam Mixins para ligar para as implementações subjacentes (servidor de Minecraft Vanilla e Forge).
Mixins são uma forma de modificar o código Java no tempo de execução adicionando comportamentos a classes. Estes permitem transplantar comportamentos específicos para objetos do Minecraft que já existentes. Os Mixins são necessários para o funcionamento do Sponge coremod.
Uma introdução básica a alguns dos principais conceitos subjacentes a funcionalidade do mixin que estamos usando para implementar a esponja está disponível no Mixin Wiki
Começa com princípios absolutos. Se você é um desenvolvedor java experiente, sinta-se livre para pular para a seção 4, onde os componentes são discutidos.
If you’re looking to get started writing mixins, we also strongly recommend carefully examining all of the examples in the SpongeCommon repository which are extensively documented and cover many of the more complex scenarios. You should also consult the Javadoc of the Mixin repository itself, since almost everything is already documented.
Nota
The Mixin project will be servicing a number of other projects in addition to Sponge itself. Therefore, Mixin has its own documentation together with the repository.
Mixins and Inner Classes
While you can use lambdas, anonymous and inner classes inside mixins, you cannot use an anonymous/inner class within
another anonymous/inner class that is also inside a mixin, unless one of the inner classes is static
.
Isto significa que expressões como a seguir causará mixin a falhar e trazer morte e destruição sobre todos os que tentam usam a Sponge.
return new Collection<ItemStack>() {
@Override
public Iterator<ItemStack> iterator() {
return new Iterator<ItemStack>() {
// THIS WILL NOT WORK!
@Override
public boolean hasNext() {
// Code skipped
}
@Override
public ItemStack next() {
// Code skipped
}
};
}
// Other methods skipped
};
This applies to all classes that are annotated with @Mixin
. Classes that are not touched by the mixin processor may make use of those
features. There are two ways to work around this.
One option is to use a separate utility class, as unlike your mixin class that utility class will still exist at runtime, while your mixin class will be merged into the specified target class. The following code therefore will work.
public class SampleCollection implements Collection<ItemStack> {
private final TargetClass target;
public SampleCollection(TargetClass target) {
this.target = target;
}
@Override
public Iterator<ItemStack> iterator() {
return new Iterator<ItemStack>() {
@Override
public boolean hasNext() {
// Code skipped
}
@Override
public ItemStack next() {
// Code skipped
}
};
}
// Other methods skipped
}
@Mixin(TargetClass.class)
public abstract class SomeMixin {
public Collection<ItemStack> someFunction() {
return new SampleCollection((TargetClass) (Object) this);
}
}
The other option is simply to place all of the nested inner classes directly into the mixin or one of its methods, as opposed to one inside the other. For example:
@Mixin(TargetClass.class)
public abstract class SomeMixin {
private final class SampleIterator implements Iterator<ItemStack> {
@Override
public boolean hasNext() {
// Code skipped
}
@Override
public ItemStack next() {
// Code skipped
}
}
public Collection<ItemStack> someFunction() {
return new Collection<ItemStack>() {
@Override
public Iterator<ItemStack> iterator() {
return new SampleIterator();
}
// Other methods skipped
};
}
}