4 ms·

> 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

> 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.

marktangotango 5y ago
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.
MrBuddyCasino 5y ago
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.
- pie_flavor 5y ago
  Volatile is specifically C's thread safety. AtomicInteger and ReentrantLock (aka mutex) are what a thread safe person should know.
  - zozbot234 5y ago
    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.
    - nicoburns 5y ago
      Correct, but it’s worth noting that ‘volatile’ in Java does provide atomicity.
      - zozbot234 5y ago
        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.
        ysleepy 5y ago
        *sequential consistency, not linerarizability
  - aardvark179 5y ago
    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.
  - deleted 5y ago
    [deleted]
_0w8t 5y ago
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.
- throwaway2037 5y ago
  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.
  - xmodem 5y ago
    You need to register an event handler with `Runtime.getRuntime().addShutdownHook()`.
  - _0w8t 5y ago
    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.
- Scarbutt 5y ago
  Wouldn't just wrapping System.in with the Scanner class handle this?
StevePerkins 5y ago
"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.
- throwaway2037 5y ago
  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-volatile-a-memory-barrier-in-java 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.
throwaway2037 5y ago
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!
commandlinefan 5y ago
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.

marktangotango 5y ago

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.

MrBuddyCasino 5y ago

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.

pie_flavor 5y ago
Volatile is specifically C's thread safety. AtomicInteger and ReentrantLock (aka mutex) are what a thread safe person should know.
- zozbot234 5y ago
  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.
  - nicoburns 5y ago
    Correct, but it’s worth noting that ‘volatile’ in Java does provide atomicity.
    - zozbot234 5y ago
      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.
      - ysleepy 5y ago
        *sequential consistency, not linerarizability
- aardvark179 5y ago
  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.
- deleted 5y ago
  [deleted]

_0w8t 5y ago

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.

throwaway2037 5y ago
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.
- xmodem 5y ago
  You need to register an event handler with `Runtime.getRuntime().addShutdownHook()`.
- _0w8t 5y ago
  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.
Scarbutt 5y ago
Wouldn't just wrapping System.in with the Scanner class handle this?

StevePerkins 5y ago

"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.

throwaway2037 5y ago
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-volatile-a-memory-barrier-in-java 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.

throwaway2037 5y ago

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!

commandlinefan 5y ago

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.