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.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).
It's an online quiz. You don't have to do it from memory.
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.
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);
}
} 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);
}
};
}
}... And here's a fine example of Java culture.
2 lines do stuff, everything else is fluff, and it is considered prettier.
BTW: I did not run this specific code, but dropping the buffer is likely to make this code take much, much more CPU (unless HotSpot is much better these days than it was in 2010 when I last used it). That's another pillar of Java culture - care not about performance.
Disclaimer: I didn't test this, and any mention of performance requires testing, rather than reasoning. I don't have a Java compiler handy anymore, or I would test it.
e.g. if the File implementation had an internal buffer (C stdio's "FILE " does), and the read from that* buffer was inlined (from my past experience up to date as of early 2011, HotSpot doesn't, but LuaJIT does), it might not make any difference.
Seriously, LuaJIT does things I've never thought I'd see a compiler (JIT or AOT) for any language (dynamic or statically typed) do. I used to reply to "sufficiently smart compiler" with "one hasn't appeared yet, despite at least 3 decades of waiting". But LuaJIT has appeared.