On Feb 27, 2012, at 10:02 PM, Romain Manni-Bucau wrote: > Was my analysis so the question is do we still need to capture them like it > or can we use more simple setters/getters?
The accessors are generated regardless if field or getters/setters are used. > Note: the code i pasted in my previous email is the one which is generated > from the injector. You might have to give me a line number as I don't see that in the NativeMethodAccessorImpl.java you posted in your previous email. > Ps: maybe i looked too fast but i didnt see jaxb-impl in tomee It's part of the jvm as of Java 6, so it's no longer something we ship. That said, if we wanted to certify our JAX-WS stack, we'd have to upgrade to 2.2 which means putting the jaxb impl in an endorsed dir (same as @Resource.lookup) -David > Le 28 févr. 2012 06:36, "David Blevins" <david.blev...@gmail.com> a écrit : > >> >> On Feb 26, 2012, at 11:59 PM, Romain Manni-Bucau wrote: >> >>> 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). >> >> That's a deceptively similar, but unrelated bit of code. Those are for >> the java.lang.reflect API. >> >> I grabbed the JAXB RI source and dug around (svn co >> https://svn.java.net/svn/jaxb~version2/tags/jaxb-2_1_9). This appears to >> be the mechanism it uses to determine if the class has already been >> generated: >> >> >> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/com/sun/xml/internal/bind/v2/runtime/reflect/opt/Injector.java?av=f#112 >> >> Basically a weak hashmap of classloaders and "Injector" instances where >> each "Injector" holds a hashmap of classes that have been generated. >> >> Not sure how we get around it other than an AccessorFactory. >> >>> Custom accessors is probably the key. >> >> Perhaps one that just instantiates the generated Accessors we've captured. >> >> >> -David >> >>> >>> 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 >>>> >>>> >> >>
