Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4238437

(process) Stream returned from Process.getOutputStream converts LF to LF CR

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Unresolved
    • Icon: P4 P4
    • None
    • 1.1.7
    • core-libs
    • Fix Understood
    • x86
    • windows_nt



      Name: dbT83986 Date: 05/14/99


      Hello,

      This problem was previously reported under bugid "4104702".
      Its status is "closed, will not be fixed".

      I would like you to reconsider this as a "bug".

      Quick refresh: On win32, the stream returned from a
      "getOutputStream" call on a Process object created from
      a "Runtime.exec()" call ALWAYS interprets "LF" and converts them
      to "LF CR" - the new line convention on DOS based machines.
      Thus, it is impossible through Sun jdk to send binary data into
      an exec'ed process through stdin.

      On bugid "4104702", the tech person responded:

      "I don't believe it is really a bug. The default stdio streams on win32 are ascii streams. If people need a binary stream, they should open another stream instead of change the stdio stream into binary mode. We definitely can not provide API for doing such platform specific operations. The process is an external concept to Java. Its behavior is always platform dependent. We can never make it totally platform independent."

      I have several objections to this answer:

      1. Win32 provides a "C" "_setbuf" call, which allows a program
      to set ANY stream to binary mode. Hence, it is entirely possible
      to stream binary data into a win32 application through stdin.

      2. The interpretation/conversion of LF to LF CR by the jdk is a bad implementation. If I stream in ASCII text created through a WIN app (such as "notepad") that already inserts LF CR to end each line of text, the underlying jdk vm STILL interprets the LF and adds another CR. Thus, the output for each line of text actually ends as "LF CR CR". In a started process that expects to read a precise amount of text from stdin, this will NOT work correctly.

      3. The behaviour is inconsistent with many of the derived
      "OutputStream" classes. For instance, "DataOutputStream" is
      doc'ed as follows:

      "A data output stream lets an application write primitive Java data types to an output stream in a portable way. An application can then use a data input stream to read the data back in."

      A method on this class allows for writing a byte array out.
      A "portable" way to write out a byte array is to write it
      out "AS IS", with no data interpretation/translation.

      If I create a "DataOutputStream" from the OutputStream returned
      from the "getOutputStream", this DOES NOT WORK as described in
      the DataOutputStream doc, because LF's are converted to "LF CR".

      4. One person noted in a comment on bugid "4104702" that the Microsoft jvm handles this correctly. I want to add that Symantec's jvm ALSO handles this correctly.

      Bottom line is, the underlying jvm should NOT make the determination of how to interpret the output to a stream. It
      should just move data AS IS. Interpretations and conversions should be controlled by the upper layer java classes:

      If I want to write ASCII text to a stdin stream, I should create
      a "PrintWriter" stream from the returned OutputStream from "getOutputStream".

      If I want to write binary data to a stdin stream, I should be able to do this through the "DataOutputStream".

      Can this "bug" be corrected?
      (Review ID: 63203)
      ======================================================================

            Unassigned Unassigned
            dblairsunw Dave Blair (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Imported:
              Indexed: