As someone who develops one of these frameworks, I can explain exactly why they don't generate XML metamodels at build time:
1) It's an enormous amount of work to develop both the tools and the metamodel. Java has a built-in metamodel (annotations) which is easy to work with and well understood by most developers. 2) It imposes significantly upon the end developer. Instead of just including a jar with your deployment, now you need to hook into the build system (ant, maven, or eclipse?). 90% of developers don't know how to do this and even fewer actually want to bother. 3) This is only an issue on GAE, not on other platforms. GAE is a tiny part of the Java developer community so there are very few tools available to support hooking into the build system, converting annotations to a metamodel, and exposing this metamodel at runtime. We're lucky to have the appengine-specific OS projects that we do. 4) This classloader limitation is an undocumented (and hopefully temporary) issue in GAE. Hell, we don't even know that this is the problem - there's no official statement on the matter, just a lot of trial-and-error-informed speculation. I've been developing for years on GAE and didn't realize the scope of this problem; I always thought "avoid classpath scanning and I'll be ok". Well it turns out that it's more complicated than that. And it only hits apps that reach a certain critical level of complexity... which I finally have. The upshot is that I wouldn't expect a lot of frameworks to adopt this model anytime soon. It's not that there aren't any - take a look at Slim3, it builds a metamodel at compile time. However, run some tests - AFAIK, they built the metamodel for the purpose of avoiding reflection overhead at runtime (a non-issue), not to avoid classloading, so it's possible that loading all those pre-generated stubs could make the problem even worse. This harkens back to one of my earlier points - it's hard to develop workarounds for a problem that we only barely understand. I could spend weeks developing a "solution" to this problem that might not even provide significant benefit. Jeff On Tue, Jun 19, 2012 at 9:23 AM, Jason Collins <[email protected]> wrote: > Joakim, you took the words right out of my mouth. > > It seems, in distributed computing with a solid versioning mechanism, > that everything that can be moved to a build-time operation is a > (potentially) huge win for global cost/performance. > > j > > On Jun 18, 2:40 pm, Joakim <[email protected]> wrote: >> I've been pondering for some time now why none of the frameworks seem to >> have realized that the configuration will never change after the build is >> complete. They should all ship something that generates an XML config from >> the class annotations (Ant plugin, an annotation processor for javac, >> anything), I can't imagine the amount of resources wasted globally because >> of the lack of this (though that likely says more about my imagination than >> anything else). >> >> My project: >> >> # of classes in WEB-INF/classes: >> Zero (I jar) >> >> Size of WEB-INF/classes: >> 0M >> >> # of jars in WEB-INF/lib: >> 44 >> >> Size of WEB-INF/lib: >> 34.5M >> >> # of classes registered with Objectify: >> Zero (I still haven't moved from JDO) >> >> # of classes registered with other means (any explicit classloading, ie >> JAX-RS): >> 100+ >> >> Fastest observed startup time: 35s >> Typical startup time: 45s >> Slowest startup time: deadlined 60s+ >> >> >> >> >> >> >> >> On Monday, June 18, 2012 9:58:29 AM UTC+2, Jeff Schnitzer wrote: >> > * My "sitemap" (ie the mapping of URIs to code) is determined by >> > @Path annotations on 80+ classes. This is the JAX-RS way. The >> > alternative is the history of defining all URIs in xml files like >> > web.xml or struts.xml - an approach that was wholly abandoned by the >> > Java community at least 5 years ago. > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
