8 ms·

So I was a Java developer from 2006-2012. I still occasionally touch Java at work. Off the top of my head, right now, in this text box, without google, I can't

by SCdF 13y ago

So I was a Java developer from 2006-2012. I still occasionally touch Java at work. Off the top of my head, right now, in this text box, without google, I can't write the code to copy standard input to standard output. System.out.println(System.in)? That's wrong. You need some kind of InputReader, or BufferedInputReader, or Buffered...something. I think System.in is an InputStream, so presumably I need to do new InputReader(System.in)? Or BufferedInputReader? Should I buffer the output? Ok, let's do some API googling (ie, not StackOverflow). So I was... pretty wrong. I think what you want is: public class CopyInput { public static void main(String[] args) { while (true) System.out.write(System.in.read); } } I haven't tried to run this though. In my defence, I have never, in all my years of working, had to ever read standard input, let alone write it out again.

bermanoid 13y ago
I was about to say the exact same thing: I'd probably walk out of an interview if remembering how to read stdin was part of it, because it comes up maybe once every couple of years in real work, better to just Google it. Don't tailor from-memory standard library questions to bits of code that almost nobody ever has to use.
- sophacles 13y ago
  I think that is sort of the point of the article though (or at least one of the points...). Dealing with stdin/stdout is not uncommon in itself, though it is probably rare in java. Choosing the right tool for the job is kind of important in most aspects of software, so doing a simple script in say python or a few lines of C or whatever is important - it shows a familiarity with the environment, not just the language(s). For example: Whenever I'm dealing with a data processing pipeline I tend to design things as if they would be used from a unix command line. I tell the team to make their classes etc as if they would be wrapped with a simple chunk of code to parse a text stream then serialize to it later. During the course of testing, I almost always will then write those tools to allow simple command line pipes to push test data around. It helps prevent reliance on certain toolsets and certainly helps stop us from conflating bugs in our code with bugs or operator error about a pipeline framework. Later we can go back and more closely integrate with the chosen operating environment, if performance demands it. On the other hand going from a situation where code is written to the environment and migrating to another environment can be very daunting, difficult and error prone.
- torrent-of-ions 13y ago
  It depends. If the job is Unix/Linux based then I'd say you definitely should know how to do stdio.
- cbsmith 13y ago
  > Don't tailor from-memory standard library questions to bits of code that almost nobody ever has to use. So seriously? You almost never need to read & write to streams?
  - bermanoid 13y ago
    No. I almost never need to read from stdin, as I said. Again, most of us write real apps, not command line utilities.
cs02rm0 13y ago
Yeah, I've spent 10 years as a Java developer and I'd have to think about how to do it in Java. It just isn't a problem Java was designed to fix - sledgehammers, nuts and all that.
- ZanyProgrammer 13y ago
  Which seems pretty amazing to me. Granted I'm not a Java developer, but it seems like such a basic feature of any language.
  - magpi3 13y ago
    But how often do you read stdin in Java? It's a language that is used heavily to build web apps and (though less so) desktop GUI apps. I also programmed in Java for nearly a decade in the late nineties till about 2004 and have never used System.in for anything.
    - Jtsummers 13y ago
      I'm writing desktop GUI apps in C# these days. Not the same as Java, but still many people would probably ask the same thing about C# as you've asked about Java: How often would you read stdin in C#? I use it at various prototyping stages of my applications. Oh, I need to handle a new file format. Ok, write the parser and classes to contain the file contents. Then create a quick console app that lets me read in a file and pose questions to it (give me the contents of data block 0x0840, what's its time tag, etc.). Now I need to run analyses on the file, and there's another file format that contains the queries. Create a quick console app that lets me combine those two pieces and a simple text interface to explore it. Then, once the pieces work, I plug them into the GUI. Now, do I do this every week? No, because after a certain point it's all about the GUI and other interactions. But it's a great way (for me) to prototype, and I'd use this approach regardless of the language for most programming tasks.
    - cbsmith 13y ago
      > But how often do you read stdin in Java? Doesn't matter. For this problem it is just a conveniently available InputStream. How often do you read from an InputStream? I'd hope the answer to that isn't 0. > I also programmed in Java for nearly a decade in the late nineties till about 2004 and have never used System.in for anything. Okay, then change the problem to implementing this interface: public interface Copier { public void copy(java.io.InputStream in, java.io.PrintStream out); } That doesn't change the problem.
cbsmith 13y ago
> In my defence, I have never, in all my years of working, had to ever read standard input, let alone write it out again. Yeah, but there is nothing different from this and having to copy data from an input stream to an output stream. If you can't remember how to do that, it kind of raises the question of what you were doing in Java. Not knowing if you need to buffer is actually fine in my book. That's an optimization thing. Not knowing how to make the code correct though...
- SCdF 13y ago
  Crud apps my man, ones where the framework did all the IO for you.
tod222 13y ago
You probably never use the command line. People like me who use pipelines on *nix [1] every day write these sorts of filters all the time. [1] http://en.wikipedia.org/wiki/Pipeline_%28Unix%29#Pipelines_in_command_line_interfaces http://en.wikipedia.org/wiki/Pipeline_%28Unix%29#Pipelines_i...

by SCdF 13y ago

bermanoid 13y ago

I was about to say the exact same thing: I'd probably walk out of an interview if remembering how to read stdin was part of it, because it comes up maybe once every couple of years in real work, better to just Google it. Don't tailor from-memory standard library questions to bits of code that almost nobody ever has to use.

sophacles 13y ago
I think that is sort of the point of the article though (or at least one of the points...). Dealing with stdin/stdout is not uncommon in itself, though it is probably rare in java. Choosing the right tool for the job is kind of important in most aspects of software, so doing a simple script in say python or a few lines of C or whatever is important - it shows a familiarity with the environment, not just the language(s). For example: Whenever I'm dealing with a data processing pipeline I tend to design things as if they would be used from a unix command line. I tell the team to make their classes etc as if they would be wrapped with a simple chunk of code to parse a text stream then serialize to it later. During the course of testing, I almost always will then write those tools to allow simple command line pipes to push test data around. It helps prevent reliance on certain toolsets and certainly helps stop us from conflating bugs in our code with bugs or operator error about a pipeline framework. Later we can go back and more closely integrate with the chosen operating environment, if performance demands it. On the other hand going from a situation where code is written to the environment and migrating to another environment can be very daunting, difficult and error prone.
torrent-of-ions 13y ago
It depends. If the job is Unix/Linux based then I'd say you definitely should know how to do stdio.
cbsmith 13y ago
> Don't tailor from-memory standard library questions to bits of code that almost nobody ever has to use. So seriously? You almost never need to read & write to streams?
- bermanoid 13y ago
  No. I almost never need to read from stdin, as I said. Again, most of us write real apps, not command line utilities.

cs02rm0 13y ago

Yeah, I've spent 10 years as a Java developer and I'd have to think about how to do it in Java. It just isn't a problem Java was designed to fix - sledgehammers, nuts and all that.

ZanyProgrammer 13y ago
Which seems pretty amazing to me. Granted I'm not a Java developer, but it seems like such a basic feature of any language.
- magpi3 13y ago
  But how often do you read stdin in Java? It's a language that is used heavily to build web apps and (though less so) desktop GUI apps. I also programmed in Java for nearly a decade in the late nineties till about 2004 and have never used System.in for anything.
  - Jtsummers 13y ago
    I'm writing desktop GUI apps in C# these days. Not the same as Java, but still many people would probably ask the same thing about C# as you've asked about Java: How often would you read stdin in C#? I use it at various prototyping stages of my applications. Oh, I need to handle a new file format. Ok, write the parser and classes to contain the file contents. Then create a quick console app that lets me read in a file and pose questions to it (give me the contents of data block 0x0840, what's its time tag, etc.). Now I need to run analyses on the file, and there's another file format that contains the queries. Create a quick console app that lets me combine those two pieces and a simple text interface to explore it. Then, once the pieces work, I plug them into the GUI. Now, do I do this every week? No, because after a certain point it's all about the GUI and other interactions. But it's a great way (for me) to prototype, and I'd use this approach regardless of the language for most programming tasks.
  - cbsmith 13y ago
    > But how often do you read stdin in Java? Doesn't matter. For this problem it is just a conveniently available InputStream. How often do you read from an InputStream? I'd hope the answer to that isn't 0. > I also programmed in Java for nearly a decade in the late nineties till about 2004 and have never used System.in for anything. Okay, then change the problem to implementing this interface: public interface Copier { public void copy(java.io.InputStream in, java.io.PrintStream out); } That doesn't change the problem.

cbsmith 13y ago

> In my defence, I have never, in all my years of working, had to ever read standard input, let alone write it out again. Yeah, but there is nothing different from this and having to copy data from an input stream to an output stream. If you can't remember how to do that, it kind of raises the question of what you were doing in Java. Not knowing if you need to buffer is actually fine in my book. That's an optimization thing. Not knowing how to make the code correct though...

SCdF 13y ago
Crud apps my man, ones where the framework did all the IO for you.

tod222 13y ago

You probably never use the command line. People like me who use pipelines on *nix [1] every day write these sorts of filters all the time. [1] http://en.wikipedia.org/wiki/Pipeline_%28Unix%29#Pipelines_in_command_line_interfaces http://en.wikipedia.org/wiki/Pipeline_%28Unix%29#Pipelines_i...