Objective

Develop a new, purpose-built API for ProtocolLib that ensures compatibility with past, current, and future versions of Minecraft. This new API aims to streamline the codebase by distinguishing between public-facing components for plugins and internal components, facilitating easier and quicker future updates.

Goals

1. Backward Compatibility: Maintain support for existing plugins by deprecating the current API and delegating its functionality to the new one. This will provide ample time for plugin developers to transition without disrupting their workflows.

2. Codebase Segmentation: Clearly separate the public API components from internal ones. This separation will help in simplifying maintenance, reducing the risk of accidental changes to the API, and making it easier for developers to understand and use the API correctly.

3. Abstraction and Decoupling: Abstract, decouple, and generalize most parts of the code to be more self-contained. This will enhance modularity, making the system more robust and adaptable to future changes. Self-contained modules will also make it easier to test, debug, and extend functionality without unintended side effects.

Implementation Steps

1. Document the components of the current API and how they are utilized.
2. Design the new API structure, focusing on modularity, clarity, and abstraction.
3. Implement the new API, ensuring it can delegate to the old API for backward compatibility.
4. Deprecate the current API and provide migration guides for plugin developers.

This approach will help us overcome the limitations of the nearly 12-year-old API, setting the stage for a more flexible and maintainable future for ProtocolLib.

1. Current API

• sync/async packet listener
  • priority
  • opt-in event-loop process
  • read only listeners (monitor)
• async timeout listener
• packet event
  • post send/process callback
  • scheduled packet (related to post send callback)
  • clone?
• packet container
  • read/write from/to buffer
  • clone
  • wrapper access
• wire packet
  • id + buffer
• protocol/packet type constants/registry
• utility
  • minecraft version
  • buffer helper with wrapper support
• wrappers

I haven't had the time to start working on this yet, so we don't have anything concrete planned beyond what's written above. Since the main goal is to rewrite the entire API, a complete overhaul of the StructureModifier/Reflection API seems feasible. Additionally, implementing a way to bind the current API to the new one would be desirable to maintain backwards compatibility in future releases.

Just to inform: I would be up for designing & implementing a new API to replace the current StructureModifier construct, which has (at least) one major issue that will make ProtocolLib cause warning messages starting from JDK 23, and will make it incompatible with a future jdk version (in short: I am speaking of the use of IMPL_LOOKUP, which is currently the only way to update fields in records. The retreival of that field value is done using sun.misc.Unsafe methods that were deprecated in JDK 23 & print warning messages when used [see JEP 471], and will be removed in a future version).

Not sure if there is something planned into that direction already, would be great if some insight could be shared in that case :)