> > Assuming that 80% of templates will generate new classes instead of > > mutating an existing class we can definitely make it faster by not > > instantiating jjtree AST objects. The best solution would be a runtime > > I'm not following here. What kind of templates would want to *modify* > existing sources? > -Or more specifically: esisting sources' javadocs (cause that's the only > thing you can > modify with xjavadoc).
We don't have such templates currently, but what stops us from letting user do that? I mean write a template which generates equals() methods from persistent fields and generates that method into the same class, not a new one, not a derived one. Or you could go the reverse path, you have a web.xml file, now you want to run a chunk of web_xml.j and add ejb-refs to that already built file. Quite handy for web.xml/etc which are easy to create for the first time and mostly are composed of merge files of welcomefile/security/its instead of dramatically dynamic content like ejb-jar.xml. The xdocletgui also modifies files. > One grammar, two parsers. OK! But switchable in runtime. > > Flyweight is the way to go. I implemented a simple form of it with the > > XJavaDoc.getXClass method, so all parameters/return-types/classes are > > lazy loaded and the XClass pointer is null until it's accessed actually. > > The flyweight pattern has nothing to do with lazy loading. It's about > storing > extrinsic state as lightweight members (ints) and passing that state to a > shared > object before accessing it. See > http://www.enteract.com/%7Ebradapp/javapats.html#Flyweight "Use sharing to support large numbers of fine-grained objects efficiently." From GOF book. So we share primitives/classes/etc and we also lazy load/instantiate them. > XJavaDoc.getXClass(String,boolean) with true is ProxyClass. This means > that > when you do a > superclass() on a class, you'll get an instance of ProxyClass. You can > call > qualifiedName() > on that instance without anything happening, but if you try to call any > other method, the ProxyClass > will ask for the real instance (the subject) by calling > XJavaDoc.getXClass(String,boolean) with false. Amazing. > This mix of lazy loading and proxy is quite efficient, but not enough. Jjtree is guilty here, and ... we just started optimizing it recently. > I guess what you're talking about is to lazy-instantiate the Xxxx[] > arrays. > That can be done too. Lazyloading everything possible. Currently we lazy load XClasses, right? But when we load/scan it, we create all XMethod/XConstructor/Xetc object too except again XClass refs of parameter types/etc which are lazy loaded, but XMethod objects are created for all methods of the XClass. I argue in most cases you just want to first check if a class derives from class x and has class level @tag y and then move on working on that class and maybe (maybe) methods of that classes. Fairly reasonable argument imho. Take a look at our own SubTask-derived classes, We check if ofType="EntityBean" and havingClassTag="ejb:bean" and then bother to process that class. Even further than not instantiating XMethod objects is stop parsing that class by checking ofType/havingClassTag!! So just quit parsing the whole compilation unit if it doesn't implement EntityBean! But that's the extreme :o) > True. XJavaDoc should only be instantiated with setDir, _not_ with > setFiles. > If dir is known, we can load classes on demand. You're absolutely right, that's why I killed dirscanner's use in XJavaDoc altogether. > Good, so we'll not try to be compatible with the javadoc API. Being able > to > use > javadoc doclets is not a big issue, and if you think the xdoclet migration > with the > current xjavadoc API is ok, then let's forget about javadoc API. Don't support docletclass. But try to be as compatible as you can. type()/doc()/etc are mini-differences which are easy to handle imho. Ara. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
