JDK-4150737 : java.io.StreamTokenizer does not work well for interactive input
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 1.1.5,1.1.6,1.2.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris_2.6
  • CPU: generic,sparc
  • Submitted: 1998-06-19
  • Updated: 1999-02-04
  • Resolved: 1999-02-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.2.2 1.2.2Fixed
Related Reports
Duplicate :  
Description

Name: paC48320			Date: 06/19/98


The StreamReader under JDK 1.1.5 no longer works
properly when eolIsSignificant(true) has been 
called.  Previous versions would return TT_EOL for
each newline encountered.  In JDK 1.1.5 TT_EOL is
only returned for every second newline, or when
the next line is parsed.  The first newline is
being absorbed either by the Reader (In my case
a BufferedReader and InputStreamReader) or by
the tokenizer itself.  When parsing a file
this causes no problem, but when parsing 
interactive input, this means that the user must
issue two EOL's for each line of input. 

The following code will not respond to the first
line of input, and will only respond to each
subsequent line of input with  the input from the
previous line:

import java.io.*;

class Test {
  public static void main(String[] args) {
      boolean running = true;

      /* Create the tokenizer */      
      Reader r = new BufferedReader(new InputStreamReader(System.in));
      StreamTokenizer tokenizer = new StreamTokenizer(r);

      /* Enable eol checking */
      tokenizer.eolIsSignificant(true);

      while(running) {
         try {
            System.out.print("> ");
            System.out.flush();
           
            /* Read a line of input from the user */
            args = ReadLine(tokenizer);

            /* Process the users input */
            System.out.println("Parsed input: " + args[0]);
         } catch (IOException e) {
         } /* Check for IO errors (try/catch IOException) */
      } /* Loop as long as we are still running (while running) */
   } /* main() */

  private static String[] ReadLine(StreamTokenizer tokenizer)
     throws IOException 
  {
      int       index = 0;
      String[]  retVal = new String[10];

      read:
      for (;;) {
         switch(tokenizer.nextToken()) {
            case StreamTokenizer.TT_EOF:
                System.exit(0);
            case StreamTokenizer.TT_EOL:
                break read;
           case StreamTokenizer.TT_WORD:
               /* Add the token to the array */
               retVal[index++] = tokenizer.sval;
               break;
            case StreamTokenizer.TT_NUMBER:
               /* Add the token to the array */
               retVal[index++] = Double.toString(tokenizer.nval);
               break;
         } /* See what kind of token we have (switch tokneizer.nextToken()) */
      } /* Read until we get an EOL or EOF (for ;;) */     

      return(retVal);
   } /* ReadLine() */
} /* class Test */
(Review ID: 28851)
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.2.2 generic FIXED IN: 1.2.2 INTEGRATED IN: 1.2.2
14-06-2004

WORK AROUND Name: paC48320 Date: 06/19/98 Hit return twice :-) ======================================================================
11-06-2004

EVALUATION Verified on 1.1.6 and 1.2beta4. Did this ever work correctly? We should check the case of using the old StreamTokenizer constructor that takes a byte stream. -- mr@eng 6/19/1998 In fact this stopped working correctly in JDK 1.1.1 on solaris, and it's never worked correctly on win32. The end-of-line logic in the nextToken method was being too eager about reading ahead. It now reads ahead only as much as is absolutely necessary. -- mr@eng 1999/2/3
02-07-0169