Hacker News Reader

Comment by jordanpg | Hacker News Reader

> write a program that copies standard input to standard output

This is pretty trivial in Java, just as in other languages. But most people don't ever need to learn the low level `System` methods needed to do it.

To me, this highlights the difference between a comprehensive approach to learning a language and a more piecemeal one. I learned Java by reading the canonical books from cover to cover, like Effective Java. But I think this is pretty rare. For example, I recall interviewing many experienced Java programmers who didn't know what things like `protected` or `volatile` mean.

View on HN

"protected" should be obvious, if you've worked on any non-trivial Java codebase. However, I've been working with Java for over 20 years now, and don't think I have ever actually used "volatile" once. The only reason I know anything about it is because I read "Java Concurrency in Practice" once upon a time, and have a really good memory.

In my experience with concurrent code in the business world, it's more common to enforce immutability rather than try to manage state updates. On the RARE occasions to the contrary (e.g. a "tripwire" flag of some kind?), accuracy is more important that maximum performance, so you would use an atomic class or something synchronized.

Really, I think this example more than anything else just shows that technical interviewing is a speed-dating crapshoot. You just have to interview at enough places to find an opportunity you're excited about, and where you happened to not stumble across any interviewer's personal bugaboos that don't match up with you.

In my career, I have used volatile incorrectly many more times than I have used it correctly. :) For readers who are not deeply familiar with Java's volatile keyword, you can read more about it here: https://stackoverflow.com/questions/13688697/is-a-write-to-a...

I feel the same about robust, easy to maintain enterprise software: Just use a blocking queue (or disrupter circular buffer for speed freaks) and make all messages/requests immutable. It is a trivial concept to explain to new hires and all but guarantees "boring" thread-safe code can be written by junior devs.

I think I finally understood volatile (in a pratical setting) when I read the source code for class CopyOnWriteArrayList. To be honest, the first few times I read it... the pattern made no sense. I thought to myself: "Why use volatile?" After reading many times (and using volatile wrong many times), I finally understood the pattern.

Maybe thats the difference between "having mastered something" and "doing something a long time"? I cannot imagine an experienced Java programmer that doesn't know what "protected" means, its use is fundamental and pervasive. As for "volatile", idk - not knowing it hints at that person not having a concept of thread-safety. I'd expect someone who claims to be a senior to maybe not give me the memory model implications, but at least having a rough idea of what it is used for.

Volatile is specifically C's thread safety. AtomicInteger and ReentrantLock (aka mutex) are what a thread safe person should know.

volatile has nothing to do with thread safety or the memory model in modern C. It's strictly for access to memory-mapped resources, where common assumptions relied-on by optimizers may fail. It should never be used for multithreading, use proper atomics and other provided facilities instead.

Correct, but it’s worth noting that ‘volatile’ in Java does provide atomicity.

True, the guarantee of atomicity does come up in Java wrt. fields of type long or double, for which atomicity is not provided by the Java memory model in the absence of volatile. More to the point, volatile in Java provides linearizability which is a bit stronger than simple atomicity.

*sequential consistency, not linerarizability

While somebody writing concurrent Java code should definitely know the atomic classes, locks, and possibly var handles if they are implementing their own algorithms, they absolutely should also know the semantics of volatile. It does not provide thread safety in C or Java, but it’s very important in choosing how to define your data structures.

Volatile is an interesting one because it highlights a facility of the JVM that some other runtimes don't provide, namely multi-threading AND multi-process. Someone coming from node or python for example may not appreciate what's going on behind the scenes unless they go looking or have been exposed to those ideas.

Your comment made me think of a very difficult programming interview question: Can you copy STDIN to STDOUT in a non-blocking fashion? My point: The most trivial solutions assume that STDIN will give you all the data very quickly, then STDOUT will accept 100% "instantly". Using only Java, I don't know the solution off the top of my head. I will need to do a little bit of research.

However, using POSIX calls with C (select() and friends), yes, I could imagine a way to do it.

Deeper: Can you write a function to launch an external process then (a) write to its STDIN, (b) read from its STDOUT, (c) read from its STDERR -- all independently and without blocking? It's a hard problem!

It is rather non-trivial to write a program to copy input to output if one requires proper handling of a termination signal when the code flushes the already read data without waiting for more and exits without loosing any buffered data. Knowing how to do that is a good sign that the person really knows the language and it’s libraries.

Can this be done with vanilla Java? If yes, can you share a snip of code? I would curious to learn! Using POSIX C, I think I know the solution.

As another comment has written one needs Runtime.getRuntime().addShutdownHook(). The hook then, for example, closes the input stream to ensure that it’s reader is woken up from a blocking read and then waits until the already read data is written. In turn this requires to know how synchronization works.

You need to register an event handler with `Runtime.getRuntime().addShutdownHook()`.

Wouldn't just wrapping System.in with the Scanner class handle this?

I learned Java from the “Core Java” books 20 years ago. The language has changed so much since that I’m tempted to pick up another “Java from scratch” series and read it cover to cover to see how new developers are viewing the language now.

Reply on news.ycombinator.com