Skip to content

FAQ

Jump to bottom Edit New page
Matthias Ngeo edited this page May 16, 2020 · 22 revisions

Table Of Contents

General

Why does the project require Java 11 and above?

Chimera uses several new APIs and language features introduced in Java 9 & above.

  • Collection factory methods, i.e. List.of(...), Set.of(...), Map.of(...)
  • Local type inference
  • VarHandle API introduced to modify inaccessible fields in Brigadier classes

We could use Java 10, or Java 9 if we refrain from using local type inference. However, neither has LTS and are no longer supported. Hence Java 11 which has LTS as the minimum required version.

We understand that most servers and plugins are using Java 8; that most developers cannot/will not use the library. Nevertheless, we stand by our decision to use Java 11. We encourage developers and server owners to upgrade to Java 11+ to leverage on the improvements to the language and JVM over the 6 years since Java 8 was released.

What is Chimera's deprecation & Minecraft version support policy?

The project is stable and breaking API changes are extremely unlikely. That being said, breaking changes may be introduced in major or minor releases.

Chimera will only support the latest Minecraft version at the time of release. We have no plans to support older versions of the game.

How do I use SNAPSHOT releases?

Use the snapshot repository.

<repository>
  <id>chimera-snapshots</id>
  <url>https://repo.karuslabs.com/repository/chimera-snapshots/</url>
</repository>

API Design Decisions

Why does Chimera Commands require NMS?

Interactions between Brigadier and NMS are complex and intertwined. It is extremely difficult and inefficient to rely on reflection to dance between Spigot and NMS types. In addition, Cartesian types rely on the NMS ArgumentVec types which again makes it impractical to use reflection.

In summary, NMS provides better correctness guarantees and performance over reflection.

Why doesn't Chimera Commands have a caching mechanism?

Early development builds of Chimera supported caching of suggestions and parsed arguments. However, we ran into issues that blocked progress.

Chiefly was the frequency at which the server was asked to provide suggestions which led to the cache being both bloated and stale, rendering it ineffective. It also caused memory leaks as it prevented the cleaning-up of Player objects.

In the end, we felt it to be more hassle than worth and that it can be better implemented in 3rd-party custom types if the need arises.

Why must fields annotated with @Bind be public and final?

Requiring fields annotated with @Bind to be public both facilitates code generation and simplifies the resultant code. To support non-public fields will pose additional and needless complexity when accessing the fields in the generated code. Furthermore, encapsulation will be broken if non-public fields are accessed in another (generated) class.

Mutable @Bind fields introduce a slew of unexpected and suprising behaviour

Add a custom footer
Clone this wiki locally