did you look http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/reflect/NativeMethodAccessorImpl.java ?
seems this class usage/generation is not a simple try { loadClass() } catch (...) { generate(); } it is generated if it is often used (> 15 times by default if i didnt look too quickly). Custom accessors is probably the key. - Romain 2012/2/27 David Blevins <david.blev...@gmail.com> > > On Sep 26, 2011, at 12:43 AM, David Blevins wrote: > > > # JAXB Accessors > > > > One of the biggest polluters of the class space is JAXB as it generates > accessors for all the fields. First thought is, gee, I wonder if we can do > that at build time and keep the class definitions. If there's some way we > could write down those classes, it could save us a lot of trouble at > runtime. We'd get a great speed boost on the cold start -- which is where > unit test performance lives. > > > > A while back I did some perf testing of our OpenEJB 3.0 speed and JAXB > was nearly half of the time it took to boot. We have a bigger JAXB tree > than we did and that can easily account for a sliver of the slightly slower > embedded speed. > > > > The classes exist, so there has to be some way to write them to disk > even if there is no magical flag that will make the JAXB RI do it for us. > Would be great to know if such a flag did exist. If someone is looking > for a research problem, this would be a great one. > > Did some work on this. https://issues.apache.org/jira/browse/TOMEE-143 > > With a JavaAgent, we monitor all classes created and their bytecode. > Anything that is a "$JaxbAccessor" class is written to disk. The new > openejb-jee-accessors module contains all these accessors. > > $ ls -lh target/openejb-jee-accessors-4.0.0-beta-3-SNAPSHOT.jar > -rw-r--r-- 1 dblevins dblevins 596K Feb 26 15:48 > target/openejb-jee-accessors-4.0.0-beta-3-SNAPSHOT.jar > > $ jar tvf target/openejb-jee-accessors-4.0.0-beta-3-SNAPSHOT.jar | grep > 'WebApp' > 666 Sun Feb 26 15:48:22 PST 2012 > org/apache/openejb/jee/WebApp$JaxbAccessorF_absoluteOrdering.class > 608 Sun Feb 26 15:48:22 PST 2012 > org/apache/openejb/jee/WebApp$JaxbAccessorF_contextParam.class > 652 Sun Feb 26 15:48:22 PST 2012 > org/apache/openejb/jee/WebApp$JaxbAccessorF_dataSource.class > 610 Sun Feb 26 15:48:22 PST 2012 > org/apache/openejb/jee/WebApp$JaxbAccessorF_distributable.class > 654 Sun Feb 26 15:48:22 PST 2012 > org/apache/openejb/jee/WebApp$JaxbAccessorF_ejbLocalRef.class > 644 Sun Feb 26 15:48:22 PST 2012 > org/apache/openejb/jee/WebApp$JaxbAccessorF_ejbRef.class > 648 Sun Feb 26 15:48:22 PST 2012 > org/apache/openejb/jee/WebApp$JaxbAccessorF_envEntry.class > 602 Sun Feb 26 15:48:22 PST 2012 > org/apache/openejb/jee/WebApp$JaxbAccessorF_errorPage.class > 596 Sun Feb 26 15:48:22 PST 2012 > org/apache/openejb/jee/WebApp$JaxbAccessorF_filter.class > 610 Sun Feb 26 15:48:22 PST 2012 > org/apache/openejb/jee/WebApp$JaxbAccessorF_filterMapping.class > 640 Sun Feb 26 15:48:22 PST 2012 > org/apache/openejb/jee/WebApp$JaxbAccessorF_icon.class > 602 Sun Feb 26 15:48:22 PST 2012 > org/apache/openejb/jee/WebApp$JaxbAccessorF_jspConfig.class > [....] > > $ jar tvf target/openejb-jee-accessors-4.0.0-beta-3-SNAPSHOT.jar | grep > -c 'class$' > 966 > > Soo... all that and it doesn't seem to work :) > > mingus:~/openejb/examples 04:13:17 > $ for n in simple-stateless* ; do (cd $n && mvn clean install); done | > egrep 'Time elapsed|JAXBContext' > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.918 > sec > JAXBContext.newInstance 403 org.apache.openejb.jee.EjbJar > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.341 > sec > > I think we're darn close though. > > I'd like to shift gears and work on more classpath scanning performance > boosts, if someone wants to pickup this task and see what we might have to > do to get JAXB to see the classes we've generated, that'd be great. > > Could shave half a second or a second off of even a simple test. > > > -David > >