This situatioin can be regarded as a consequence of the interplay between the JLS bug described in 6640435 and a limitation of section 184.108.40.206 of the JLS. Here, a constraint of the kind T == Integer is found during the first step of type inference (the one taking into account actual vs. formal parameter types - JLS 220.127.116.11). However, since this constraint does NOT involve the type variable I being inferred, this constraint is simply discarded by javac.
During the second step of type inference (the one taking into account return type along with uninferred type variables' bounds) start from scatch. Moreover, since the the return type in the second call to the method getGenericValue() is not subject to an assigment conversion, no further constraints on T is derived in 18.104.22.168. The only constraint is thus Object >> Integer (being Object the bound of T), so that the inferred type of T is indeed glb(Object) = Object. This choice is not compliant with the signature of the method testSet, thus triggering the error.
Resuming, there are two possible solutions to this bug:
1) Propagate the constraint T==Integer from 22.214.171.124 to 126.96.36.199
2) Generalizing 188.8.131.52 in order to infer a constraint S >> T if the type variable T appear in return-type position of a generic method m1() whose evaluation is passed to another method m2() accepting an argument of type S.