Am 18.10.2014 18:59, schrieb Peter Levart: [...]
The complete solution will require new API, but the java.lang.reflect.Proxy API could be improved a bit too. With introduction of default interface methods it is somehow broken now.
I find this a bit strange. A new API means at least JDK9. So JDK8 will stay broken in regards to the reflective Proxy. The only reason why we use it, is because it is really faster to create a reflective Proxy and use it for several cases. But basically it means we have no proxy solution in JDK8/9 for now that works for sure. Of course you can try a method handle with an invoke special, but how to get to the "private access" allowing lookup constructor? With reflection a security manager may prevent it (and does so on Google app engine for example)... Not to mention that it sounds wrong as well. The only other way is then "slow" class generation at runtime, with all the class loader fun, and again possible security managers forbidding things.
Default interface methods enable interface evolution, but break existing Proxy InvocationHandler(s) which are not prepared to handle new methods.
imho, that's only partially the problem. It depends on the usage of the proxy. If the purpose of the proxy is to simply redirect each and every method call to the proxies object, then it will work just fine as before. If you say it makes sense to not to redirect the default methods, you have lost the game, since there is no instance to make the reflective invocation on
So perhaps a small improvement to Proxz API could be to add new factory method that takes an additional a boolean flag indicating whether generated proxy should override default methods and forward their invocation to InvocationHandler or not. An all-or-nothing approach. I know that even that is not trivial. Generated proxy class can implement multiple interfaces and there can be conflicts. In that case, the easiest solution is to bail out and refuse to generate a proxy class with such combination of interfaces.
yeah, I guess I simply have a problem with the assumption that default methods are intended to allow a backwards compatible way of interface evolution. But the conflict case surely is the end of the line for this.
bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
