Package org.spongepowered.asm.mixin

## Annotation Type Overwrite

    @Documented
    @Retention(RUNTIME)
    @Target(METHOD)
    public @interface Overwrite

`Overwrite` can be applied on methods that need to be explicitly overwritten. By default an unannotated method will replace the bytecode of a method it collides with, but if the annotated member does not collide with a method in the target, a new method will be created. In contrast, `Overwrite` does not create new methods and requires a collision. Should no collision occur, a compile-time error is thrown.

### Optional Element Summary

Optional Elements
`java.lang.String[]` `aliases` The spongeian implementation (and therefore the standard Micromixin implementation) does not remap the name of aliased methods in INVOKESTATIC calls.

### Element Detail

#### aliases

    java.lang.String[] aliases

The spongeian implementation (and therefore the standard Micromixin implementation) does not remap the name of aliased methods in INVOKESTATIC calls. That is "working as intended" - but be aware that static methods should not be referenced if they are aliased.

The aliases of the method. Only one alias is selected from the given list, if none match an exception is thrown during transformation. The actual name of the method is discarded and will not play a role once aliases are defined.

Aliases are not affected by (@link #prefix() the prefix).

The spongeian Mixin specification advises against the usage of aliases. According to them aliases should only be used if the name of the target has changed. (The behaviour of aliases does not allow much more usecases anyways)

In the spongeian mixin implementation, aliases are not supported on non-private members (for this, the access modifier of the target member is being used, not the one of the member in the mixin class). The cited reason for this is that other mixins could add fields that would match the alias and thus invalidate caches. It is unclear why this is an issue in the spongeian implementation, but for compatibility reasons it is recommended to ensure that shadowed members with aliases are private. While micromixin-transformer and micromixin-remapper support the usage of aliases on non-private members, it will log a warning at application time when doing so and may in the future refuse to apply such mixins. Proceed with care.

Returns:
  The aliases to use.

Default:
  {}