google-guice Google Group

Re: Guice release schedule?

jeremy.ch...@gmail.com (Jeremy Chone) — Fri, 19 Mar 2010 00:23:10 UT

Max,
Did you get a response to your question? I would be curious to know as well.
I love Guice, just a little worry about the roadmap (the lack of information
on the subject kind of reminds me of Gears... I hope I am mistaken).
Jeremy,

Re: AssistedInjection FactoryProvider.newFactory performance - slow

krishnan.1...@gmail.com (Kartik Kumar) — Thu, 18 Mar 2010 20:37:01 UT

Not to belabor the obvious but I think there is an issue # 435 (to lazy to
look up the link) on AssistedInject and lock contention.

Re: AssistedInjection FactoryProvider.newFactory performance - slow

cprim...@currenex.com (cpea) — Thu, 18 Mar 2010 18:17:21 UT

Hi Fred,
Thanks for the reply, I will try switching to @AssistedInject and look
forward to getting the fix in the future.
To test this I created a simple junit test that loops 10k times and on
each iteration uses Guice (using assisted injection) to create an
object. At the end of the test it prints out the time to run. I was

Re: Creating more boilerplate with Guice

ffa...@gmail.com (Fred Faber) — Thu, 18 Mar 2010 13:35:54 UT

At that point you would simply have a considerable amount of domain factory
logic. The Guice boilerplate in itself is relatively thin. If the
boilerplate is the injection of N providers, then that at least can be
simplified to an injection of a Map<Class<? extends Foo>., Provider<Foo>>:
your factory switches off at you had it written, and once it determines what

Re: Creating more boilerplate with Guice

jason.m.fel...@gmail.com (Jason Felice) — Thu, 18 Mar 2010 08:31:12 UT

The use case which inspired the post has more complicated logic used to
decide the concrete implementation, where various case clauses inspect
different properties of a data bean which is the sole parameter. I was
trying to capture that with my contrived example (the 'inverted'), but
didn't think too much about it and missed the mark.

Re: Creating more boilerplate with Guice

jason.m.fel...@gmail.com (Jason Felice) — Thu, 18 Mar 2010 08:12:07 UT

I'm either missing some key pattern in the FP pattern book, or it's a matter
of taste: I find this kind of solution awkward. In the
single-method-on-strategy case, it is cleaner, but in the
multiple-method-on-strategy case you end up reinventing OO dispatch in a
probably-non-standard way. Hmm, I suppose you can work around this in

Re: Creating more boilerplate with Guice

marc...@gmail.com (Marcos Alcantara) — Thu, 18 Mar 2010 06:44:42 UT

Great... Solved one problem for me.. Thx
Sent from my iPhone

Re: Creating more boilerplate with Guice

krishnan.1...@gmail.com (Kartik Kumar) — Thu, 18 Mar 2010 06:34:43 UT

[link]
<[link]>This
could help.

Re: Creating more boilerplate with Guice

dha...@gmail.com (Dhanji R. Prasanna) — Thu, 18 Mar 2010 04:44:22 UT

On a slightly unrelated note, I take issue with the insinuation that
Functional languages do not do the strategy pattern well. I'd say higher
order programming achieves the same goal, and somewhat more elegantly than
the strategy pattern.
Dhanji.

Re: Creating more boilerplate with Guice

ffa...@gmail.com (Fred Faber) — Thu, 18 Mar 2010 04:19:31 UT

I think you'd be better off using a MapBinder. The boilerplate of guice
essentially disappears, with only your specific configuration needing to
consume a linearly incremental amount of code per new type.
Code below.
regards
-Fred
class FooFactory {
static class FooKey {
final char type;
final boolean inverted;

Creating more boilerplate with Guice

jason.m.fel...@gmail.com (Jason Felice) — Thu, 18 Mar 2010 03:57:07 UT

I just posted this blog article:
[link]
A note: While it seems to be a peculiar problem, I'm not slamming Guice,
Guice is still a big net win for us!
I post here for thoughts on this problem, and suggestions for solutions to
it.
Excerpt:

Re: AssistedInjection FactoryProvider.newFactory performance - slow

ffa...@gmail.com (Fred Faber) — Thu, 18 Mar 2010 00:20:06 UT

This is a known issue due to the way in which FactoryProvider2 operates.
For the time being, if you're seeing unacceptable performance, I suggest
using the @AssistedInject annotation on your implementation classes versus
the @Inject annotation. There is a solution on the table to adjust the
code, which will happen within the next month or so one way or the other.

Re: AssistedInjection FactoryProvider.newFactory performance - slow

cprim...@currenex.com (cpea) — Thu, 18 Mar 2010 00:02:52 UT

Sorry, I meant 7 seconds (not ms) for the auto generated factory, and
0.2 seconds for the hand-coded one.

AssistedInjection FactoryProvider.newFactory performance - slow

cprim...@currenex.com (cpea) — Wed, 17 Mar 2010 23:24:40 UT

When I use the AssistedInject to generate a factory class
automatically, object creation takes a significantly longer time than
hand-coding the factory. My test involves creating 10,000 objects in a
loop. With the FactoryProvider.newFactory in my binding, it takes 7ms
to run the test. If I replace the binding with my own factory class

Re: Guice release schedule?

jeremy.ch...@gmail.com (Jeremy Chone) — Wed, 17 Mar 2010 21:04:47 UT

Thanks Max for asking this question. I have been using 2.0 for a while now
(and I am happy with it), however, I hope the trunk/next release won't be
out of sync.
Jeremy,