It was not an inital goal of GWT to support reflection. Also it will never be a goal of GWT to support the entire reflection API and capabilities of java. This would cause extreme overhead for a browser client app.
However, bean introspection is what really is required by many GWT clients and actually it is already supported - e.g. by javax.validation that is supported in core GWT.
A problem is that many other (open source) projects and frameworks for GWT also need this but it is not exposed via a common API. So they create their own "solution".
As a result you end up with the opposit of the inital goal: you have the introspection code generated for multiple frameworks in the same client causing even more overhead.
I would raise my voice to create a common solution for bean introspection within the GWT project that could be used by javax.validation support but also by other frameworks.
The minimal requirements are:
* retrieve the properties of a bean via bean class
* read a property value from a bean via bean instance and property name
* write a property value in a bean via bean instance, property name and value
* determine the type of a property via bean class and property name
I see two problems to discuss:
1. There is no common Java API for bean introspection that is suitable here. We should check if there is one that is most commonly accepted or wheter we should create a new one.
However, the API should be more on the scope of a JSR (I do not want to make it too complicated and go for a real JSR) and not be inside a gwt-user.jar that many architects do not want to see on the server as a dependency for common code modules.
2. How to determine which beans to support in the GWT reflection? Supporting all beans would be too much overhead. Requiring GWT.create for each bean would conflict with other purposes of generation as unfortunately GWT.create does not take the expected result type as 2nd arg. So maybe something like configurable marker interfaces might be a solution. Also java.io.Serializable could be a candidate.
BTW: I already started a discussion on G+ about this and got some positive feedback:
https://plus.google.com/116004699596425048754/posts/4zTzAEnFSNA
But as I learned G+ is not the right platform for long term discussions. Therefore I started this thread.
Cheers
Jörg
-- However, bean introspection is what really is required by many GWT clients and actually it is already supported - e.g. by javax.validation that is supported in core GWT.
A problem is that many other (open source) projects and frameworks for GWT also need this but it is not exposed via a common API. So they create their own "solution".
As a result you end up with the opposit of the inital goal: you have the introspection code generated for multiple frameworks in the same client causing even more overhead.
I would raise my voice to create a common solution for bean introspection within the GWT project that could be used by javax.validation support but also by other frameworks.
The minimal requirements are:
* retrieve the properties of a bean via bean class
* read a property value from a bean via bean instance and property name
* write a property value in a bean via bean instance, property name and value
* determine the type of a property via bean class and property name
I see two problems to discuss:
1. There is no common Java API for bean introspection that is suitable here. We should check if there is one that is most commonly accepted or wheter we should create a new one.
However, the API should be more on the scope of a JSR (I do not want to make it too complicated and go for a real JSR) and not be inside a gwt-user.jar that many architects do not want to see on the server as a dependency for common code modules.
2. How to determine which beans to support in the GWT reflection? Supporting all beans would be too much overhead. Requiring GWT.create for each bean would conflict with other purposes of generation as unfortunately GWT.create does not take the expected result type as 2nd arg. So maybe something like configurable marker interfaces might be a solution. Also java.io.Serializable could be a candidate.
BTW: I already started a discussion on G+ about this and got some positive feedback:
https://plus.google.com/116004699596425048754/posts/4zTzAEnFSNA
But as I learned G+ is not the right platform for long term discussions. Therefore I started this thread.
Cheers
Jörg
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment