1

Is it possible to reopen standard Console I/O streams during execution after closing them?

public static void main(String[] args) throws IOException {
        System.out.println("Hello World!!!");
        System.out.println("1:" + System.in.read());
        System.out.println("" + FileDescriptor.in.valid());       //true
        System.in.close();
        System.out.println("" + FileDescriptor.in.valid());       //false
        System.out.println("2:" + System.in.read());              //IOException
        System.in.close();
}

From this post I could figure out that private static native void setIn0(InputStream in); native function is used to initialize final I/O streams in private static void initializeSystemClass() private method after thread initialization.

Can I renitialize the I/O streams?

Edit:

As System.in is a final object I cannot modify it with things like

 System.in=new InputStream() {

                @Override
                public int read() throws IOException {
                    throw new UnsupportedOperationException("Not supported yet."); //To change body of generated methods, choose Tools | Templates.
                }
            }

during runtime...
What I am expecting is a solution through Native Methods/Function to retrieve the Console' handle

Community
  • 1
  • 1
boxed__l
  • 1,334
  • 1
  • 10
  • 24

1 Answers1

1

There is no way to reopen an arbitrary stream after you close it.

That being said, you can use System.setIn to use any InputStream as stdin. ByteArrayInputStream.close doesn't do anything, and you could create your own InputStream that cannot be closed.

Jeffrey
  • 44,417
  • 8
  • 90
  • 141
  • How does it initialize in the first place if its an arbitrary stream? Shouldn't there be a Descriptor/Handle for the stream? @jeffrey – boxed__l Jul 21 '13 at 20:33
  • @boxed__l The JVM creates the initial streams and sets them at start up. – Jeffrey Jul 21 '13 at 20:40
  • @boxed__l: Sure there is still a descriptor and a filehandle around. The only problem is that your initial `close` also closes the resource on the operating system level. This invalidates the filehandle. – A.H. Jul 21 '13 at 21:19
  • @A.H. So the JVM initializes i/o for each program separately and if any program closes its i/o then the handles(that specific programs') become invalid? is it correct? any reference would be helpful – boxed__l Jul 21 '13 at 21:34
  • 1
    @boxed__l: Although I don't understand what you mean: The parts I understand are wrong. First: I assume a standard setup. Hence the OS starts `java.exe' - just like any other program. The OS will make sure that the filehandles 0, 1 and 2 (STDIN, STDOUT, STDERR) are open and connected to whatever the starter of the program wanted them to be connected - usually the console but it can be also some file. The `java.exe` starts the JVM internally. This decorates the filehandles 0, 1, and 2 with some `InputStream` or `OutputStream` and assignes these to `System.in` and consorts. – A.H. Jul 21 '13 at 21:53
  • 1
    @boxed__l: If your program closes `System.in` this will also tell the OS that the filehandle 0 should be closed. The OS invalidates the filehandle. From this point no one has a clue whether the console or some file has been connected to filehandle 0 previously. Hence you cannot "reopen" it. Depending on the OS (Unixoid for example) you could use a JNI library to `dup` the filehandles (aka. "copy" them) at startup and "restore" them at a later point. But this requires OS-specific code and JNI. – A.H. Jul 21 '13 at 21:54
  • +1s for above explanations..I did find _JVM **creates** the initial streams_ confusing – boxed__l Jul 22 '13 at 08:49