As previous evaluations have suggested, this bug is due to the fact that the subclass T2a is inheriting the static member T2.m() whose signature conflicts with its static member T2a.m() (argument types are different).
JLS 184.108.40.206 state that:
"It is a compile time error if a type declaration T has a member method m1 and there exists a method m2 declared in T or a supertype of T such that all of the following conditions hold:
* m1 and m2 have the same name.
* m2 is accessible from T.
* The signature of m1 is not a subsignature (??8.4.2) of the signature of m2.
* m1 or some method m1 overrides (directly or indirectly) has the same erasure as m2 or some method m2 overrides (directly or indirectly). "
The last condition is the one that matters here. That condition ensures that type erasure can never generate two methods with the same signature in the same class (which would be inconsistent).
A good point where to insert this check is in Check.checkOverride. However special care is required since we must be sure to not generate inappropriate errors (e.g. we must skip constructors, non inherited members, etc.).
This new implementation of checkOverrides has the advantage of detecting errors earlier. In fact, in a scenario in which two non-static, non overriding methods are inherited by a given class, javac used to be able to report the error only after having applied type-erasure on method symbols and generated bridges for generic inherited methods (which is the last step of the compiler pipeline before code generation). With this new implementation javac is able to detect the error while attributing the class (and this is the correct behaviour since the class is not well-formed wrt to the JLS 220.127.116.11).