Yep. This is pretty darn close to DI. I would be willing to change the patch that I just put up to use Guice if that's what people wanted. I know some of our classes could use some DI loving to help with testability.
On Wed, Jul 11, 2012 at 11:57 AM, Andrew Purtell <[email protected]>wrote: > On Wed, Jul 11, 2012 at 10:50 AM, Elliott Clark <[email protected]> > wrote: > [...] > > > > The reflection option seems like it would be a big perf hit. Reflection > > basically means that nothing ever gets inlined so all function calls into > > metrics2 code would be very expensive. Since it seems like we are adding > > more and more instrumentation this perf impact would only grow. > > In addition as more hadoop versions come out all of our reflection code > > would get much more complicated and brittle. > > > > The conditionally loaded jar would be nice in that the JIT would only see > > one version of the factory classes on the classpath and everything could > be > > optimized just like any other jvm run jit'd code. In addition there are > > other places that we use reflection to do things conditionally and a > > conditionally loaded jar would be nice. > > Coprocessors are a solution close to conditionally loaded JARs: there > is not reflection, very frequently executed code would be JITed, the > only thing missing is direct inlining. > > More and more (useful) metrics are going into hot paths, we want all > three I think. > > We keep inching toward DI. > > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet > Hein (via Tom White) >
