[rfc][icedtea-web] TeeOutputStream Dependency Fix

[Jacob Wisor]

On 09/09/2014 05:15 PM, Omair Majid wrote:
> * Jiri Vanek <jvanek at redhat.com> [2014-09-09 11:03]:
>> Unluckily, yes, this have spread in ITW a lot.  The api is being dirty by
>> non-private utility methods which
>>   - should be private
>>   - should be tested
>
> Can you give some examples of this? If it's really, really private,
> maybe it shouldn't be tested?
>
>> I would probably like to set some kind of rule for this to future. To test
>> such private methods via reflection stub. It will move test "api" issues
>> from compile time to runtime, but by retrospective look, it is probably
>> worthy.
>
> Working in a language with static types, the type system can be a great
> friend, not only finding and helping fix errors before they can happen
> at runtime, but also helping discover things (for example, all pieces of
> code that invoke a certain method).

This is true indeed. :-)

> Reflection can work against static typing and make things more difficult
 > to see and figure out. Please be really, really sure you need to use
> reflection before you decide to use it (or worse, mandate it).

I am not sure I get your point, but reflection is subject to static typing like 
any other code and data in Java. You are right when you're saying that careless 
use of reflection in applications/programs may lead to disastrous mess and break 
things like finding calling hierarchies or method references etc.

However, we are talking about code unit tests here, not about using reflection 
in the application itself. Their purpose it to test for the proper inner working 
of classes. In some cases application classes do some more or less complex stuff 
internally which should be protected from regressions when modifying or 
extending these classes. This internal stuff usually is or should be private, 
but should still be tested. Testing the public members only may not always 
reveal /all/ regressions introduced or may prove very difficult or impossible to 
test for their internal state, since classes are supposed to hide their internal 
state by design. Using reflection, we can monitor and thus test for the internal 
state of a class without providing hidden or undocumented public or protected 
members just for testing purposes. This approach keeps classes clean and still 
allows for proper testing.

Jacob