> Here is a short list of what I can think of now. Deferring class parsing > is a good idea. it should boost the speed.
Definitely. classes()/superclass()/etc should all consult JavaParser if not scanned yet, otherwise return the scanned class. Such tricks are also possible for tags, parameters and so on. A user rarely modifies many classes so excluding classes from javadoc loading/parsing can make it super fast. I'm sure we can make it n times faster where n>10 :o) > 2) if a class implements an interface only available as binary, it seems > it's not discovered. see xdocletgui. nothing shows up under tag libraries. I'll investigate it. > Enhancements that can be done. > 1) simplify the java grammar. it's useless/time consuming to parse the > method bodies. Can we ignore method bodies? I think we can only prevent jjtree from creating various AST classes/instances such as blablaExpression/SynchronizedBlock/etc. Right? > 2) general javacc optimisations, like making parser static etc. Yup, JavaParser should be a utility class, probably with a repository of already scanned classes (assuming lazy scanning classes is used). > structural enhancements/refactorings > 1) expose less of the api. make more classes/methods package private. > 2) remove the classicwrapper/xml packages. they were for testing at an > early stage, but the junit stuff is sufficient now. 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
