Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Copying stdin to stdout in Java

gist.github.com

Post reply on HN
Print view View original

31–40 of 61 posts

Re: Copying stdin to stdout in Java

#31

Post by RyanZAG »

acqq wrote: post #26
RyanZAG wrote: post #19

Earlier quoted context omitted.

You open network sockets in Linux and redirect stdout to them? It's possible with curl I guess, but generally people don't do that as it's hard to send the data in the right format. Mostly people will use a tool to access network services. As for serving files, you'd normally let nginx or apache take care of the sockets for you and not use output redirection. In Plan9 it's actually viable to use network sockets as fi…

> but for Linux it's not really how people do it. Please explain that to all the people who wrote CGI scripts for years. Seen the link at all?

CGI scripts are dead though. It turns out it wasn't a good way to do it. It's better to use a nice new invention like Apache or Nginx to handle the sockets for you and then use frameworks specifically designed to handle HTTP responses as piping HTML through std inputs is difficult and error prone.

The ability of a language to easily write to std out is simply not important anymore apart from shell scripting which is mostly used these days for setting up the runtime environment and building other languages to handle the grunt work.

I don't know of any companies that still pipe std output directly to sockets anymore, but I guess there must be some. If your company still does this then a language feature like that makes sense. For most people, having the ability to write code that can directly write to sockets without piping through a shell is better practice.

Re: Copying stdin to stdout in Java

#32

Post by bananas »

acqq wrote: post #30
abalone wrote: post #25

As he notes in the comments, you'd really just do this: IOUtils.copy(System.in, System.out); using the Apache Commons library. That's the most apples-to-apples comparison to more "scripty" languages that have more stuff built in. With Java you pick the libraries/frameworks you want to use. Commons and Guava are extremely popular and robust libraries and really should be included in any comparison against "real world"…

Still, Awk and Perl need no library, the semantics was the part of the language since the beginning, and is always available to every programmer, also for the bigger programs. Awk and Sed were obvious inspirations for Perl.

Awk and Perl are tools built on another language that does stream copying i.e. read stdin and write stdout.

You could build Awk and Perl in Java if you wanted and have the same result.

  System.out.println("hello world");
Is the same as:

  printf("hello world\n");

Re: Copying stdin to stdout in Java

#33

Post by lmm »

cromwellian wrote: post #14

Amazingly, in Java 8, they added a Files utility class to copy an InputStream to a Path, and copy a Path to an OutputStream, but no Files.copy(InputStream, OutputStream). At this point, Guava should just be added as part of the JDK. :) In Guava, ByteStreams.copy(System.in, System.out)

Java has really solid dependency management with maven, so I'd actually like to see less in the JDK. Let Guava/JodaTime/log4j/etc. keep their faster release cycle, just deprecate the parts of the JDK that used to do those things and point developers in the right direction.

Re: Copying stdin to stdout in Java

#34

Post by Perseids »

dvdkhlng wrote: post #27
Perseids wrote: post #23

Earlier quoted context omitted.

(You referenced the one byte read function, instead of the multi-byte function used in the OP.) The documentation does not answer how long it blocks. Blocking when there is no input is completely ok in this use case as there is nothing better to do instead of waiting for input. The relevant question is how long it blocks after there is some input available for efficiency reasons.

> there is nothing better to do instead of waiting for input. In case no more input is available it would be best to already output the data that have accumulated in buffer. Else in case the input program deadlocks you're never going to see the last (up to 8191) bytes output. This is what non-blocking I/O is for. With non-blocking I/O you first wait until your input channel becomes readable, then reading functions re…

You are right but I was talking about the case when no input was there to be read since the call to `read` and also about this specific application:

> Blocking when there is no input is completely ok in this use case as there is nothing better to do instead of waiting for input.

(Emphasis is new.)

Re: Copying stdin to stdout in Java

#35

Post by kamaal »

abalone wrote: post #25

As he notes in the comments, you'd really just do this: IOUtils.copy(System.in, System.out); using the Apache Commons library. That's the most apples-to-apples comparison to more "scripty" languages that have more stuff built in. With Java you pick the libraries/frameworks you want to use. Commons and Guava are extremely popular and robust libraries and really should be included in any comparison against "real world"…

>>High-level Java

How is file manipulation High level. That sort of stuff should work right next after your Hello, World program.

If you are telling me Java intentionally makes easy things difficult. Its the last thing I want to use to solve difficult problems.

Re: Copying stdin to stdout in Java

#36

Post by Alphasite_ »

dvdkhlng wrote: post #22
acqq wrote: post #16

Earlier quoted context omitted.

You are right, the shortest awk is one byte. Please post the link all nine variants I wasn't able to Google it. Still the shortest Perl is 0 bytes when the command line switch is allowed to be -p Update: That's actually called "the sed mode of Perl." Moreover these two command lines behave similarly: perl -pe 's/search/replace/g' and sed 's/search/replace/'

SED is shorter (0 byte). SED /is/ a turing complete language [1] so don't try to claim that I'm cheating. sed output :) [1] http://robertkotcher.com/sed.html [update] s/set/sed/

Even java can do that setOut(system.in); (iirc)

Re: Copying stdin to stdout in Java

#37

Post by einhverfr »

RyanZAG wrote: post #31
acqq wrote: post #26

Earlier quoted context omitted.

> but for Linux it's not really how people do it. Please explain that to all the people who wrote CGI scripts for years. Seen the link at all?

CGI scripts are dead though. It turns out it wasn't a good way to do it. It's better to use a nice new invention like Apache or Nginx to handle the sockets for you and then use frameworks specifically designed to handle HTTP responses as piping HTML through std inputs is difficult and error prone. The ability of a language to easily write to std out is simply not important anymore apart from shell scripting which is…

I wouldn't say they are totally dead. They are great for relatively quick/dirty code.

The major advantage that CGI gives you is the fact that you get a new, clean process on each request. This means you have fewer and simpler failure cases. This can be helpful when you have a line of business web application though it is certainly suboptimal for public-facing scalable systems.

I wouldn't say cgi is dead. It still has a role to play. It is not the ideal way for doing many things though. I.e. they are no longer the go-to tool, but rather one tool for relatively lower-volume applications where performance matters less than some other considerations.

Re: Copying stdin to stdout in Java

#38

Post by chatman »

Python, shell, etc. isn't suitable for high scalability, fast applications (e.g. Apache Solr, Lucene, Hadoop etc.). And beginner examples like these make no sense. Java clearly has an important role in this world, maybe not in yours (if you're so irked by "verbosity").

Re: Copying stdin to stdout in Java

#39

Post by abalone »

kamaal wrote: post #35
abalone wrote: post #25

As he notes in the comments, you'd really just do this: IOUtils.copy(System.in, System.out); using the Apache Commons library. That's the most apples-to-apples comparison to more "scripty" languages that have more stuff built in. With Java you pick the libraries/frameworks you want to use. Commons and Guava are extremely popular and robust libraries and really should be included in any comparison against "real world"…

>>High-level Java How is file manipulation High level. That sort of stuff should work right next after your Hello, World program. If you are telling me Java intentionally makes easy things difficult. Its the last thing I want to use to solve difficult problems.

File manipulation, like any kind of computer programming, can be programmed in a high-level or low-level way. High-level is easier and reflects some assumptions and opinions. Low-level gives you more control. With Java, you can choose which way you want to go, and the easier route is only as "difficult" as choosing a high-level framework.

Re: Copying stdin to stdout in Java

#40

Post by dvdkhlng »

Alphasite_ wrote: post #36
dvdkhlng wrote: post #22

Earlier quoted context omitted.

SED is shorter (0 byte). SED /is/ a turing complete language [1] so don't try to claim that I'm cheating. sed output :) [1] http://robertkotcher.com/sed.html [update] s/set/sed/

Even java can do that setOut(system.in); (iirc)

> Even java can do that setOut(system.in);

I was referring to an empty SED-program that would then be run via 'sed -f empty-file.sed'. Of course you need >0 bytes to invoke the SED program.

Post reply on HN