[news.eclipse.webtools.jsf] Re: Reporting problems from AbstractContextS

[Vadim Dmitriev <dmgloss@xxxxxxx>]

Several cases, that can be improved:

I. Array case:

Let's take the following class declaration as starting point:

class ExtendedArrayElement extends ArrayElement{ ... }

1. Current type comparator compare non-simple-class signatures only as
Strings. I.e. A can be assigned to B if A = "[[[ArrayElement" and B =
"[[[ArrayElement" (signatures strings equals). And not if A =
"[[[ExtendedArrayElement", which is technically not correct.
2. There is one special case for arrays, which is not covered either: if
A = "[[[Ljava.lang.Object", then it can be assigned to B =
"[Ljava.lang.Object;", which TypeComparator reports as wrong.


II. Parametrized types case:

With parametrized types there are some complicated cases, all of which
drill to resolving type parameters and substituting them with actual
types.

My guess parametrized types comparison should be done it three steps
(checking if A can be assigned to B):
1. check if A extends or implements B. If it does, then extract type
parameters of A
2. Substitute type parameters variables with actual types
3. Check base types and types arguments one-by-one for compatibility.

For example:

class StringMap< N > extends HashMap< String, N > {...}

If we need to check compatibility of A = StringMap<Integer> with B =
Map< String, Number >, then we must:
1. Find if A extends or implements B (in this case StringMap implements
Map)
2. Substitute StringMap's interface Map type parameters with actual
types: Map< K = String, V = N = Integer >
3. Check if Map< String, Integer > (interface of type A with resolved
type parameters) can  be assigned to B = Map<String, Number>. In this
case - it can be assigned.

I haven't gave it much thought, though implemented this logic already.
If you are somehow interested - check "SignatureComparator" class in my
attachment here [1].

[1] - https://bugs.eclipse.org/bugs/show_bug.cgi?id=219160