Creating conditions for inaccessible classes, methods and/or parameter types

[bjkeller]

Running Toradocu on org.apache.commons.collections4.bidimap.TreeBidiMap with --export-conditions (on randoop branch) get

    // void org.apache.commons.collections4.bidimap.TreeBidiMap.checkNonNullComparable(java.lang.Object o,org.apache.commons.collections4.bidimap.TreeBidiMap.DataElement dataElement)
    public static boolean m51_t0(org.apache.commons.collections4.bidimap.TreeBidiMap target, java.lang.Object o, org.apache.commons.collections4.bidimap.TreeBidiMap.DataElement dataElement) {
        // @throws java.lang.NullPointerException if o is null ==> args[0]==null
        return o == null;
    }

where checkNonNullComparable() is a private method of the class.

Though, the condition class doesn't compile because org.apache.commons.collections4.bidimap.TreeBidiMap.DataElement is package private.

[bjkeller]

A similar problem affects 14 classes in Commons Collections that have to be excluded from Toradocu-Randoop evaluation.

[bjkeller]

Also, not excluding private classes such as org.apache.commons.collections4.trie.AbstractPatriciaTrie

[albertogoffi]

A possible (partial?) solution could be place the condition class in the a package with the same name of the target class' package. What do you think?

[bjkeller]

I think that makes sense.

In general, the goal is that the condition classes compile, so whatever makes that possible. This won't be directly possible when the condition method has parameter types that are private. So, when the target class is private, as in

private class CannotBeUsedDirectly { 
  void subjectMethod(int val) { ... }
}

or when one of the parameter types is a private member of the target class

public class CanBeUsed {
  void subjectMethod(PrivateMember arg) { ... }
  private class PrivateMember {...}
}

My guess is that you can lift these to a public supertype in the condition method (keeping the correct types in the JSON). There may be conditions that cannot be expressed properly, but, regardless, I think you should be prepared to drop some conditions because they cannot be made public.

[albertogoffi]

Now Toradocu generates condition-checking methods only for non-private methods. Also, the condition-checking class has now the appropriate package definition (the package is the same as the target class).

Do we need additional checks for the parameter types of the condition-checking methods? In that case, can you provide me few example where the compilation of the condition-checking class fails because of the private type of the parameters?

[bjkeller]

I think this change should be sufficient, as i don't think it should be possible to compile the subject class with a parameter type with more restrictive access than the method.

[bjkeller]

This won't be an issue until issue #27 is fixed, but there is not enough information in org.toradocu.extractor.Type to determine the package name of a member class. At the moment, since there cannot be an enclosing class, it is sufficient to take the prefix of the qualified name such that qualifiedName is prefix + "." + name.

[bjkeller]

I'm going to close this because the original issue is resolved.