Hello list this is to inform you that I found a problem with the field definition parser in JaxMeJs. From what I can see this problem resides within the interpretation of the AST representation of the java file from the AntLr parser - or within the AntLr itself. I am very sorry that I can't provide a fix or further details, as my time atm is extremly limited. (please also note that this email address will cease to exist by the end of this month)
The problem is again with arrays. I already changed the code in JavaParser.parseIdentifier(AST pAST, StringBuffer sb) to detect multiple dimensions (see http://marc.theaimsgroup.com/?l=jaxme-dev&m=112083392721610&w=2 and http://marc.theaimsgroup.com/?l=jaxme-dev&m=112083149600157&w=2 ). Apparently the AST structure provided by AntLr is too complex for me to comprehend just by examples during debugging. Suppose I have a class file, which I wish to analyse: public class failingFields { private java.lang.String[] s1; private java.lang.String s2[]; ... according to http://java.sun.com/docs/books/jls/third_edition/html/arrays.html#10.2 both array declarations are valid. However, it doesn't work :) s1 seems to be not recogniced by AntLr. At least I can't see the ttype=17 (ARRAY_DECLARATOR) in the AST given to parseIdentifier. I can only assume this is an error in AntLr or the language definition used by AntLr. For some obscure reasons, s2 returns "[]" as type (instead of "java.lang.String[]" which I would expect for both) - or, including my above mentioned patch, "[]java.lang.String". Since it doesn't matter for multidimensional arrays, I changed the order of my patch, the relevant portion now reading: private void parseIdentifier(AST pAST, StringBuffer sb) { ... case JavaTokenTypes.ARRAY_DECLARATOR: for (AST child = pAST.getFirstChild(); child != null; child = child.getNextSibling()) { parseIdentifier(child, sb); } sb.append("[]"); break; (before the change the loop was after the sb.append) Now "java.lang.String[]" is returned, as expected, and multidimensional arrays are detected as well. However, since s1 is still not recognized and I can't find how I could change this, I am not happy with this method. I am also not sure how the parser might react when fed with even stranger looking, but still correct, lines. Please bear in mind that I do not really understand the way the AST is build - it seems to have some inherent logic (first 'down', then the AST.text itself, then 'right'), but when looking at the debug output of 'java.lang.string', this would result in 'lavalang.String.' (the dot being at the wrong place) I am sorry that I can't provide any more details, but I wanted to at least inform you about this. :Frederic: --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
