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
On Jul 19, 2010, at 6:37 PM, Nick Chalko wrote:
I am working on JSR-303 support for the Google Web Tool Kit (gwt).
I am interested in using the apache bean validation as a starting
point and I want to get your feed back.
GWT does not support Reflection so any code that uses reflection would
have to be changed GWT code
I see a few ways this could be approached
Add a gwt subproject that works on the GWT specific parts
Fork the code and tune for GWT.
What is your take on this?
Is there any interest?
Do you think we can reasonably isolate the reflection code so this
will run on GWT.
R,
Nick
