Issue Details (XML | Word | Printable)

Key: XJD-41
Type: Improvement Improvement
Status: Resolved Resolved
Resolution: Fixed
Priority: Critical Critical
Assignee: xdoclet-devel (Use for new issues)
Reporter: Hao Chen
Votes: 38
Watchers: 25
Operations

If you were logged in you would be able to see more operations.
XJavaDoc

Support Java 1.5 Syntax ?

Created: 01/Mar/04 09:11 AM   Updated: 26/Jan/09 12:51 PM
Component/s: Parser
Affects Version/s: 1.0.2
Fix Version/s: 1.5

Time Tracking:
Original Estimate: Not Specified
Remaining Estimate: 0 minutes
Time Spent - 1 hour, 30 minutes
Time Spent: 1 hour, 30 minutes
Time Spent - 1 hour, 30 minutes

File Attachments: 1. Zip Archive xjavadoc-1.1-j5-src.zip (3.05 MB)
2. Java Archive File xjavadoc-1.1-j5-v2.jar (221 kB)
3. Java Archive File xjavadoc-1.1-j5-v3.jar (221 kB)
4. Java Archive File xjavadoc-1.1-j5-v4.jar (221 kB)
5. Zip Archive xjavadoc-1.1-j5.zip (240 kB)
6. File xjavadoc-jdk15-patch.diff (3 kB)
7. Zip Archive xjavadoc-src-1.1-j5-v4.zip (3.23 MB)

Issue Links:
Depends
 
Duplicate
 
Related issue (no dependency)
 


 Description  « Hide
Is there any plan to upgrade the parser to support Java 1.5 syntax?

 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Walter Mundt added a comment - 21/Apr/04 04:24 PM
Here's a patch I posted to the mailing list awhile ago when JIRA was down to make the parser not blow up with some of the new generics and for-each syntax. It's pretty basic -- nested parameterized types break it, and there are a few other things it doesn't like much. Better than nothing, though.

Gili added a comment - 05/Sep/04 08:21 PM
Hey! Can you guys please incorporate this into an official xdoclet 1.x release soon please? Java 1.5 final is due out at the end of the month and xdoclet 2.x is due out in a long while so we need this fix now.

Please fix it.

Heiko W. Rupp added a comment - 06/Sep/04 12:53 AM
Walter,
could you incorporate enum support?
I guess those will appear soon in 1.5 sources ..

 Heiko

Gili added a comment - 11/Sep/04 04:45 PM
Guys, J2SE 5.0 now gives warnings if you use "raw" types like Map, List as opposed to Map<Object>, List<Object> etc... it's getting more and more annoying to use xdoclet w/o J2SE 5.0 support. Any ETA on this fix?

bryan hunt added a comment - 25/Sep/04 01:31 PM
yep, I want to move to hibernate 3 and java 1.5. Xdoclet code
generation is the only thing holding me back.

Yannick Menager added a comment - 26/Sep/04 05:10 AM
will somebody apply this patch sometime in my lifetime ? :(

Heiko W. Rupp added a comment - 26/Sep/04 07:13 AM
Yannick,
as I don't know how old you are or in what medical condition, I can't answer this one ...


This patch will not make it into xdoclet 1.2.2, but will be incorporated afterwards.

The patch is incomplete and needs more tweaking

bryan hunt added a comment - 26/Sep/04 07:18 AM
I am trying to decide if in future I should use the hibernate
code generation tools or go in the opposite direction and drive
it all from my source code.

Would you imagine that by January ( when I guess hibernate 3 will
be stable ) that xdoclet will support java 1.5/5 and hibernate 3
syntax ?

It would be usefull to know this as I could then decide to use
hibernate to drive everything or to use xdoclet instead.

--b


Heiko W. Rupp added a comment - 26/Sep/04 08:38 AM
I am sure, that there will be at least a snapshot of a release that supports JDK 5 until then.
But I don't think it is a good idea to either
- hold this release until JDK 5 support is fully in
- deliver the next release with support for some but not all
new constructs in JDK 5.

bryan hunt added a comment - 26/Sep/04 08:41 AM
Thank you for the clarification Heiko

--b

Gili added a comment - 26/Sep/04 10:51 PM
I can't wait until January. It's already been months since this issue was reported and JDK 1.5 throws warnings left and right if you use raw collections classes; rather annoying that. As a workaround, is there some way for me to tell hibernate.doclet to not process JDK 1.5 files? I tried excluding them from the <fileset> but the problem is that the files with xdoclet markups depend on classes that make use of JDK 1.5 and so xdoclet complains about missing dependencies.

Is there a workaround whereby xdoclet marked-up files can remain in JDK 1.4, while depending on other classes that make use of JDK 1.5 and xdoclet will not complain?

I apologize if I seem to be pushing for this issue a bit too strongly, but if you guys can spend a few days getting a proper patch in place it would be much appreciated.

Heiko W. Rupp added a comment - 27/Sep/04 01:18 AM
Don't get me wrong. I did not say "wait until january".

Can't you use '-source 1.4' option to javac?

Gili added a comment - 27/Sep/04 01:38 AM
Even if you could do "-source 1.4", which isn't supported in JDK 1.5 as far as I know, it would not help. Remember that xdoclet is parsing the java files, not the class files.

I wish I knew how to sort the open issues by votes because somehow I suspect that this issue has the most votes of all open issues. I know, eight votes is a joke :) but then again, our community is small.

I personally view xdoclet as being mostly feature-complete. It would be nice to get it working, as is, under JDK 1.5 before adding new features.

Lastly, I don't know what internal parser you guys use, but if it is something standard like ANTLR, I am sure the JDK 1.5 grammar is floating around (other projects require it) and perhaps we can just plug one in.

bryan hunt added a comment - 27/Sep/04 06:16 AM

Yes, here are two of them for starters.

yet another java 1.5 grammar
Michael Stahl Wed Aug 25, 2004 10:23
a recognizer and tree parser for java 1.5, developed independently from the one by michael studman

http://www.antlr.org/grammar/1093454600181/java15-grammar.zip

Michael Studman Sat Jul 24, 2004 16:51
An update to the Java 1.3/1.4 grammar (incorporating Cortex's generics additions) to support all Java 1.5 language changes.

http://www.antlr.org/grammar/1090713067533/index.html

I think if xdoclet does not keep up with the language
people may turn to attributes instead.

I personally prefer xdoclet because I don't really want
all that stuff added to the generated class files but
I guess it's each to their own.

--b

bryan hunt added a comment - 27/Sep/04 06:23 AM
Actually I notice that you are using javacc rather than antlr,
no problem the javacc project page has an announcement that
they have java 1.5 suppport.

https://javacc.dev.java.net/

They don't appear to have a jjtree grammar though. Is this the
problem ? If it is the case then perhaps we should be lobbying
the javacc guys for java 1.5 grammar so your team can do it's
thing.

--b

Heiko W. Rupp added a comment - 27/Sep/04 07:10 AM
If someone would provide support for enums in addition to the existing patch, then this could be solved relatively soon.

I did have a look at it in the past, but this is not trivial.
Just replacing the existing grammar with a 1.5 one doesn't help, as the
"interfacing between the grammar and xdoclet" would be lost.

Andrew Stevens added a comment - 28/Sep/04 02:02 AM
Anyone who can't wait for xdoclet 1.x to add JDK 1.5/5.0 support might want to take a look at XDoclet 2, as that no longer uses xjavadoc. In fact, the way it's architected the parser is pluggable though the existing modules use QDox (qdox.codehaus.org) to do it. I don't know if QDox supports enums yet, but the latest CVS certainly includes a change for "Implement QDOX-53: Add support for parsing of JSR-14 generic types." The down side is there's fewer existing modules than for XDoclet 1.x.

Gili added a comment - 28/Sep/04 02:11 AM
Andrew,

I remember trying to information about XDoclet 2 a few weeks ago and I could not find anything. The link to XDoclet 2 on the main site was down last time I checked and it wasn't discussed anywhere else.

So, where does one find out more about XDoclet 2? Does it have a Hibernate module among other things (this is the only module I am interested in at the moment)? Where does one download a copy of XDoclet 2?

Thank you,
Gili

Scott Haug added a comment - 30/Sep/04 08:13 PM
Here's the link to the xdoclet 2 site:

http://xdoclet.sf.net/wiki

However, it's parser (qdox) has only very preliminary support for Java 1.5 features. I just checked out the qdox code from CVS, and although it has some support for generics, it's not complete. For example, it doesn't support the '?' placeholder, as in:

public class Bar { private Class<? extends Date> klass; }

The qdox parser will barf on that.

Also, it seems to have *no* support for any other 1.5-specific features, including enums.

Sylvain Vieujot added a comment - 03/Oct/04 08:38 AM
For the one impatients of using jdk5 like me, here is a workaround I use to be able to get generics, and still have xdoclet running :

I add a small ant task that parse all my sources with a regex, removing all the generics, and all the declaration of the foreach loops.

The resulting code isn't functional, but it's good enough to run xdoclet on it.

Note, the regex works fine for me, but it might need to be improved for more complex cases.
Right now, the most complex handled case is simething like :
<String,byte[]>

So, here is the ant task :

<target name="remove-generics" depends="init">
<!-- Since XDoclet isn't already able to parse java 1.5 source code,
we remove all references to generics and for each loops. -->
<property name="generics.match.pattern" value="&lt;[\w\[\]]+(&lt;\w+&gt;)?,?[\w\[\]]*(&lt;\w+&gt;)?&gt;|(for\s?\(.+:.+\))"/>
<echo message="Pattern used to remove generics : ${generics.match.pattern}"/>
<copy toDir="${build.generate.dir}/java" overwrite="true">
<fileset dir="${src.main.dir}">
<include name="**/*.java"/>
</fileset>
</copy>
<replaceregexp byline="true" flags="g">
<fileset dir="${build.generate.dir}/java">
<include name="**/*.java"/>
</fileset>
<regexp pattern="${generics.match.pattern}"/>
<substitution expression=""/>
</replaceregexp>
</target>

Andy DePue added a comment - 29/Oct/04 05:13 PM
1.5 is officially out now and I've run right into this problem. Is there any kind of workaround for this issue? Copying all my source files for every compile is not really an option as our project is way too big for that to be practical. The patch provided doesn't offer enough functionality. I use XDoclet for hibernate - surely someone has come up with a better solution?

Scott Haug added a comment - 29/Oct/04 05:20 PM
I sure wish there was. My solution is to not use xdoclet with java 1.5 and hibernate. We maintain our mappings files manually. It's a pain in the ass, with lots of duplication. But there doesn't seem to be much of an alternative, if you require full java 1.5 parsing.

Andy DePue added a comment - 29/Oct/04 05:39 PM
OK, here's a workaround idea (though I know nothing about XDoclet). There has got to be an InputStream or Reader involved somewhere in the process of XDoclet reading the Java source to parse it... so, if we Just had some Java code that could strip generics enough to make the XDoclet parser happy, and we could somehow incorporate this Java code into a InputStream/Reader filter (wrapper/decorator/whatever term you want to use), then it could possibly be a case of simply wrapping the InputStream/Reader before handing it off to the parser... So, the tricks would be:
1. Java code that can strip generics in the form of an InputStream/Reader filter.
2. Enough knowledge of XDoclet source to know how to interpose this filter before handing the stream off to XDoclet.
This is basically the same general concept as the copy-all-your-source-and-regex-it idea above, except you don't have to copy all your source (it becomes more efficient as we can avoid invoking the OS and the slow disk IO).
Unfortunately, I don't have time to accomplish either of these. :-(


Scott Haug added a comment - 29/Oct/04 05:46 PM
Stripping generics, no matter what the approach, is not a workable solution for our needs. We make full use of most of the new 1.5 features, including enums, annotations, for:loops, etc. Specifically, we have hibernate mappings for Enum classes. No amount of generics stripping will solve that problem. Our project needs full java 1.5 parsing support, or enough support to handle generics and enums and ignore anything else that doesn't involve class declarations.

Gili added a comment - 30/Oct/04 01:26 PM
Scott,

What you said makes no sense to me. Generics, enums and most of the other JDK 1.5 features are purely compiler syntactic suger. Hence, there is absolutely no benefit to having XDoclet "recognizer" them as enums, generics etc. If XDoclet sees "Set" instead of "Set<Integer>" that is absolutely fine and the resulting mappings will be valid.

Adding JDK-1.5 recognition is nice to have because then this:

@hibernate.collection-one-to-many class="someType"

changes into:

@hibernate.collection-one-to-many

and XDoclet is smart enough to auto-detect the "class" by grabbing the generic type.

Again, this is just syntactic suger and is not required. If you guys filter JDK 1.5 code into 1.4 before feeding it into XDoclet it'll make me (and others) very happy. You can use the regexp mentioned above as a starting point.

Scott Haug added a comment - 30/Oct/04 02:46 PM
So perhaps I overstated. I don't need a full JDK 1.5 parser. But *something* needs to be able to parse JDK 1.5 syntax and convert it into something XDoclet can understand. If that *something* is XDoclet itself (or whatever parser it's using today), then all the better. My point was that "stripping generics" is not good enough for me. I need enum parsing/conversion at least. For now, the incremental effort of making sure our manually-created mapping files are consistent with the classes is a far easier story to tell management then creating, testing, and verifying a suite of "jfront"-style regexes to convert 1.5 syntax into 1.4.

Gili added a comment - 30/Oct/04 03:47 PM
Ok, so far generics -> raw types and enums -> integer constants have been discussed. Are there any other entities that need to be converted for XDoclet to work?

If someone could comment on how easy/hard it would be to handle enum -> integer constants I think we can begin work on this.

Scott Haug added a comment - 30/Oct/04 04:23 PM
For me, enums -> integer contants is not sufficient. Our enums are persisted as full blown classes, with properties that map to columns in the DB. We're running a modified version of hibernate (patch submitted) that allows persisting classes that don't provide a default ctor for this very reason. So any solution has to treat JDK 1.5 enums for what they really are: java classes.

Gili added a comment - 30/Oct/04 05:00 PM
Scott,

  Agreed, but my point is that XDoclet processes files one at a time. The only time you have to concern yourself with enums is when you're processing their .java file. In such a case, you simply have to swap "enum" for "class" and convert its values into "final int" values and you're done. In fact, I will go further and say that you could even strip the values altogether since XDoclet doesn't care about the actual class implementation, but rather about its commments.

   So when processing enums, we simply need to replace "enum" by "class" and strip away the values. I'm not sure what the specification says about enums, but from what I've seen, everything between the beginning of the class body up until the first semicolor seems to make up the values. Stripping them should be simple enough. If the specification turns out to be more complicated, we could always enhance our enum support in the future but this should be enough for a start.

Heiko W. Rupp added a comment - 31/Oct/04 07:30 AM
Hi,

simplest would be if someone would patch the attached grammar-patch to support enums

 Heiko

Andy DePue added a comment - 01/Nov/04 01:26 PM
Is there an open source utility anywhere that will convert the new 1.5 syntax to compatible 1.4 syntax? For example generics to their erasure forms, enums to their class form, etc... if so, it could be possible to interpose this utility (maybe via an inline InputStream/Reader filter) between the file and XDoclet. Of course, the best option is to modify the grammar, but I'm not sure how many people are familiar with how XDoclet grammar is setup, and I certainly don't have the time to figure it out. If there is an already existing project that can do such a conversion, then it may be a good temporary fix. In any case, the ultimate solution, as you mention, is to fix the grammar. Really, at this point I don't care how it gets done, so long as it works. :-)

Anton Adamansky added a comment - 13/Nov/04 04:37 AM
Here is the fixed version of XJavadoc which can successfully deals with new java 1.5 language syntax.

I'm currently working on one big project (based on java 1.5) and I've been very disappointed with XDoclet inability
to work with Tiger syntax, so I've permitted oneself to spend a few days in order to make serious
effort in resolving of this scary problem.

1) The old java 1.2 grammar was completely replaced with new java 1.5 (was taken on javacc.dev.java.net)
   
2) then i've carefully merged XJavaDoc java building routines with new syntax in Java1.5-xjd.jjt (it was tiresome work :))
   (in order to build java parser javacc-3.2 was used)

3) tested with all junit test in xjavadoc and with light java 1.5 test +
   tested in real world application with using java 1.5 & xdoclet & hibernate tags.

files:
/xjavadoc-1.1-j5.jar - complete binary build of xjavadoc with java 1.5 support
(in order to use XDoclet with Tiger you should replace old xjavadoc.jar with xjavadoc-1.1-j5.jar)

Affected sources:
/afsrc//test/ - simple test routines
/afsrc/Java1.5-xjd.jjt - javacc & xjavadoc parser template - the replacement of old - Java1.2-b.jjt
/afsrc/Token.java - generated javacc Token.java - should be replaced with this file

limitation:

enums - are completelly ignored by xjavadoc (also in XDoclets enums is not sipported)

Hope it helps you with xdoclet & java 1.5
Adamansky Anton.

Heiko W. Rupp added a comment - 13/Nov/04 11:38 AM
Anton,
this is cool. I don't understand your comment about Token.java.
As this is normally generated on every run .. should the generated one always be replaced by the class supplied by you or is this only meant for initial bootstrapping?

Gili added a comment - 13/Nov/04 01:17 PM
Anton,

First, I'd like to thank you for all your hard work. Secondly, it is not exactly clear to me how to patch XDoclet with your attachment to make it support JDK 1.5. Could you please elaborate?

Thanks,
Gili

Heiko W. Rupp added a comment - 13/Nov/04 01:24 PM
Anton,
to use javac3.2.2 - what ant version do you use? ant 1.5 expects the start method to be in some com.sun.labs class, where javacc3 does have no com.sun packages.
Or how did you incorporate this?

Javacc 2.x as supplied with xdoclet compiles the grammar without warning, so I think 2.x should be ok anyway.
When using this, I get failures in the unit-tests.

Anton Adamansky added a comment - 14/Nov/04 07:42 AM
Hi Fellows !

Heiko W. Rupp wrote:
>I don't understand your comment about Token.java.
>As this is normally generated on every run .. should the generated one >always be replaced by the class
>supplied by you or is this only meant >for initial bootstrapping?

JavaCC generates a set of .java parser files related to actual grammar, but the last 1.5 grammar depends on
the specific (custom) Tokens such as GTToken (used to resolve generics cases).
And, in order to compile generated parser sourses you need to replace Token.java generated with
JavaCC with custom provided Token.java (originally such routines was added by Sreenivasa Viswanadha
in his Java 1.5 grammar, please see https://javacc.dev.java.net/source/browse/javacc/examples/JavaGrammars/1.5/
and https://javacc.dev.java.net/servlets/ReadMsg?list=users&msgNo=247)

Heiko W. Rupp wrote:
> to use javac3.2.2 - what ant version do you use? ant 1.5 expects the > start method to be in some com.sun.labs class, where javacc3 does
> have no com.sun packages. Or how did you incorporate this?

I've used ant 1.6.2 ant and replaced old JavaCC.zip with new javacc3.2.2.jar - benefits: parser generated code compiles under jdk 1.5 (may be another benefits and bug fixes :))

>Javacc 2.x as supplied with xdoclet compiles the grammar without >warning, so I think 2.x should be ok anyway. When using this, I get >failures in the unit-tests.

Considering junit test there is Two issues I've found among of 91 xjavadoc junit test cases:

1) The public void testSuperclass() is not passed for only one particular class: 'XClass', (xjavadoc/etc/xjavadoctest.j#testSuperclass())
The <XDtClass:fullSuperclassName/> returns "java.lang.Object" only for ''XClass' why ?:) (maybe some intristic bug ?)
I've commented this vague case.
2) XJavaDocTest#testOldFashioned() attempts to compare creation time of old fashioned class placements,
(actual creation times differs) but in this case the parser logic is not responsible to support it.
I've commented it too.

So i've sent the complete source distribution is created tom make things clearer.


Gili wrote:
>Secondly, it is not exactly clear to me how to patch XDoclet with >your attachment to make it support JDK 1.5. Could you please >elaborate?

In order to use xdoclet with jdk 1.5 you need (at least at present time :) relace your xjavadoc-1.x.jar in xdoclet/lib with xjavadoc-1.1-j5.jar (you can find it in attached archive xjavadoc-1.1-j5.zip mentioned above) hope it helps you in your projects.

PS.

  Sorry for my file spam,
  but i've placed in attachment (xjavadoc-1.1-j5-src.zip) the complete source distribution is used to build xjavadoc-1.1-j5.jar.



Sincerely yours

Adamansky Anton.

Gili added a comment - 16/Nov/04 02:43 PM
Anton,

I've tried replacing xjavadoc-1.x.jar with xjavadoc-1.1-j5.jar as you recommended but I get this exception when I try using xdoclet on my code:

java.lang.NoSuchMethodError: xjavadoc.XJavaDoc.getSourceClasses(ZZ)Ljava/util/Collection;
    at xdoclet.TemplateSubTask.startProcessPerClass(TemplateSubTask.java:657)
    at xdoclet.TemplateSubTask.startProcess(TemplateSubTask.java:594)
    at xdoclet.XmlSubTask.startProcess(XmlSubTask.java:198)
    at xdoclet.modules.hibernate.HibernateSubTask.execute(HibernateSubTask.java:123)
    at xdoclet.XDocletMain.start(XDocletMain.java:48)
    at xdoclet.DocletTask.start(DocletTask.java:462)
    at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:105)
    at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
    at org.apache.tools.ant.Task.perform(Task.java:364)
    at org.apache.tools.ant.Target.execute(Target.java:341)
    at org.apache.tools.ant.Target.performTasks(Target.java:369)
    at org.apache.tools.ant.Project.executeTarget(Project.java:1214)
    at org.apache.tools.ant.Project.executeTargets(Project.java:1062)
    at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:217)
    at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:236)
    at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:125)


Any ideas?

Gili

Gili added a comment - 16/Nov/04 03:03 PM
Ok, I've fixed the problem by upgrading to XDoclet 1.2.2. I used using XDoclet 1.2.1 before.

Jon Olson added a comment - 17/Nov/04 04:17 AM
The attached xjavadoc binary appears to break EJB XDoclet interface generation with XDoclet 1.2.2. Specifically, generated remote interfaces have all defined methods, but the methods are only marked as throwing RemoteException. This is inconsistent with the EJB spec, and more importantly with the template file used for interface generation. It would appear that XJavadoc is returning an empty exceptions list (regardless of the actual contents), but that the XDtMethod:exceptionList tag is appending java.rmi.RemoteException as expected.

Szczepan Kuzniarz added a comment - 17/Nov/04 05:15 AM
I have problem generating MBean interface for a class which uses some enum types. The new version of xjavadoc crashes with following exception:

java.util.EmptyStackException
    at java.util.Stack.peek(Stack.java:79)
    at xjavadoc.SimpleParser.currentClass(SimpleParser.java:228)
    at xjavadoc.SimpleParser.MethodDeclaration(SimpleParser.java:1108)
    at xjavadoc.SimpleParser.ClassOrInterfaceBodyDeclaration(SimpleParser.java:861)
    at xjavadoc.SimpleParser.ClassOrInterfaceBody(SimpleParser.java:795)
    at xjavadoc.SimpleParser.EnumConstant(SimpleParser.java:704)
    at xjavadoc.SimpleParser.EnumBody(SimpleParser.java:632)
    at xjavadoc.SimpleParser.EnumDeclaration(SimpleParser.java:627)
    at xjavadoc.SimpleParser.TypeDeclaration(SimpleParser.java:485)
    at xjavadoc.SimpleParser.CompilationUnit(SimpleParser.java:330)
    at xjavadoc.SimpleParser.populate(SimpleParser.java:272)
    at xjavadoc.SourceClass.parse(SourceClass.java:758)
    at xjavadoc.SourceClass.<init>(SourceClass.java:124)
    at xjavadoc.XJavaDoc.scanAndPut(XJavaDoc.java:885)
    at xjavadoc.XJavaDoc.getXClass(XJavaDoc.java:406)
    at xjavadoc.SourceClass.qualify(SourceClass.java:375)
    at xjavadoc.AbstractClass.resolveImportedClasses(AbstractClass.java:822)
    at xjavadoc.SimpleParser.ClassOrInterfaceDeclaration(SimpleParser.java:542)
    at xjavadoc.SimpleParser.TypeDeclaration(SimpleParser.java:481)
    at xjavadoc.SimpleParser.CompilationUnit(SimpleParser.java:330)
    at xjavadoc.SimpleParser.populate(SimpleParser.java:272)
    at xjavadoc.SourceClass.parse(SourceClass.java:758)
    at xjavadoc.SourceClass.<init>(SourceClass.java:124)
    at xjavadoc.XJavaDoc.scanAndPut(XJavaDoc.java:885)
    at xjavadoc.XJavaDoc.getXClass(XJavaDoc.java:406)
    at xjavadoc.XJavaDoc.getOuterSourceClasses(XJavaDoc.java:760)
    at xjavadoc.XJavaDoc.getSourceClasses(XJavaDoc.java:323)

Anton Adamansky added a comment - 20/Nov/04 09:23 AM
Hi!

Thanks for the issues above, i've fixed it.
(xjavadoc-1.1-j5-v2.jar attached)

1) Now method's exceptions is properly handled by parser
2) Enums should work (your issue Szczepan)

  In order to not produce file spam i've presumed to place
  all sources (tracked the current status of my work)
  at this address: http://www.softmotions.com/xjavadoc/

Bye.
  Adamansky Anton.



Szczepan Kuzniarz added a comment - 29/Nov/04 04:38 AM
Thanks for the new version. The EmptyStackException problem is fixed, but now I have new exception compiling class with enums:

java.lang.IllegalStateException: Don't call setName for outer classes. Call setQualifiedName instead. (IndexType)
        at xjavadoc.AbstractClass.setName(AbstractClass.java:750)
        at xjavadoc.SimpleParser.EnumDeclaration(SimpleParser.java:624)
        at xjavadoc.SimpleParser.TypeDeclaration(SimpleParser.java:484)
        at xjavadoc.SimpleParser.CompilationUnit(SimpleParser.java:330)
        at xjavadoc.SimpleParser.populate(SimpleParser.java:272)
        at xjavadoc.SourceClass.parse(SourceClass.java:758)
        at xjavadoc.SourceClass.<init>(SourceClass.java:124)
        at xjavadoc.XJavaDoc.scanAndPut(XJavaDoc.java:885)
        at xjavadoc.XJavaDoc.getXClass(XJavaDoc.java:406)
        at xjavadoc.SourceClass.qualify(SourceClass.java:375)
        at xjavadoc.AbstractClass.resolveImportedClasses(AbstractClass.java:822)
        at xjavadoc.SimpleParser.ClassOrInterfaceDeclaration(SimpleParser.java:541)
        at xjavadoc.SimpleParser.TypeDeclaration(SimpleParser.java:480)
        at xjavadoc.SimpleParser.CompilationUnit(SimpleParser.java:330)
        at xjavadoc.SimpleParser.populate(SimpleParser.java:272)
        at xjavadoc.SourceClass.parse(SourceClass.java:758)
        at xjavadoc.SourceClass.<init>(SourceClass.java:124)
        at xjavadoc.XJavaDoc.scanAndPut(XJavaDoc.java:885)
        at xjavadoc.XJavaDoc.getXClass(XJavaDoc.java:406)
        at xjavadoc.XJavaDoc.getOuterSourceClasses(XJavaDoc.java:760)
        at xjavadoc.XJavaDoc.getSourceClasses(XJavaDoc.java:323)
        at xjavadoc.XJavaDoc.getSourceClasses(XJavaDoc.java:310)

'IndexType' reported in the first line of stacktrace is the name of my enum class.


Regards,

Szczepan Kuzniarz

Anton Adamansky added a comment - 05/Dec/04 07:07 AM
Hi!

>The EmptyStackException problem is fixed, but now I have new exception compiling class with enums:

This problem with standalone enums was fixed (xjavadoc-1.1-j5-v3.jar ),
i'm considering the xjavadoc-1.1-j5-v3 as quite stable.

Please see attachments, or:
http://www.softmotions.com/xjavadoc/xjavadoc-1.1-j5-v3.jar
http://www.softmotions.com/xjavadoc/xjavadoc-src-1.1-j5-v3.zip

PS.
I Hope XDoclet team takes my efforts into account in order to
produce release version of xjavadoc that supports java 5.

Thanks.

      Adamansky Anton.

   




Luiz-Otavio Zorzella added a comment - 29/Dec/04 12:32 PM
Thanks for the patch!!! It is saving my life :^>

There's a problem, though: if a parametrized generic is used in a session bean remote method (for example), the generated interface class does not come with the parameter. E.g.:

... MySessionBean ... {
...

   /**
     * @ejb.interface-method
     * view-type = "remote"
     *
     */
   public List<MyClass> getListOfMyClass () { ... }
...
}

will generated:

... MySession ... {
...
   public List getListOfMyClass () { ... }
...
}

So a caller that does:

List<MyClass> listOfMyClass = mySession.getListOfMyClass ();

will have the compiler (and Eclipse) warn about type safety. While that is just a warning, it is still quite anoying.

Thanks again,

Zorzella

trajano added a comment - 15/Feb/05 09:26 AM
Would it be difficult to just use Java 5.0 annotations with XDoclet as well?

Stefan Langer added a comment - 26/Feb/05 04:41 PM
Need this issue fixed since my code depends heavily on enums.

stefan

Mark Derricutt added a comment - 09/Apr/05 03:32 AM
Unfortunately this doesn't replace/update any of the XDoclet templates, so whilst it parses ok, if say, a remote method returns List<Foo>, the generated EJB classes just return List. Still, its better than not getting anything at all...

Has anyone looked at patching the templates at all?

Denis Robert added a comment - 11/Apr/05 08:39 AM
As far as I can tell, XDoclet is a dead project. There doesn't seem to have been any activity since October 2004.

I this is wrong, could some of the developers for the project correct me? I am getting ready to abandon XDoclet as a dead weight in my own development; and I'm pretty sure I'm not the only one, since there is no sign of life on the XDoclet (and esp. on the XDoclet2) site.

Matthias Germann added a comment - 11/Apr/05 11:04 AM
XDoclet is not dead!

If you had a look at the mailing list archive or JIRA, you had seen that XDoclet 1.2.3 will be released soon.

Charles Blaxland added a comment - 22/Apr/05 11:16 PM
Yes, XDoclet is still alive, but unfortunately this issue just doesn't seem to be considered a high priority. I think this is strange considering how long the bug has been open (> 1 year), how long JDK 1.5 has been out (> 7 months) and how many votes this defect has (must be by far the most in the xdoclet project?). It even seems that most (?) of the work has already been done and contributed as patches.

This defect is apparently scheduled for the 1.3 release, but who knows how long before that gets released. Would anyone on the XDoclet team care to comment on when we might see this defect fixed?

Mark Derricutt added a comment - 09/May/05 05:55 AM
I see XDoclet 1.2.3 has hit the sourceforge download servers, I just gave it a run for its money and discover that generics still make XDoclet cry like baby jesus.

I note theres been no official announcement of this release, so its not really "released" persae, but was wondering what was up?

Paul Galbraith added a comment - 17/May/05 12:16 PM
I hope nobody minds me upping the priority on this :-)

Cat added a comment - 06/Jun/05 10:51 AM
So, anybody can me say when this feature will be applied? Is there anybody?

Andy DePue added a comment - 06/Jun/05 11:20 AM
Just FYI, we've decided to move away from XDoclet due to this outstanding issue. We have moved to Hibernate 3 and are manually maintaining *.hbm.xml files until Hibernate 3 annotations become mature enough for our usage. This frees us up to use Java 1.5 syntax in our Hibernate classes.

Caoilte O'Connor added a comment - 06/Jun/05 11:26 AM
What's wrong with the patched XJavaDoc linked to at the top of this bug? I dropped it into our project and it worked fine.

Andreas Schildbach added a comment - 06/Jun/05 11:39 AM
I have been moving away from XDoclet, too.

Hibernate Annotations are such a breeze to use, even in the current (beta 2) release.

There is not really a need for XDoclet any more, if you use JDK 1.5 and have annotations at hand.

I guess this is the reason why it has become very silent about fixing and enhancing XDoclet.

Mark Mindenhall added a comment - 06/Jun/05 11:40 AM
The following enum still breaks with the latest patch. It does not expect to encounter the semicolon following the opening bracket on the first line.



public static enum Flag {;

public static String getDBValue(boolean indicator) {
String key = null;
if (indicator) {
key = CHAR_TRUE;
} else {
key = CHAR_FALSE;
}

return key;
}

public static boolean getFlagType(String indicator) {
boolean result = false;

if (indicator != null)
if (indicator.equals(CHAR_TRUE)) {
result = true;
}
return result;
}

public static boolean getFlagType(String indicator, boolean defaultValue) {
boolean result = false;

if (indicator != null)
if (indicator.equals(CHAR_TRUE)) {
result = true;
} else if (indicator.equals(CHAR_FALSE)) {
result = false;
} else {
result = defaultValue;
}
return result;
}

public static final String CHAR_FALSE = "F";
public static final String CHAR_TRUE = "T";
};

Anton Adamansky added a comment - 07/Jun/05 02:21 AM
Hello !

Hope, the issues founded since last patch will be fixed within this week.

PS.
IMHO XDoclet is going its way into the death, and waiting for stable
releases of Hibernate anntations and relative annotations based tools.

Cat added a comment - 07/Jun/05 03:38 AM
Hi all,
Andy & Andreas, should note that XDoclet is JUST MORE than just EJB 3.0 annotation... ;) I belive in XDoclet and wishes best regards to XDoclet team.
Anton Adamansky, good luck. ;)

Heiko W. Rupp added a comment - 10/Jun/05 05:10 AM
Anton,
do I read your last message correctly, that you will fix the
'semicolon problem'?

  Heiko

Anton Adamansky added a comment - 10/Jun/05 07:08 AM
Heiko wrote:
>do I read your last message correctly, that you will fix the
> 'semicolon problem'?

Yes, today the new version of patched xjavadoc will be released.

Anton.




 

Heiko W. Rupp added a comment - 10/Jun/05 07:18 AM
CVS COMMIT LOG:
SUBJECT: [Xdoclet-devel] CVS: xjavadoc/javacc Java1.5.jj,NONE,1.1 Token.java,NONE,1.1 Java1.5x.jjt,NONE,1.1
Support Java5. From Anton Adamansky in XJD-41.


Heiko W. Rupp added a comment - 10/Jun/05 07:18 AM
CVS COMMIT LOG:
SUBJECT: [Xdoclet-devel] CVS: xjavadoc/etc xjavadoctest.j,1.14,1.15
Support Java5. From Anton Adamansky in XJD-41.


Heiko W. Rupp added a comment - 10/Jun/05 07:18 AM
CVS COMMIT LOG:
SUBJECT: [Xdoclet-devel] CVS: xjavadoc/junit/xjavadoc XJavaDocTestJ15.java,NONE,1.1 XJavaDocTest.java,1.6,1.7
Support Java5. From Anton Adamansky in XJD-41.


Heiko W. Rupp added a comment - 10/Jun/05 07:18 AM
CVS COMMIT LOG:
SUBJECT: [Xdoclet-devel] CVS: xjavadoc/lib log4j.properties,NONE,1.1 commons-logging.properties,NONE,1.1 javacc.jar,NONE,1.1
Support Java5. From Anton Adamansky in XJD-41.


Heiko W. Rupp added a comment - 10/Jun/05 07:19 AM
CVS COMMIT LOG:
SUBJECT: [Xdoclet-devel] CVS: xjavadoc/test Hello2.java,NONE,1.1 Goodbye2.java,NONE,1.1 Hello.java,1.25,1.26
Support Java5. From Anton Adamansky in XJD-41.


Anton Adamansky added a comment - 10/Jun/05 07:30 AM
Patched XJavadoc update: (attached: xjavadoc-1.1-j5-v4.jar)

Fixed issues:

1) Parser does't expect the 'final' keyword in such case:

   for (final Object item : items) {
   }

2) Parser was failed on the semicolon following the opening bracket on the first line of enum:

   public static enum Flag {;
    ....
   }

PS.
Binary JAR: http://callisto.nsu.ru/xjavadoc/xjavadoc-1.1-j5-v4.jar
Sources: http://callisto.nsu.ru/xjavadoc/xjavadoc-src-1.1-j5-v4.zip

Heiko W. Rupp added a comment - 10/Jun/05 07:32 AM
Anton,
could you please provide a diff to your last version or relative to the current state of cvs? This would help me a lot.

Thanks
  Heiko

Anton Adamansky added a comment - 10/Jun/05 07:36 AM
Source version is attached too. (xjavadoc-src-1.1-j5-v4.zip)

Anton Adamansky added a comment - 10/Jun/05 07:38 AM
Ok, tomorrow diffs will be provided

Heiko W. Rupp added a comment - 10/Jun/05 09:43 AM
CVS COMMIT LOG:
SUBJECT: [Xdoclet-devel] CVS: xjavadoc/test/annotation TestAnnotation.java,NONE,1.1
Support Java5. From Anton Adamansky in XJD-41.


Heiko W. Rupp added a comment - 10/Jun/05 09:43 AM
CVS COMMIT LOG:
SUBJECT: [Xdoclet-devel] CVS: xjavadoc project.xml,1.20,1.21
Add Anton Adamansky, provider of the XJD-41 patch.


Heiko W. Rupp added a comment - 10/Jun/05 06:19 PM
CVS COMMIT LOG:
SUBJECT: [Xdoclet-devel] CVS: xjavadoc build.xml,1.56,1.57
Support Java5. From Anton Adamansky in XJD-41.


Heiko W. Rupp added a comment - 11/Jun/05 08:20 AM
This seems to be fixed with the new 1.5 grammar from XJD-41.

Heiko W. Rupp added a comment - 11/Jun/05 08:21 AM
This seems to be fixed with the new 1.5 grammar from XJD-41.

Heiko W. Rupp added a comment - 11/Jun/05 08:30 AM
Patches applied, the tests run well, so go and play .. :-)

Mark Derricutt added a comment - 11/Jun/05 05:15 PM
Surely without any of the templates being updated so that generated code actually supports 1.5 generic syntax this can't really be resolved, can it?

This is still not just more than "doesn't die on 1.5", not "supports". Maybe I'm wanting to much thou?

When an EJB remote method returns List<UserValue>, it'd be nice to see List<UserValue> in the actual interface, rather than just List. I suppose that might also be a good thing from a backward-to-1.4 compatibility feature thou.

Heiko W. Rupp added a comment - 12/Jun/05 03:48 AM
1.5-Snapshot050611 incorporates this.

Heiko W. Rupp added a comment - 12/Jun/05 07:32 AM
New grammar, new luck ...

Heiko W. Rupp added a comment - 12/Jun/05 07:46 AM
Mark,

XJD-41 is about the parser, not about templates. Those are Xdoclet-related.
So yes, the "fixed" means "does no longer die on Java 5".

  Heiko

Catalin Hritcu added a comment - 12/Jun/05 08:23 AM
This is great, one problem though: Where can I get 1.5-Snapshot050611?


Gregor B. Rosenauer added a comment - 18/Jul/05 05:18 AM
Thanks to all involved. I stumbled across the same problem and found the new xjavadoc very useful, works perfectly here.
It would be useful if the xjavadoc-site contained some download-links, too...

However I still wonder why the parser parses non-comments, when all annotations are inside comments?
This would have eliminated the problem, but I suppose it is not possible to limit the parser to comments only.

Regarding xdoclet2 - looks very promising and powerful, but xdoclet 1 does the job fine for me, and I need the mx4j-description-task...

mario eugster added a comment - 08/Sep/05 06:37 AM
I still have problems using enums in xdoclet.

Using enum inside a method body or in a non-xdoclet method works fine. But if I have a method with an enum parameter, it cause an exception:

[ejbdoclet] Generating Remote interface for 'com.xx.yy.zz.aa.xManagerBean'.
[ejbdoclet] xdoclet.template.TemplateException: Invoking method in class xdoclet.tagshandler.ParameterTagsHandler failed: parameterList, line=3 of template file: jar:file:/D:/projects/mbsp/mbsp_jboss/lib/xdoclet-ejb-module-1.2.3.jar!/xdoclet/modules/ejb/intf/resources/remote.xdt, exception: null

method signature:
public void enumTest(int x, MyEnum me)

mario

Anton Adamansky added a comment - 13/Sep/05 04:13 AM
Mario, I've just added test case concerning your issue (please see CVS log/diff) - It passed successfully
Do you use the latest CVS XJavadoc snapshot ?

Anton Adamansky added a comment - 13/Sep/05 05:34 AM
CVS COMMIT LOG:
SUBJECT: [Xdoclet-devel] CVS: xjavadoc/test Hello2.java,1.3,1.4
Test cases related to XJD-41 are updated


Anton Adamansky added a comment - 13/Sep/05 05:34 AM
CVS COMMIT LOG:
SUBJECT: [Xdoclet-devel] CVS: xjavadoc/junit/xjavadoc XJavaDocTestJ15.java,1.3,1.4
Test cases related to XJD-41 are updated


luiz decaro added a comment - 10/Jan/06 07:39 AM
Hi, i'm writing this post just to thank you mate!!

  Thanks a lot!!

:LuizDecaro.

Konstantin Sobolev added a comment - 13/Jun/06 10:29 AM
Unfortunately it still fails on annotated method parameters. E.g.

/**
 * @ejb.interface-method
 */
public void foo (@SomeAnnotation int bar) {}

causes something like
Parse error at line 102, column 41. Encountered: @
(using xdoclet-1.2.3 with xjavadoc-1.1-j5-v4.jar)

Konstantin Sobolev added a comment - 13/Jun/06 12:04 PM
Proposed hotfix:

--- Java1.5x.jjt.orig 2006-06-13 20:45:45.747180520 +0400
+++ Java1.5x.jjt 2006-06-13 20:59:58.271952608 +0400
@@ -1720,7 +1720,7 @@
    }
 }
 {
- [ "final" ]
+ ( "final" | Annotation() )*
   ParameterType()
   [
     "..."

Matt Jensen added a comment - 20/Aug/07 10:17 AM
Addition to Konstantin Sobolev's patch which also allows for annotated local variable declarations (useful for, among other things, @SuppressWarnings("unchecked") in transitional code.)

1723c1723
< [ "final" ]
---
> ( Annotation() | "final" )*
2397c2397
< [ "final" ] Type() VariableDeclarator() ( "," VariableDeclarator() )*
---
> ( Annotation() | "final" )* Type() VariableDeclarator() ( "," VariableDeclarator() )*

Matt Jensen added a comment - 20/Aug/07 11:14 AM
My previous patch appears to have been incomplete:

1723c1723
< [ "final" ]
---
> ( Annotation() | "final" )*
2386c2386
< LOOKAHEAD([ "final" ] Type() <IDENTIFIER>)
---
> LOOKAHEAD(( Annotation() | "final" )* Type() <IDENTIFIER>)
2397c2397
< [ "final" ] Type() VariableDeclarator() ( "," VariableDeclarator() )*
---
> ( Annotation() | "final" )* Type() VariableDeclarator() ( "," VariableDeclarator() )*
2485c2485
< LOOKAHEAD( [ "final" ] Type() <IDENTIFIER> )
---
> LOOKAHEAD( ( Annotation() | "final" )* Type() <IDENTIFIER> )

Nick Brachet added a comment - 26/Jan/09 12:35 PM
Here's a patch to support nested annotations:

--- javacc/Java1.5x.orig 2005-06-10 20:08:50.000000000 -0400
+++ javacc/Java1.5x.jjt 2009-01-26 13:21:01.000000000 -0500
@@ -2636,11 +2636,23 @@
 {
   "@" "interface" name=<IDENTIFIER>
   {
+ if (sourceClass.isInner()) {
+
+ if (log.isDebugEnabled()) log.debug("Inner sourceClass.setName=" + name.image);
+ sourceClass.setName(name.image);
+ sourceClass.setInterface(true);
+ _xJavaDoc.addPackageMaybe( _packageName ).addClass(sourceClass);
+ _xJavaDoc.addSourceClass( sourceClass );
+
+ } else {
+
+ if (log.isDebugEnabled()) log.debug("sourceClass.setQName=" + Util.getQualifiedNameFor(_packageName, name.image));
     sourceClass.setQualifiedName(Util.getQualifiedNameFor(_packageName, name.image));
     sourceClass.setInterface(true);
     _xJavaDoc.addPackageMaybe( _packageName ).addClass(sourceClass);
     _xJavaDoc.addSourceClass(sourceClass);
   }
+ }
 
   AnnotationTypeBody()
 

Nick Brachet added a comment - 26/Jan/09 12:51 PM
And another patch to support empty default arrays for annotation attributes:

--- javacc/Java1.5x.orig 2005-06-10 20:08:50.000000000 -0400
+++ javacc/Java1.5x.jjt 2009-01-26 13:43:33.000000000 -0500
@@ -2621,7 +2621,7 @@
 void MemberValueArrayInitializer():
 {}
 {
- "{" MemberValue() ( LOOKAHEAD(2) "," MemberValue() )* [ "," ] "}"
+ "{" [ MemberValue() ( LOOKAHEAD(2) "," MemberValue() )* ] [ "," ] "}"
 }