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
-
-
- Resolved
-
-
JDK-8253904 Revert Tokenizer improvements JDK-8224225
-
- Closed
-
-
-
- Resolved
-
-
-
- New
-
(1 relates to, 2 links to)