Nice guys!
I am very inexperienced with threads, so I would never have spotted the
deadlock by just reading the code.
Did you "see" it or did you experience the deadlock, Konstantin? If you saw
it, Im really impressed, because
I have tried to understand threads for a very long time, and I never seem to
get it completely.
Anyway, we're now three active committers on xjavadoc, and that's good for
time-to-market. I'm still baffled with
the multithreading approach Ara came up with. I only implementeded it. By
now it seems to me you're both very much
up to speed with xjavadoc's under the hood workings. Isn't JavaCC great?
There are some issues you should know about that I discovered when running
xjavadoc on the Xalan sources
(which I did because I was curious about how much xjavadoc can gulp).
1) Unicode: If the sources have some \uxxxx in it, the parser will choke. It
doesn't if we modify the grammar to use
JAVA_UNICODE_ESCAPE=true;
UNICODE_INPUT=false;
, but it also seems that it degrades the performance. We should support it,
but I think it can wait for a bit.
One way to solve it is to provide two different parsers, one with unicode
enabled and one without. Can be achieved
by preprocessing the grammar with XDoclet's ReplaceCopy task (see samples)
and generate parser into two different
packages. Then we can add a -unicode runtime flag which indicates which one
to use.
2) Class resolving. I have experienced some problems if a class imports both
a package (say foo.bar.*) and also
a class in the same package (say foo.bar.Grunt), because of ambiguity. I
have solved this temporarily by juggling
in SourceClass.qualify(). -But we should verify with the java language spec
to see what the exact semantics are.
3) Trailing ; (semicolons). Many sources have kinda this:
public abstract Foo bar();;
or
public Foo bar() {};
or something like that..
The issue is that this is wrong according to the language spec, but both
javac and javadoc accepts it, and therefore
there will always be some sources around that uses it. If there is an easy
way (which doesn't degrade persformance)
to make the grammar accept it, we'll support it. Otherwise not. It's not
hard for people to remove some semicolons
as long as xjavadoc reports where the problem is (it does). -But you should
be aware of it, because it will happen if you
run xjavadoc on large sources like Ant or Xalan.
4) We should design a little class hierarchy with as many oddities as
possible and use that as test data for our
JUnit tests. The Hello alone is no good, neither are the xdoclet samples.
They're too ordinary. What we need to test
especially is:
-javadocs in front of methods/classes with/without modifiers (Because as far
as the parser is concerned, the modifier/no modifier
situations are treated differently).
-tricky import ambiguities (as described above).
-nested inner classes.
-anonymous inner classes.
-references to nonexisting classes (like there is a lot of when you use
xdoclet).
-modifying docs (on methods/classes with/without modifiers) and saving them.
-reading back the modified and saved classes and do asserts in junit test.
-adding docs to undocumented classes/methods, both with and without
modifiers
-verify that we don't have any more deadlocks/race conditions.
-verify that the tag parameter stuff works properly for read,update and
delete (update should do an add if the tag doesn't exist)
-verify that doc indentation is aligned with the class or method when saving
(must do this manually)
-do all the above that applies to fields and methods too.
-test if sources with unicode escapes work properly.
-this list (plus your additions) should be in the header of the XJavaDocTest
class(es), so we can mark whether the tests are implemented or not)
-the test hierarchy should of course compile, and the junit target shoul
depend on them being compiled.
One other idea I have is to write a javadoc doclet which scans a big source
tree and generates JUnit test classes (using xdoclet's
template engine.) This is a good way to test if xjavadoc works the same way
as javadoc. This shouldn't be too hard to do, and it
would make us really sure that xjavadoc is ready for action.
Can you think of anything else?
I'll be very busy this week, and won't be able to do much, and the week
after I'm on holiday (skiing in switzerland, yohoo),
so I hope you can start on some of this. I'll leave it up to you to
prioritise the items and assign them among us. This
should really be added to the SF tracker under xjavadoc, but I don't have
time to do that now.
Keep up the excellent work!
Cheers,
Aslak
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Ara
> Abrahamian
> Sent: 24. februar 2002 20:44
> To: 'Konstantin Pribluda'; [EMAIL PROTECTED]
> Subject: RE: [Xdoclet-devel] CVS update: xjavadoc/src/xjavadoc
> XJavaDoc.java
>
>
> Yup that was a deadlock scenario, thanks for fixing it.
>
> Ara.
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:xdoclet-devel-
> > [EMAIL PROTECTED]] On Behalf Of Konstantin Pribluda
> > Sent: Sunday, February 24, 2002 9:50 PM
> > To: [EMAIL PROTECTED]
> > Subject: [Xdoclet-devel] CVS update: xjavadoc/src/xjavadoc
> XJavaDoc.java
> >
> > User: ko5tik
> > Date: 02/02/24 10:19:30
> >
> > Modified: src/xjavadoc XJavaDoc.java
> > Log:
> > resolved deadlok. acquire lock on source class before starting
> > parser.
> >
> > Revision Changes Path
> > 1.16 +655 -654 xjavadoc/src/xjavadoc/XJavaDoc.java
> >
> > Index: XJavaDoc.java
> > ===================================================================
> > RCS file: /cvsroot/xdoclet/xjavadoc/src/xjavadoc/XJavaDoc.java,v
> > retrieving revision 1.15
> > retrieving revision 1.16
> > diff -u -w -r1.15 -r1.16
> > --- XJavaDoc.java 24 Feb 2002 04:38:56 -0000 1.15
> > +++ XJavaDoc.java 24 Feb 2002 18:19:30 -0000 1.16
> > @@ -291,10 +291,11 @@
> > SourceClass sourceClass = new SourceClass(null,
> qualifiedName,
> > f);
> >
> > ParseThread parseThread = new ParseThread(sourceClass);
> > - parseThread.start();
> > // We must wait here until the first part of the parsing
> is
> > done.
> > // we'll be notified by the parser when it's done
> > synchronized (sourceClass.getParseLock()) {
> > + parseThread.start();
> > +
> > try {
> > sourceClass.getParseLock().wait();
> > } catch (InterruptedException e) {
> >
> >
> >
> >
> > _______________________________________________
> > Xdoclet-devel mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
>
>
> _________________________________________________________
> 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
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
