|
I don't think so. We can't assume all users are going to be using Java 1.5 or greater.
It looks like we will have to take an educated guess in determining if the method takes a vararg parameter. Currently DWR remotes a varargs method: doStuff(int value, String... params) as doStuff(int value, String[] params) . Given the limitations we have to work with (any code can't be Java 1.5 specfic), I think the current behavior is acceptable. I think we can put in a fix for this but it will not be full-proof. Does any one have some ideas?
we do have quite a bit of 1.5 specific code, and we support 1.4 through retroweaver, so i think we could probably do something about this.
For 3.0 the problem as described no longer exists. It looks like DWR does not have a problem finding vararg methods. However, the vararg parameter is remoted as an array (as expected). This result of this is that you can't call a var args method from the browser like you would from java. For example:
This Java method: public void varArgs(String ...strings) { System.out.println(strings); } Is remoted as: TestVarArgs.varArgs = function(p0, callback) { return dwr.engine._execute(TestVarArgs._path, 'TestVarArgs', 'varArgs', p0, callback); }; So you can't do something like this in your JS (without losing arguments): TestVarArgs.varArgs("vararg1","vararg2", callback); If we want to support someting like this it looks like we are going to have to change how vararg methods are remoted in DefaultRemoter. Perhaps we can retrieve all of the argument and push them into the array. So the method would be remoted the same: dwr.engine._execute(TestVarArgs._path, 'TestVarArgs', 'varArgs', p0, callback); but p0 would contain all of the arguments. The problem with this approach is that it will complicate finding the callback function. Thoughts? |
||||||||||||||||||||||||||||||||||
Is there any restriction to use Java 5 API's?