Guice and constructors-as-function-objects

[Tim Boudreau]

I just moved a framework for working with Netty, which relies on Guice very heavily, to GitHub.  It's called Acteur.  It has a somewhat unusual programming model, as it's more-or-less functional programming in Java, using Guice and custom, reentrant scopes to drive the whole thing.

I'm curious if the Guice folks here see it as neat, or a strange abuse of Guice:

http://timboudreau.com/blog/Acteur/read

-Tim

[Tim Peierls]

I think it's both. :-)

<nitpick>

The "Why Constructors?" section makes me nervous, though. To say, as you do in the first bullet, that a constructor "is the one guaranteed thread-safe unsynchronized method an object can have" makes it sound as though you don't need to worry about safe publication of the object being constructed as long as you don't leak "this". But you only get the guarantee that other threads will see completely initialized values of final fields. (See http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#d5e28755 for an example.)

Your second bullet hints at this, but in a way that seems to imply that you don't have to worry about the thread-safety of objects referred to by final fields. Final doesn't magically confer thread-safety; if I have a final field that points to a mutable object, that object still needs to be made thread-safe if the final field is shared by multiple threads. All that final does is guarantee complete initialization (in the absence of leaked "this").

And you don't mention one of the big drawbacks of constructors, which is that you can't in general safely call overridden methods in constructor bodies.

</nitpick>

That said, I think the Guice abuse is very cool.

--tim

[Tim Boudreau]

The "Why Constructors?" section makes me nervous, though. To say, as you do in the first bullet, that a constructor "is the one guaranteed thread-safe unsynchronized method an object can have" makes it sound as though you don't need to worry about safe publication of the object being constructed as long as you don't leak "this". But you only get the guarantee that other threads will see completely initialized values of final fields. (See http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#d5e28755 for an example.)

Yeah, you're right.  I'm so unused to using non-final fields, I forget that most of the world was weaned on JavaBeans :-)

 

And you don't mention one of the big drawbacks of constructors, which is that you can't in general safely call overridden methods in constructor bodies.

Also true - IMO, 99% of the time anything you want people to override should be abstract and the rest should be final, but people do that too.  The dangers of coding for an audience that is yourself :-)

 

That said, I think the Guice abuse is very cool.

Thanks!

-Tim 

[Tim Boudreau]

I get the feeling I was trying to present too much too fast in the original post about Acteur and it may have puzzled some folks.

So here's a stripped down, no-web-framework version of how to do any sort of processing-pipeline while taking advantage of Guice, using it:

https://timboudreau.com/blog/ActeurPattern/read

As I've said before, it's a slightly odd use of Guice, but it is quite powerful.

-Tim