Description
The UnicodeReader/JavaTokenizer code is made more obscure than needed by some suboptimal implementation & naming choices:
* UnicodeReader has both API to 'scan' a char (e.g. read next char) as well as to 'putChar' e.g. save char in a temp buffer. The buffer functionality should arguably be higher-level and moved in the JavaTokenizer itself?
* 'putChar' has subtle overloads, some of which also advance the reader state
* the reader 'scanChar' API could be made more intuitive by renaming it to something like 'nextChar' suggesting the underlying state change
* UnicodeReader has both API to 'scan' a char (e.g. read next char) as well as to 'putChar' e.g. save char in a temp buffer. The buffer functionality should arguably be higher-level and moved in the JavaTokenizer itself?
* 'putChar' has subtle overloads, some of which also advance the reader state
* the reader 'scanChar' API could be made more intuitive by renaming it to something like 'nextChar' suggesting the underlying state change
Attachments
Issue Links
- csr for
-
JDK-8233602 Tokenizer improvements
- Closed
- is cloned by
-
JDK-8254073 Tokenizer improvements (revised)
- Resolved
- relates to
-
JDK-8303912 Clean up JavadocTokenizer
- Resolved
-
JDK-8253904 Revert Tokenizer improvements JDK-8224225
- Closed
-
JDK-8305100 [REDO] Clean up JavadocTokenizer
- Resolved
-
JDK-8252719 update DocCommentParser
- New
(1 relates to, 2 links to)