Gin leaks class names when creating via GWT.create()

[GoogleCodeExporter]

When Gin uses GWT.create() to instantiate an object, it double-checks that 
GWT.create() is returning an object of the desired type.  That's all fine.

Gin generates code of the following sort
 (http://code.google.com/p/google-gin/source/browse/trunk/src/com/google/gwt/inject/rebind/binding/CallGwtDotCreateBinding.java)

   Object created = GWT.create(MyClass.class);
   if (!created instanceof MyClass) {
     throw new CreationException("looooooong message with FQCN");
   }

That CreationException includes the fully qualified classname;   this is 
helpful for debugging, but a bad idea for production code with stripped class 
metadata.  It both bloats the code (a few kb in our app), and leaks class names 
that are otherwise completely hidden.

Original issue reported on code.google.com by awi...@google.com on 19 Nov 2010 at 6:11

[GoogleCodeExporter]

There's little to no value having the error at runtime, so how about using 
'assert' instead?
If, on the other hand, the exception is expected to be handled at runtime 
(possibly handled by an UncaughtExceptionHandler and, for example, sent back to 
the server), then passing the Class<?> to the exception could be a solution, 
but maybe even just the stack trace could be enough (if you log exceptions back 
to your server, you're probably using emulated stack and resymbolisation, so 
you could trace the exception back to the GIN-generated code, which AFAIK 
contains meaningful method names allowing you to easily link back to your 
bindings)

Original comment by t.broyer on 19 Nov 2010 at 7:18

[GoogleCodeExporter]

Changing this to assert would be perfect - I can't fathom this ever being 
something caught at runtime.  (If someone really, really wanted to do so - they 
should write their own @Provides method and not rely on an undocumented 
corner-case of Gin's implementation).

Original comment by awi...@google.com on 19 Nov 2010 at 7:22

[GoogleCodeExporter]

I created a small fix along the lines you suggested. Please review it here: 
http://codereview.appspot.com/3230041/

Note that this still throws an exception at runtime, that cannot be avoided.

Original comment by aragos on 19 Nov 2010 at 11:09

• Changed state: Review
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Submitted at r154.

Original comment by aragos on 20 Nov 2010 at 10:19

• Changed state: Fixed