Niclas Hedhman wrote:
On Mon, Apr 13, 2009 at 5:42 PM, Georg Ragaller <[email protected]> wrote:
Although I don't know exactly what happens in qi4j internals, my rough
understanding says, that the restrictions should not be a no go,
since reflection is fully supported on own classes. So if the core does not
use reflection on other classes, it should work.
Perhaps the sticking point is really the JRE class whitelist. All the other
restriction are more related to architectural or configuration issues, I
think.
Well, I can see 4 potential issues;
1. We are using some forbidden class/method.
Yes, that's the whitelist point, thats needs checking.
2. They don't allow setAccessible() on Fields et al.
My understanding is that they do, that's what I meant with "..
reflection is fully supported on own classes...
", to cite the docs (follow Stuarts link):
"...An application is allowed full, unrestricted, reflective access to
its own classes. It may query any private members, use
|java.lang.reflect.AccessibleObject.setAccessible()|, and read/set
private members..."
3. We generate sub-classes on the fly with ASM. They may no allow that.
I thought it was cglib? Nevertheless, this should only be a classloader
problem, but to cite again: "...
Custom class loading is fully supported under App Engine."
4. Our use of generics is fairly extensive, and if their JVM is not
Sun's, then there might be corner-cases which doesn't behave the same,
i.e. Qi4j ends up clueless..
Due to type erasure, the byte code should not see anything of the
generic types. There is some reflective access to static type
information related to generics, but that should be handled with the
promise of the citation above regarding reflection.
So I think you should be more confident. ;-)
Cheers, Georg
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
