"Low Latency" refers to one of the possible sides of high performance, in particular minimizing the time it takes a system to produce an output from the instant where an event is detected.
While there is a common ground to all optimizations (make the most out of the hardware) the type of work and optimizations to perform is quite different than when optimizing for high throughput or for high loads, and in many cases they are contradictory goals: optimizing for latency will in many cases reduce the overall performance of a system in ensuring that the response is fast.
This type of goals is quite common in financial systems, where being the first is the difference between getting the best price in a trade, or not even being able to execute the order at all.
As of the technologies that are related to this context, they usually range from good knowledge of the platform (hardware and OS) where the code will run, knowledge of performance measuring and tuning, multithreading and usually knowledge of networks.
Throughout the java.util.* package there are instances where code is written with package level protection. For example, this bit of java.util.String - a constructor in Java 6:
// Package private constructor which shares value array for speed.
String(int offset, int count, char value[]) {
this.value = value;
this.offset = offset;
this.count = count;
}
or this getChars method:
/** Copy characters from this string into dst starting at dstBegin.
This method doesn't perform any range checking. */
void getChars(char dst[], int dstBegin) {
System.arraycopy(value, offset, dst, dstBegin, count);
}
The reason for this is that the designers of the code (and java.util.* can be thought of as a rather large library) wanted the ability to have faster performance at the cost of a loss of various safety (range checks on arrays, direct access to other fields that imply the implementation rather than the interface, 'unsafe' access to parts of the class that are otherwise considered to be immutable via public methods).
By restricting these methods and fields to only be accessed by other classes in the java.util package, it makes for closer coupling between them but also avoids exposing these implementation details to the world.
If you are working on an application and don't have need to worry about other users, package level protection isn't something you need to worry about. Other than various aspects of design purity, you could make everything public and be ok with that.
However, if you are working on a library that is to be used by others (or want to avoid entangling your classes too much for later refactoring), you should use the strictest level of protection afforded to you for your needs. Often this means private. Sometimes, however, you need to expose a little bit of the implementation details to other classes in the same package to avoid repeating yourself or to make the actual implementation a bit easier at the expense of the coupling of the two classes and their implementations. Thus, the package level protection.
Best Answer
If you use the Maven Assembly Plugin, you can include the slf4j jar (along with whichever implementation you prefer) inside your deployed jar. There are more complicated options if you want to allow users to choose the logging library, but it will run perfectly well if you make a fat jar with or without the slf4j implementation.
Users are much more likely to be annoyed - unless hard drive space is really (and I mean really) at a premium - if they have to deal with
System.outandSystem.erroutput than if there's a provided logging framework, even if it's just the default no-op implementation and the have to add log4j or logback if they want to see the logs.