On Tue, Jul 20, 2010 at 6:44 AM, Matt Benson <[email protected]> wrote: > Hi Nick--so, the GWT alternative to reflection would be some form of > javascript inspection, or do they provide an API over that? I never got > around to giving GWT a try, so I am completely unfamiliar with how it works > beyond a vague awareness that everything compiles to javascript (if that's > even correct). It sounds like you're saying the entire app, including > bytecodes from third-party libraries, is ported and it all runs client-side, > with reflection being a (the?) java API that is conspicuously unavailable. > My initial reaction to this is that it this would seem likely to cause > problems working with many Java libraries. To go beyond Bean Validation > here, it sounds like a reflection analogue of slf4j might be in order, > whereby a secondary "reflection" API is defined, with implementation jars > provided at runtime. Applications/libraries wanting to provide support for > environments where java.reflect reflection is unavailable, but some > alternative exists, could then code to the redefined API. It happens that I > have contributed for some years to a library that includes such an API, and > have given thought over the years to incubating an overhaul of it at Apache > (targeted for Commons). If I've not guessed badly on any of the > fundamentals, this would seem a reasonable direction to take. > > -Matt >
Matt, GWT use Differed binding (http://code.google.com/webtoolkit/doc/1.6/FAQ_Client.html#What_is_Deferred_Binding?). My main question was, how isolated is the code that need reflection. My assumption is should only be needed in the code that actually validates an object graph. I will down load and start poking around in the code. My second question is, Is there interest a bval-gwt subproject? R, nick
