12

I'm trying to re-factor a large and frequently used part of my application into separate methods to make it easier to maintain.

Some of these methods asks the user for input and does input validation, so I've used a Scanner and System.in But when I close my Scanner I also close System.in

So my question is, can I only prevent System.in being closed by shielding it with CloseShieldInputStream or should I just start passing a Scanner to the methods?

deepy
  • 473
  • 4
  • 20
  • Please post some code... – nkukhar Feb 19 '13 at 16:14
  • 6
    Do you really need to close the Scanner? I'd suggest letting the garbage collector handle it - there's no way of closing it without closing the underlying object. – ddmps Feb 19 '13 at 16:15
  • 2
    My method declares a Scanner, reads and returns nextLine(), closes the Scanner and gives me a headache on the next run. If I do not close it, Eclipse pesters me about a potential resource leak, would it be safe to ignore that? – deepy Feb 19 '13 at 16:15
  • 1
    Eclipse is simply wrong in this case - or rather, it's being overly cautious. Closing a Scanner has no useful effect other than closing the underlying InputStream, so if you don't want to close `System.in` then don't call `close()` on the Scanner. – kaya3 Jan 28 '20 at 04:33

3 Answers3

19

Simply use a custom FilterInputStream instead of System.in:

new FilterInputStream(System.in) {
    @Override
    public void close() throws IOException {
        //don't close System.in! 
    }
}
Raúl Salinas-Monteagudo
  • 3,412
  • 1
  • 24
  • 22
  • 2
    This is pretty much what commons' [CloseShieldInputStream](http://commons.apache.org/proper/commons-io/apidocs/org/apache/commons/io/input/CloseShieldInputStream.html) does and if you end up this position, you may want to have another look at the design of your software. A solution like this shouldn't be needed unless you're working with third-party solutions. (applies to all the answers here) – deepy Sep 30 '14 at 14:28
  • @deepy I don't understand your reasoning. Why would this not be needed? How else would one handle a case where you need to use a scanner multiple times in the lifetime of a program other than making the scanner a variable that is effectively global? – Emmanuel Apr 15 '22 at 12:25
  • @Emmanuel you're asking a question regarding an 8 year old question, but the question is not how to re-use the scanner, the question is how to prevent `System.in` from being closed when the `Scanner` closes – deepy Apr 16 '22 at 13:10
  • @deepy I saw how old the question was, I simply held out hope you might be notified of my question. Alas, you were. Your comment was not exactly an answer to the question. You stated a viewpoint that I do not understand i.e. "... if you end up this position, you may want to have another look at the design of your software". I fail to see how ending up in said position (wanting to close the scanner but not System.in) implied a design flaw in the software. I was hoping you would clarify that view point. I'm just trying to learn. – Emmanuel Apr 16 '22 at 17:22
3

You can just ignore close by implementing custom decorator.

public class UnClosableDecorator extends InputStream {

    private final InputStream inputStream;

    public UnClosableDecorator(InputStream inputStream) {
        this.inputStream = inputStream;
    }

    @Override
    public int read() throws IOException {
        return inputStream.read();
    }

    @Override
    public int read(byte[] b) throws IOException {
        return inputStream.read(b);
    }

    @Override
    public int read(byte[] b, int off, int len) throws IOException {
        return inputStream.read(b, off, len);
    }

    @Override
    public long skip(long n) throws IOException {
        return inputStream.skip(n);
    }

    @Override
    public int available() throws IOException {
        return inputStream.available();
    }

    @Override
    public synchronized void mark(int readlimit) {
        inputStream.mark(readlimit);
    }

    @Override
    public synchronized void reset() throws IOException {
        inputStream.reset();
    }

    @Override
    public boolean markSupported() {
        return inputStream.markSupported();
    }

    @Override
    public void close() throws IOException {
        //do nothing
    }
}

And use it in main 

public static void main(String[] args) throws Exception {
        System.setIn(new UnClosableDecorator(System.in));
}
nkukhar
  • 1,975
  • 2
  • 18
  • 37
  • Wouldn't this be the same as writing my own version of CloseShieldInputStream? – deepy Feb 19 '13 at 16:33
  • I'm not quite sure what do you mean, but if you need to perform some actions with input stream on close do this actions in UnClosableDecorator.close() method – nkukhar Feb 19 '13 at 16:36
  • 1
    CloseShieldInputStream is a proxy stream that prevents the underlying input stream from being closed. http://commons.apache.org/io/apidocs/org/apache/commons/io/input/CloseShieldInputStream.html – deepy Feb 19 '13 at 17:03
  • Actually my implementation is not the same as CloseShieldInputStream. CloseShieldInputStream on close will replace input stream with dummy object that on read always returns -1 (it means that InputStream is closed) and my implementation on close just do nothing. I'm not sure what solution will be more appropriate for you. – nkukhar Feb 19 '13 at 18:35
  • 2
    I suspect I should just start passing Scanners around instead, it seems to be the least painful way in the end. – deepy Feb 20 '13 at 01:25
1

you could just let it be without closing it, just set the holding variable to null

mamayr
  • 31
  • 4