Re: How to Contribute to River

[Mark Brouwer <ma...@cheiron.org>]

Bob Scheifler wrote:
> Rick Moynihan wrote:
>> Briefly, my main issue with these classes (and I guess other parts of 
>> Jini) is that code which uses these classes is hard to unit test 
>> because they don't have interfaces.
> 
> If the issue is just unit testing, what prevents you from simply writing
> your own alternate implementations of the classes and linking them in?

I know the question was for Rick, but nevertheless I like to take the
opportunity to react.

Around the 'expectation' the contract of some important functionality is
specified as an interface a bunch of tools have been developed, for
example a product such as EasyMock (for more info read
http://today.java.net/pub/a/today/2006/06/20/getting-started-with-easymock-2.html,
haven't used it so don't know whether it is handy or not). Also things
as Google Guice and other DI frameworks most times use in their examples
interfaces instead of classes that can be extended, resulting in a
mindset that interfaces is what people expect for DI (note I'm not
saying this is correct).

But my main argument against alternate implementations (by extension
that is), is that you often end up with those nasty constructors that
require proper arguments which you don't have or don't want to provide
or that even might fail at construction time. Together with all the
environmental assumptions that lie in the implementation of the class
you are extending, also you might drag in a lot of code just because of
the implementation.

Interfaces gives an ultimate freedom and allow for minimal dependencies
and I don't see why we can't factor out some of the functionality of SDM
e.g. into an interface, do you Bob?
-- 
Mark

Re: How to Contribute to River

[Mark Brouwer <ma...@cheiron.org>]

Bob Scheifler wrote:

>> Well that would make it hard to have multiple implementations as part of
>> the same JAR file, test sets, etc.
> 
> Start with an abstract class, and do all variants as subclasses of that?

While writing my posting I knew you were going to say this if you
couldn't resist to ignore me :-)
-- 
Mark

Re: How to Contribute to River

[Bob Scheifler <Bo...@Sun.COM>]

Mark Brouwer wrote:
>> I wasn't suggesting subclassing, rather complete reimplementation.
> 
> Well that would make it hard to have multiple implementations as part of
> the same JAR file, test sets, etc.

Start with an abstract class, and do all variants as subclasses of that?

- Bob

Re: How to Contribute to River

[Mark Brouwer <ma...@cheiron.org>]

Bob Scheifler wrote:
> Mark Brouwer wrote:
>> But my main argument against alternate implementations (by extension
>> that is),
> 
> I wasn't suggesting subclassing, rather complete reimplementation.

Well that would make it hard to have multiple implementations as part of
the same JAR file, test sets, etc. Different implementations with the
exactly the name seems problamatic to manage for multiple reasons. Not
even talking about the lack of tool support for creating your mocks.

>> Interfaces gives an ultimate freedom and allow for minimal dependencies
>> and I don't see why we can't factor out some of the functionality of SDM
>> e.g. into an interface, do you Bob?
> 
> Many things are possible, priority is the question.

Well that I consider a big leap forward :-) I agree with the priorities,
but I think it is worth an issue in JIRA (Rick?).
-- 
Mark

Re: How to Contribute to River

[Bob Scheifler <Bo...@Sun.COM>]

Mark Brouwer wrote:
> But my main argument against alternate implementations (by extension
> that is),

I wasn't suggesting subclassing, rather complete reimplementation.

> Interfaces gives an ultimate freedom and allow for minimal dependencies
> and I don't see why we can't factor out some of the functionality of SDM
> e.g. into an interface, do you Bob?

Many things are possible, priority is the question.

- Bob

Re: How to Contribute to River

[Bob Scheifler <Bo...@Sun.COM>]

Mark Brouwer wrote:
> Given the fact you mention tackling things that really are hard, can you
> give a hint about the things you are thinking about.

I don't have an agenda for River; I expect to largely be in a
review/advise/knowledge-transfer mode for the project.

- Bob

Re: How to Contribute to River

[Mark Brouwer <ma...@cheiron.org>]

Bob Scheifler wrote:
> Rick Moynihan wrote:
>> None of this stuff is particularly hard, and I don't mean to be picky, 
>> as there are clearly ways around some of these issues.  My problem is 
>> only that these things could all be a bit easier.
> 
> That's one of the things to wrestle with as we go forward, priority
> of making a bit easier things that aren't really particularly hard,
> vs tackling things that really are hard.

Given the fact you mention tackling things that really are hard, can you
give a hint about the things you are thinking about.
-- 
Mark

Re: How to Contribute to River

[Bob Scheifler <Bo...@Sun.COM>]

Rick Moynihan wrote:
> None of this stuff is particularly hard, and I don't mean to be picky, 
> as there are clearly ways around some of these issues.  My problem is 
> only that these things could all be a bit easier.

That's one of the things to wrestle with as we go forward, priority
of making a bit easier things that aren't really particularly hard,
vs tackling things that really are hard.

- Bob

Re: How to Contribute to River

[Mark Brouwer <ma...@cheiron.org>]

Hi Rick,

Rick Moynihan wrote:

> None of this stuff is particularly hard, and I don't mean to be picky, 
> as there are clearly ways around some of these issues.  My problem is 
> only that these things could all be a bit easier.  If River is going to 
> break API's for the repackaging to org.apache, why not also clean up 
> these issues through introducing a few interfaces etc?

I see no reason why the introduction of a few interfaces that will be
implemented by SDM e.g. (assuming the signature matches that of the
current methods) in a next release is going to break compatibility. The
preferred way from then on seems to be using interfaces in new API, but
people can continue to use SDM where they did in the past.

There might be a reason why this is not something we want to pursue but
no doubt we will be informed.
-- 
Mark

Re: How to Contribute to River

[Rick Moynihan <ri...@calicojack.co.uk>]

Mark Brouwer wrote:
> Bob Scheifler wrote:
>> Rick Moynihan wrote:
>>> Briefly, my main issue with these classes (and I guess other parts of 
>>> Jini) is that code which uses these classes is hard to unit test 
>>> because they don't have interfaces.
>>
>> If the issue is just unit testing, what prevents you from simply writing
>> your own alternate implementations of the classes and linking them in?
> 
> I know the question was for Rick, but nevertheless I like to take the
> opportunity to react.

Thanks for this, as your response is largely in line with my views and 
experience on the matter.  I also seem to have neglected to respond to 
this question.

> 
> Around the 'expectation' the contract of some important functionality is
> specified as an interface a bunch of tools have been developed, for
> example a product such as EasyMock (for more info read
> http://today.java.net/pub/a/today/2006/06/20/getting-started-with-easymock-2.html, 
> 
> haven't used it so don't know whether it is handy or not). Also things
> as Google Guice and other DI frameworks most times use in their examples
> interfaces instead of classes that can be extended, resulting in a
> mindset that interfaces is what people expect for DI (note I'm not
> saying this is correct).

I have no experience in using EasyMock or anything along those lines, 
instead preferring to create my own mock's where possible.  And I can't 
say that the experience of wrestling to make mocks out of the Jini 
classes was rewarding.

I'm also partial to dependency injection, and find the technique 
particularly useful, primarily because it helps to support unit testing. 
       Again, I've not been using a special DI framework for this. 
Instead I have found that Commons Digester can deliver this 
functionality, and for me works particularly well:

http://jakarta.apache.org/commons/digester/

> But my main argument against alternate implementations (by extension
> that is), is that you often end up with those nasty constructors that
> require proper arguments which you don't have or don't want to provide
> or that even might fail at construction time. Together with all the
> environmental assumptions that lie in the implementation of the class
> you are extending, also you might drag in a lot of code just because of
> the implementation.

My experience with Jini and mocking is that it can be done, and I did 
infact manage to mock out various classes (e.g. the 
ServiceDiscoveryManager) for my purposes.  Here (as Mark suggests) I 
used extension to create my MockServiceDiscoveryManager class.  I then 
added a few extra methods to allow me to configure different 
expected/unexpected behaviors into the implementation.

I must admit that It didn't occur to me that I could have just created 
my own implementation of the class in the SDM namespace and linked it in 
at runtime.  Unfortunately I think this approach is problematic as it is 
likely that to get a decent test coverage the developer will want to 
actually provide multiple implementations of the mock, i.e. one that 
throws RemoteExceptions, one that behaves correctly etc...  It seems to 
me that the right place to determine which class to use is the test, not 
the build script.  Developers may also want their mock SDM to be named 
in a manner that indicates the mocks behaviour e.g. 
RemoteExceptionThrowingServiceDiscoveryManager.

Regarding Dependency Injection, you ideally want to remove knowledge of 
the implementation until runtime.  Unfortunately with the Jini classes 
as they stand this isn't really possible.

Another example I've mentioned before is the partitioning of 
responsibilities on LookupDiscoveryManager also makes this awkward 
because their is no interface that unifies *ALL* the responsibilities of 
the class (other than the class itself).

> Interfaces gives an ultimate freedom and allow for minimal dependencies
> and I don't see why we can't factor out some of the functionality of SDM
> e.g. into an interface, do you Bob?

None of this stuff is particularly hard, and I don't mean to be picky, 
as there are clearly ways around some of these issues.  My problem is 
only that these things could all be a bit easier.  If River is going to 
break API's for the repackaging to org.apache, why not also clean up 
these issues through introducing a few interfaces etc?

If these issues can't be resolved, would it be worthwhile creating 
configurable mock implementations of these Jini classes??

--
Rick Moynihan
Software Engineer
Calico Jack LTD
http://www.calicojack.co.uk/