Fix validation errors for workflows where generics and annotations don't correspond

[fsteeg]

In some workflows, the @In and @Out annotations do no correspond to the actual types, e.g.:

as-lines | // produces String
catch-object-exception | // consumes T, produces T -- but @Out says Object
decode-pica | // consumes String

Validation for this workflow fails, since decode-pica expects String but catch-object-exception declares that it produces Object.

I'm not sure how to approach this. Should this be solved by more advanced validation (look at the previous command or something), or would it be more appropriate to change something about the annotations (since by their annotations catch-object-exception and decode-pica are not compatible)?

[cboehme]

I stumbled over this problem as well. If a module uses generics, the annotations become quite uninformative. I think there are two aspects to this issue:

1. The verification of module compatibility should consider the inheritance of generic types. For instance, passing a String to a module which expects an Object is fine but the other way round does not work. This does not only apply to modules with generics but to all modules. In case of generics the annotations should always be set to the base type of the generic parameter (e.g. ObjectReceiver<T extends String, ...> should use @In(String.class) instead of Object.class)
2. When using a module with generic input and generic output it is not clear from the annotations whether input and output are of the same type. I am not sure if this is actually an issue or if we can safely assume that input and output types always match. If they do not, we might need an annotation to specify the relationship between input and output in order for allowing advanced validation as you suggested.