6 ms·

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

by 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.
    - magpi3 13y ago
      Sure I am familiar with input streams, but we are talking about doing something from memory. One quick Google search leads to an "oh, of course that is what you would do" moment, but I am just noting that even in my Java hey day I would have needed that Google search before writing the requested code. Your interface does not change the problem, but it does phrase the problem in a more familiar way and would have been much more easy for me to respond to (in my Java hey day that is).
      - cbsmith 13y ago
        > Sure I am familiar with input streams, but we are talking about doing something from memory. It's an online quiz. You don't have to do it from memory.
- jbooth 13y ago
  It's definitely a basic feature of any language, including Java. I have no idea what the people upthread are talking about. From memory (may not compile) (edit thanks to cbsmith) import java.io.*; public static void main(String[] args) { byte[] buf = new byte[4096]; while (true) { int numRead = System.in.read(buf); if (numRead < 0) { // hit EOF, terminate System.out.flush(); System.exit(0); } System.out.write(buf,0,numRead); } }
  - cbsmith 13y ago
    You need a test for the exit condition (read returning back -1) and you need to flush stdout.
    - jbooth 13y ago
      Right, thanks. Either way, it's not rocket surgery.
      - cbsmith 13y ago
        Agreed. Then again, you did mess it up the first time, so I guess it is an effective test. Everyone uses the buffer, which I find amusing.
  - benkillin 13y ago
    just for the lolz, here is another way to do it without a buffer and using some java 8 features (lambdas) to avoid having to wrap the code in a try catch (technically you still are but it looks prettier IMHO): public class SimpleJavaTest { public interface RunnableEx { // can't use Callable<Void> because that run method needs to return a value public abstract void run() throws Exception; } public static void main(String[] args) { // write standard in to standard out: uncheck( () -> { int c; while( (c = System.in.read()) > -1) { System.out.write(c); } } ).run(); } public static Runnable uncheck(RunnableEx r) { return () -> { try { r.run(); } catch(Exception e) { throw new RuntimeException(e.getMessage(), e); } }; } }
- mcherm 13y ago
  And it IS a basic feature of Java. Just not one that is used much, and therefore not one that has a particularly clear or succinct idiom. Java didn't grow up in the world of unix where scripts that read from stdin and write to stdout get chained to produce pipelines. It grew up in the world of long-running stand-alone applications that communicate over sockets (like web applications). Java, because of the virtual machine, has a particularly slow start-up time and would be a poor choice for implementing mini pipeline components like this anyway.
cbsmith 13y ago
Seriously? You've never read from or written to a stream?
- smrtinsert 13y ago
  Where does HN find these guys... It's amazing how many long term "java" developers there are here.
  - cbsmith 13y ago
    I honestly am at a loss for this. Reading & writing data from a stream without losing any information seems like a pretty basic thing you'd want to know how to do in your chosen programming language.
    - peterashford 13y ago
      The reason for this is that if you're doing IO in Java you'll usually use some kind of buffered input reader rather than stdio. I've written a command line in Java that reads commands, runs native commands, streams output to the console and even that doesn't need to read stdio as a stream. It's not that Java can't do that, it's that there are better idioms for most problems.
      - cbsmith 13y ago
        > The reason for this is that if you're doing IO in Java you'll usually use some kind of buffered input reader rather than stdio. The methods are the same with a buffered input reader. > I've written a command line in Java that reads commands, runs native commands, streams output to the console and even that doesn't need to read stdio as a stream. So, the thing that you are struggling with is how to get to System.in? But no problem doing System.out? That's not even what the various code samples that have been posted have failed. > It's not that Java can't do that, it's that there are better idioms for most problems. Java's actually very good at doing IO efficiently, and as has been demonstrated, the code for this is quite simple. Sure, you wouldn't implement "cat" in Java, but you would read and write to sockets & files with it, which provides all the knowledge one might need to figure out how to solve this. As has been pointed out, the Apache Commons libraries make it so this is a two line program with no branching or looping. That's about as simple as it gets.

by 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.
  - magpi3 13y ago
    Sure I am familiar with input streams, but we are talking about doing something from memory. One quick Google search leads to an "oh, of course that is what you would do" moment, but I am just noting that even in my Java hey day I would have needed that Google search before writing the requested code. Your interface does not change the problem, but it does phrase the problem in a more familiar way and would have been much more easy for me to respond to (in my Java hey day that is).
    - cbsmith 13y ago
      > Sure I am familiar with input streams, but we are talking about doing something from memory. It's an online quiz. You don't have to do it from memory.
jbooth 13y ago
It's definitely a basic feature of any language, including Java. I have no idea what the people upthread are talking about. From memory (may not compile) (edit thanks to cbsmith) import java.io.*; public static void main(String[] args) { byte[] buf = new byte[4096]; while (true) { int numRead = System.in.read(buf); if (numRead < 0) { // hit EOF, terminate System.out.flush(); System.exit(0); } System.out.write(buf,0,numRead); } }
- cbsmith 13y ago
  You need a test for the exit condition (read returning back -1) and you need to flush stdout.
  - jbooth 13y ago
    Right, thanks. Either way, it's not rocket surgery.
    - cbsmith 13y ago
      Agreed. Then again, you did mess it up the first time, so I guess it is an effective test. Everyone uses the buffer, which I find amusing.
- benkillin 13y ago
  just for the lolz, here is another way to do it without a buffer and using some java 8 features (lambdas) to avoid having to wrap the code in a try catch (technically you still are but it looks prettier IMHO): public class SimpleJavaTest { public interface RunnableEx { // can't use Callable<Void> because that run method needs to return a value public abstract void run() throws Exception; } public static void main(String[] args) { // write standard in to standard out: uncheck( () -> { int c; while( (c = System.in.read()) > -1) { System.out.write(c); } } ).run(); } public static Runnable uncheck(RunnableEx r) { return () -> { try { r.run(); } catch(Exception e) { throw new RuntimeException(e.getMessage(), e); } }; } }
mcherm 13y ago
And it IS a basic feature of Java. Just not one that is used much, and therefore not one that has a particularly clear or succinct idiom. Java didn't grow up in the world of unix where scripts that read from stdin and write to stdout get chained to produce pipelines. It grew up in the world of long-running stand-alone applications that communicate over sockets (like web applications). Java, because of the virtual machine, has a particularly slow start-up time and would be a poor choice for implementing mini pipeline components like this anyway.

cbsmith 13y ago

Seriously? You've never read from or written to a stream?

smrtinsert 13y ago
Where does HN find these guys... It's amazing how many long term "java" developers there are here.
- cbsmith 13y ago
  I honestly am at a loss for this. Reading & writing data from a stream without losing any information seems like a pretty basic thing you'd want to know how to do in your chosen programming language.
  - peterashford 13y ago
    The reason for this is that if you're doing IO in Java you'll usually use some kind of buffered input reader rather than stdio. I've written a command line in Java that reads commands, runs native commands, streams output to the console and even that doesn't need to read stdio as a stream. It's not that Java can't do that, it's that there are better idioms for most problems.
    - cbsmith 13y ago
      > The reason for this is that if you're doing IO in Java you'll usually use some kind of buffered input reader rather than stdio. The methods are the same with a buffered input reader. > I've written a command line in Java that reads commands, runs native commands, streams output to the console and even that doesn't need to read stdio as a stream. So, the thing that you are struggling with is how to get to System.in? But no problem doing System.out? That's not even what the various code samples that have been posted have failed. > It's not that Java can't do that, it's that there are better idioms for most problems. Java's actually very good at doing IO efficiently, and as has been demonstrated, the code for this is quite simple. Sure, you wouldn't implement "cat" in Java, but you would read and write to sockets & files with it, which provides all the knowledge one might need to figure out how to solve this. As has been pointed out, the Apache Commons libraries make it so this is a two line program with no branching or looping. That's about as simple as it gets.