> I guess that's enough optimising for now. The rest of the job is:
>
> 1) Write a proper test suite. Throw away the test classes that are
there
> and
> add some custom written ones and try to break xjavadoc - and fix
remaining
> bugs.
> 2) Put xjavadoc into xdoclet
> 3) Pick up Reverse XDoclet and XTags. (Konstantin is already working
on
> the
> gui I think)
Btw, I found an even easier way of doing this optimization:
Create an HaltException class which derives from ParseException and
throw it after reading ClassDeclaration but before the { sign. Catch the
exception, if instanceof HaltException then it's in halt, keep the
source file content in ProxyClass preferably in a WeakReference. Now
when user uses some of the inner methods like methods()/fields() run the
parser again, we can somehow pass the old SourceClass reference to
parser instead of creating one.
What's the gain? No threads. Are we going to create 600 threads? I think
it's problematic on linux for example and certainly doesn't scale for
higher number of classes.
What do you think? Should I spend time on it?
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
