It seems that it's not technically possible to attach generic info 100% correctly and completely. Therefore, integrators are encouraged to detect client proxies and subclasses and work around the problem via reflection.

Also note that since 2.3.0.Beta1 and 3.0.0.Alpha11 classes generated by Weld are marked with the SYNTHETIC modifier.

Actually, the referenced JDK bugs are not the only problems we've found. We're not able to attach the generic info properly if a method return type or parameters use a type variable declared deeper in the class hierarchy, e.g.:

class Foo extends Bar<String> {
}
class Bar<T> {
  T get() {
  }
}

If a proxy class extends Foo, it also declares a method get() with signature TT;. However, T is not available in the scope of Foo (even if we add a class signature which would be something like LBar<Ljava/lang/String;>;) and the reflection API returns corrupted data. I'm not quite sure whether it should work or not. But this is how it's implemented in Oracle JDK 7 and 8.

So we've decided to add a special marker interface into the Weld API to allow to detect a Weld proxy/subclass.

Unfortunately, there are some JDK bugs which could block merging of pull/900.

I have released classfilewriter 1.1.0.Final

We've added this functionality to jboss-classfilewriter: https://github.com/jbossas/jboss-classfilewriter/pull/4. Once 1.0.6.Final is released we're ready to add method signatures to proxy methods. We also consider making this configurable so that it's possible to disable this in some edge scenarios.

Well, there is a marker interface already - org.jboss.weld.bean.proxy.ProxyObject. But it's not part of the Weld API and should not be used outside the weld codebase.