Details
Bug
Closed
Major
Description
JavaClassBuilder fails to successfully parse the UnicodeBlock java.lang.Character inner class.
In this class, fields are not defined as usual but like this :
public static final UnicodeBlock
BASIC_LATIN
= new UnicodeBlock("BASIC_LATIN"),
LATIN_1_SUPPLEMENT
= new UnicodeBlock("LATIN_1_SUPPLEMENT"),
/* cut */
HALFWIDTH_AND_FULLWIDTH_FORMS
= new UnicodeBlock("HALFWIDTH_AND_FULLWIDTH_FORMS"),
SPECIALS
= new UnicodeBlock("SPECIALS");
From this code block, QDOX only finds the BASIC_LATIN field, and only 4 fields from the entire class (BASIC_LATIN, SYRIAC, blockStarts and blocks).
Activity
This is a matter of whether we want to support ugly C-style declarations like:
int i,j,k;
It's in the Java spec, so I don't think we should "won't fix" this.
Aslak Hellesøy
added a comment - This is a matter of whether we want to support ugly C-style declarations like:
int i,j,k;
It's in the Java spec, so I don't think we should "won't fix" this. After a bit more thought, I think there actually is a way to handle this without a performance hit.
If we keep track of paren/brace nesting within the ASSIGNMENT, we can get the lexer to recognise and return the COMMA, while still discarding the uninteresting tokens.
Mike Williams
added a comment - After a bit more thought, I think there actually is a way to handle this without a performance hit.
If we keep track of paren/brace nesting within the ASSIGNMENT, we can get the lexer to recognise and return the COMMA, while still discarding the uninteresting tokens. Mike Williams
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Assignee | Mike Williams [ mdub ] |
Mike Williams
made changes -
| Fix Version/s | 1.4 [ 10304 ] | |
| Description |
JavaClassBuilder fails to successfully parse the UnicodeBlock java.lang.Character inner class. In this class, fields are not defined as usual but like this : public static final UnicodeBlock BASIC_LATIN = new UnicodeBlock("BASIC_LATIN"), LATIN_1_SUPPLEMENT = new UnicodeBlock("LATIN_1_SUPPLEMENT"), /* cut */ HALFWIDTH_AND_FULLWIDTH_FORMS = new UnicodeBlock("HALFWIDTH_AND_FULLWIDTH_FORMS"), SPECIALS = new UnicodeBlock("SPECIALS"); From this code block, QDOX only finds the BASIC_LATIN field, and only 4 fields from the entire class (BASIC_LATIN, SYRIAC, blockStarts and blocks). |
JavaClassBuilder fails to successfully parse the UnicodeBlock java.lang.Character inner class. In this class, fields are not defined as usual but like this : public static final UnicodeBlock BASIC_LATIN = new UnicodeBlock("BASIC_LATIN"), LATIN_1_SUPPLEMENT = new UnicodeBlock("LATIN_1_SUPPLEMENT"), /* cut */ HALFWIDTH_AND_FULLWIDTH_FORMS = new UnicodeBlock("HALFWIDTH_AND_FULLWIDTH_FORMS"), SPECIALS = new UnicodeBlock("SPECIALS"); From this code block, QDOX only finds the BASIC_LATIN field, and only 4 fields from the entire class (BASIC_LATIN, SYRIAC, blockStarts and blocks). |
Agree. That's the way to do it 
Aslak Hellesøy
added a comment - Agree. That's the way to do it If implemanting this cause too much slowdowns, it may be possible to have to different lexers. One "fast" and a "slow", that could be choosen at runtime or at compiletime...
Eric Dechaux
added a comment - If implemanting this cause too much slowdowns, it may be possible to have to different lexers. One "fast" and a "slow", that could be choosen at runtime or at compiletime... I was wrong: we managed to fix this without a performance hit.
Mike Williams
added a comment - I was wrong: we managed to fix this without a performance hit. Mike Williams
made changes -
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
Awesome work Mike!
Aslak Hellesøy
added a comment - Awesome work Mike! I agree, great work
it works great
Eric Dechaux
added a comment - I agree, great work
it works great Mike Williams
made changes -
| Status | Resolved [ 5 ] | Closed [ 6 ] |
Tricky.
This happens because the lexer discards everything between the first "=" and the ";".
Discarding "un-interesting" tokens during lexical analysis is what makes QDox so speedy. In other words, it will be difficult to fix this bug without a big performance hit.