|
[
Permalink
| « Hide
]
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.
Walter,
could you incorporate enum support? I guess those will appear soon in 1.5 sources .. Heiko yep, I want to move to hibernate 3 and java 1.5. Xdoclet code
generation is the only thing holding me back. will somebody apply this patch sometime in my lifetime ? :(
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 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 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. Thank you for the clarification Heiko
--b 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. Don't get me wrong. I did not say "wait until january".
Can't you use '-source 1.4' option to javac? 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. 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 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 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. 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.
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 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. 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="<[\w\[\]]+(<\w+>)?,?[\w\[\]]*(<\w+>)?>|(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> 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?
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.
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. :-( 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.
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. 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.
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. 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.
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. Hi,
simplest would be if someone would patch the attached grammar-patch to support enums Heiko 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. :-)
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. 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? 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. 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. 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 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.
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) 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. 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 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. 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 Need this issue fixed since my code depends heavily on enums.
stefan 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? 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. 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. 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? 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? I hope nobody minds me upping the priority on this :-)
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.
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.
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. 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"; }; 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. Anton,
do I read your last message correctly, that you will fix the 'semicolon problem'? Heiko 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. 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 CVS COMMIT LOG:
SUBJECT: [Xdoclet-devel] CVS: xjavadoc/etc xjavadoctest.j,1.14,1.15 Support Java5. From Anton Adamansky in 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 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 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 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 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 Source version is attached too. (xjavadoc-src-1.1-j5-v4.zip)
Ok, tomorrow diffs will be provided
CVS COMMIT LOG:
SUBJECT: [Xdoclet-devel] CVS: xjavadoc/test/annotation TestAnnotation.java,NONE,1.1 Support Java5. From Anton Adamansky in CVS COMMIT LOG:
SUBJECT: [Xdoclet-devel] CVS: xjavadoc project.xml,1.20,1.21 Add Anton Adamansky, provider of the CVS COMMIT LOG:
SUBJECT: [Xdoclet-devel] CVS: xjavadoc build.xml,1.56,1.57 Support Java5. From Anton Adamansky in This seems to be fixed with the new 1.5 grammar from
This seems to be fixed with the new 1.5 grammar from
Patches applied, the tests run well, so go and play .. :-)
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. 1.5-Snapshot050611 incorporates this.
Mark,
So yes, the "fixed" means "does no longer die on Java 5". Heiko This is great, one problem though: Where can I get 1.5-Snapshot050611?
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... 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 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 ? CVS COMMIT LOG:
SUBJECT: [Xdoclet-devel] CVS: xjavadoc/test Hello2.java,1.3,1.4 Test cases related to CVS COMMIT LOG:
SUBJECT: [Xdoclet-devel] CVS: xjavadoc/junit/xjavadoc XJavaDocTestJ15.java,1.3,1.4 Test cases related to Hi, i'm writing this post just to thank you mate!!
Thanks a lot!! :LuizDecaro. 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) 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() [ "..." 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() )* 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> ) 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() 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() )* ] [ "," ] "}" } |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Resolved
Critical
Support Java 1.5 Syntax ?
