Removed nTypes from FunctorImplementationBuilderAbstract constructor; it is now passed as a parameter to buildLambaImplementationClass() at call time via table.nTypes(). This makes all builder instances stateless w.r.t. arity, so autoN in AutoRegister becomes a static final singleton like auto1 and auto2 — no more per-call allocation. Also removed the unused classOfFunctor field from AutoRegisterAbstract.
Split the single-module project into a Maven multi-module structure:
- jmdispatch-core: Pure dispatch table with no runtime dependencies. Supports lambda-based handler registration via
table.register(types, functor). - jmdispatch-auto: Annotation-driven auto-registration (
@Dispatch+AutoRegister). Depends on core + ASM for bytecode generation. - jmdispatch-sample-core: Collision demo using lambda functors (core only).
- jmdispatch-sample-auto: Collision + serialization demos using
@Dispatchannotation.
Breaking API change: autoregister() moved from DispatchTable to AutoRegister.autoregister(table, ...).
Bug fixes:
- Static
@Dispatchmethods failed when registered viaautoregister(table, instance)— the instance was incorrectly passed to the no-arg functor constructor. - Copy-paste error:
Functor1.classinstead ofFunctor2.classinAutoRegister.auto2field.
Design decisions:
- Core module has zero runtime dependencies (no ASM) — users who register handlers with lambdas don't pay for bytecode generation.
TestUtils(type hierarchy A/B/C/X/Y) is duplicated in both test modules rather than introducing a shared test-jar dependency, keeping the build simple.- Sample modules set
maven.deploy.skip=trueso only the two library artifacts are published to Maven Central. - Javadoc in core classes cleaned of all references to
@Dispatch/autoregistersince core doesn't depend on auto.