[rfc][icedtea-web] TeeOutputStream Dependency Fix

Jiri Vanek jvanek at redhat.com
Tue Sep 9 15:26:18 UTC 2014

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?

What I mean are private methods which actually do the job, but are not intended to be visible.

Artificial example:

public String processStringByID(String s){
return processString(s, 10)
public String processStringByName(String s){
return processString(s, 20)

private String processString(String s, int x){
do a lot of magic

In this example is better to test both public methods, no metter of implementation in 
processString(s, i)

But there are cases, where is better to test the final method doing the real work.
In such case, it stops to be private and changes to package private.

So I have started to incline to solution, where each

public class ClassInITW

have its

public class TestClass extends Test

in tests folder, which contains

private class TestableClassInITW extends ClassInITW

which is redeclaring all private such private methods, by theirs accessible siblings, calliung its 
super by reflection. And the tests are then run above tis artificial extension.

What do you think?

>> 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). 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 100% agree with you:( And I dont know clean way out.


More information about the distro-pkg-dev mailing list