● Standard: reference implementation for JSR 330
● Flexible: can map all sorts of metadata to bindings
● Type-safe: detailed messages when things go wrong
● Modular: multiple extensions available, OSGi-ready
● Fluent Java binding API
● Records generic information lost during erasure
● Can be driven by Java / annotations / XML / ...etc...
● New standard for Java dependency injection
// Constructor injection
// Field injection
// Setter injection
Extending JSR 330
● JSR 330 tells us how to mark dependencies
● and qualify them (just like with Plexus hints)
● But it does not say how to mark components
Identifying JSR 330 components
● Wrap the Class-Path up as a ClassSpace and scan it
● Look for classes with qualifiers such as @Named
● Empty @Named means "use class name" instead
● Binding type found by analysing class hierarchy
What is a dynamic application?
● OSGi lets us dynamically add / remove bundles
● ... without needing to restart the application
● This may add / remove qualified components
● ... but Guice bindings are static
Dynamic application vs. static bindings
● How can we resolve this mismatch?
● Need support for dynamic component collections!
● Backed by dynamic Iterable of qualified beans
● Iterables updated as injectors come and go
● Copy-on-iteration avoids synchronization overhead
● Weak-ref detects when Iterable not used anymore
● Watching application bean can remain a POJO
● Mediators detected just like any other component
● Created on-demand as bean instances created
● Removed when the watching bean is GC'd
● Just wrap your Class-Path as a ClassSpace
● ... install the QualifiedScannerModule
● and kick-start Guice injection as usual
What about Peaberry?
● Majority of plugin bindings tied to its lifecycle
● Can simply create one injector per plugin
● For plugin services that are not tied to the
lifecycle we need something more dynamic!
● Proxies backed by the OSGi Service Registry