LazberryRegistryFramework

Sure — here's a detailed English write-up you could use for a portfolio, GitHub About section, or project description.

Lazberry Registry Framework (LRF) is a lightweight Inversion of Control (IoC) and Dependency Injection (DI) framework built specifically for Spigot/Paper Minecraft server plugins. I designed and implemented it from the ground up, aiming to bring the kind of dependency management developers take for granted in frameworks like Spring or Guice into the Minecraft plugin ecosystem — without the runtime overhead or unnecessary abstraction layers those frameworks carry for a use case they were never built for.

The core problem LRF solves is boilerplate. In a typical Bukkit/Spigot plugin, developers manually instantiate every service, manager, listener, and command handler inside onEnable(), wire their dependencies by hand, and manage teardown logic in onDisable() with no structural guarantees. As a plugin grows, this becomes a tangle of manual object graphs that's easy to break and hard to reason about. LRF replaces that with a constructor-based dependency injection container: developers annotate a class with @ComponenT, declare its dependencies as constructor parameters, and the framework resolves and instantiates the entire object graph automatically at boot time via classpath scanning and reflection.

Architecturally, the framework is built around a few key mechanisms. A DependencyContainer acts as the central IoC registry, recursively resolving constructor parameters into a directed dependency graph and instantiating beans bottom-up. To prevent infinite recursion from cyclic references, the container tracks an active construction path and throws a dedicated CircularDependencyException the moment a cycle is detected, rather than letting the JVM stack overflow silently. A PackageScanner handles classpath discovery using Guava's ClassPath utility, filtering candidate classes through multiple stages — skipping interfaces and abstract classes, respecting @ConsumableClass and @Virtual exclusion markers, checking server-version compatibility, and evaluating @Conditional predicates so components can be conditionally registered based on runtime environment (for example, only enabling a component on a proxy-network server versus a standalone server).

Beyond basic DI, LRF includes a configuration injection bridge (@ConfigObject/@ConfigValue) that maps YAML configuration values directly into typed Java records or fields, removing the need for manual FileConfiguration parsing. It also wraps beans with ByteBuddy-generated proxies to support AOP-style behavior, and provides annotation-driven registration for common plugin building blocks — @Commands, @Listeners, and @TASK for scheduled repeating jobs — so developers don't need to manually call Bukkit's registration APIs for each one.

Lifecycle management is one of the framework's more deliberate design choices. Instead of letting subclasses override onEnable()/onDisable() directly, LRF locks those methods as final on its abstract base class and exposes onLrfEnable()/onLrfDisable() hooks instead. This guarantees that the IoC bootstrap sequence — context registration, classpath scanning, bean assembly, task binding — always completes in a fixed order before any user code runs, and that teardown always happens in the correct reverse order: cancelling scheduled tasks, running @GracefulShutdown-prioritized cleanup handlers, and finally purging the bean container to avoid classloader memory leaks across plugin reloads.

The project also distinguishes between two tiers of failure. A small set of framework-defined exceptions (VirtualClassInjectException, CircularDependencyException, NotCompatibleWithServerException, and others) represent hard, fail-fast conditions that abort the affected operation immediately, since they indicate a structural misconfiguration that shouldn't be allowed to proceed. Everything else — such as a single class failing to load during classpath scanning — is treated as a non-critical, recoverable condition that gets logged rather than halting the entire plugin boot sequence, so one bad class doesn't take the whole server down.

I built this while working as a Minecraft plugin developer, about six months into professional Java development, largely because I wanted to understand how IoC containers work internally rather than just using one. It's distributed via JitPack for easy Gradle/Maven integration, and the README is structured with a Quick Start guide up front — installation, annotations, and working code examples — with the deeper architectural rationale (design invariants, exception hierarchy, boot/teardown pipeline mechanics) documented separately for anyone who wants to dig into the internals.