It is true that we now have basically two separate EDSL, one in the
org.glassfish.hk2.utilities.binding package and one in the
org.glassfish.hk2.utilities package. If I had this to do over I would
put the second one in its own package to distinguish it from the other
dsl and other generic utilities. However, HK2 is at the point that we
want to maintain backwards compatibility and hence we won't be changing
packages at this time.
I also agree that the org.glassfish.hk2.utilities.binding is not very
well documented. That should be fixed. In theory if you are using
classes and things from this package you should not need anything from
the other package. (This is also true of the first EDSL). The
org.glassfish.hk2.utilities.binding is more like a "fluent" api, while
the other EDSL is "fluent-like" since it does not keep state and you
need to "finish" the descriptor yourself with a call to "build" or
"buildFactory". I think which one you like better is a matter of style.
If you enter a Jira asking for better documentation on the two EDSL
styles I will be sure to remember to write that documentation (one day).
I think that the DynamicConfiguration class is directly responsible for
holding descriptors to be added or removed from the system. It does
handle some very simple cases (maybe it should not) but in general its
job is different from a generic Descriptor builder. I can see adding a
method there specifically for constants, although at this point I think
it is a better idea to just leave it as is. Lets enhance the other
builders to make them more useable, since the DynamicConfiguration class
really has a different purpose.
On 12/2/2013 5:45 PM, cowwoc wrote:
> Hi,
>
> I'm attempting to migrate code from Guice to HK2. I wanted to share an
> outsider's point of view on the API.
>
> While I appreciate how much more powerful HK2's binding model is than
> Guice, I find it to be a total mess for basic use-cases.
>
> I found the following classes related to binding:
>
> * Binder
> * AbstractBinder
> * BuilderHelper
> * AbstractBindingBuilder
> * Descriptor
> * DescriptorImpl
> * AbstractActiveDescriptor
>
> and there are others. It seems I'm not the only one who is confused.
> See http://stackoverflow.com/q/17396165/14731 and
> http://stackoverflow.com/a/20128336/14731.
>
> What makes it worse is that some functionality is available one class,
> but other functionality is available in another class (e.g.
> bindFactory() in AbstractBinder but
> BuilderHelper.createConstantDescriptor() for constants). Many of these
> classes add very little code before redirecting to one another. Please
> refactor all this functionality under the DynamicConfiguration class
> and hide all the implementation details under the hood.
>
> I ran into this problem while trying to solve three simple use-cases:
>
> * Binding of type to constant/instance, with qualifier, in scope.
> * Binding of a Factory
> * Binding of a JSR 330 Provider
>
> Thanks,
> Gili
>