Things that i do at work.

I'd suggest that it is better practice to use `String.format()` . The main reason is that `String.format()` can be more easily localised with text loaded from resource files whereas concatenation can't be localised without producing a new executable with different code for each language If you plan on your app being localisable you should also get into the habit of specifying argument positions for your format tokens as well: "Hello %1$s the time is %2$t" This can then be localised and have the name and time tokens swapped without requiring a recompile of the executable to account for the different ordering. With argument positions you can also re-use the same argument without passing it into the function twice: String.format("Hello %1$s, your name is %1$s and the time is %2$t", name, time) Because printf-style format strings are interpreted at runtime, rather than validated by the compiler, they can contain errors that result in the wrong str

Thomas J. McCabe introduced Cyclomatic Complexity in 1976 as a way to guide programmers in writing methods that "are both testable and maintainable". At SonarSource, we believe Cyclomatic Complexity works very well for measuring testability, but not for maintainability. That's why we're introducing Cognitive Complexity, which you'll begin seeing in upcoming versions of our language analyzers. We've designed it to give you a good relative measure of how difficult the control flow of a method is to  understand . Cyclomatic Complexity doesn't measure maintainability To get started let's look at a couple of methods: int sumOfPrimes(int max) { // +1 int total = 0; OUT: for (int i = 1; i <= max; ++i) { // +1 for (int j = 2; j < i; ++j) { // +1 if (i % j == 0) { // +1 continue OUT; } } total += i; } return total; } // Cyclomatic Complexity 4 String getWord

A striped  Lock/Semaphore/ReadWriteLock . This offers the underlying lock striping similar to that of  ConcurrentHashMap  in a reusable form, and extends it for semaphores and read-write locks. Conceptually, lock striping is the technique of dividing a lock into many  stripes , increasing the granularity of a single lock and allowing independent operations to lock different stripes and proceed concurrently, instead of creating contention for a single lock. The guarantee provided by this class is that equal keys lead to the same lock (or semaphore), i.e.  if (key1.equals(key2))  then  striped.get(key1) == striped.get(key2)  (assuming  Object.hashCode()  is correctly implemented for the keys). Note that if  key1  is  not  equal to  key2 , it is  not  guaranteed that  striped.get(key1) != striped.get(key2) ; the elements might nevertheless be mapped to the same lock. The lower the number of stripes, the higher the probability of this happening. There are three flavors of this class: 

This was a deliberate decision, rather than an omission (as has been suggested elsewhere.) While at first it might seem obvious that one would want to support the  synchronized  modifier on default methods, it turns out that doing so would be dangerous, and so was prohibited. Synchronized methods are a shorthand for a method which behaves as if the entire body is enclosed in a  synchronized  block whose lock object is the receiver. It might seem sensible to extend this semantics to default methods as well; after all, they are instance methods with a receiver too. (Note that  synchronized  methods are entirely a syntactic optimization; they're not needed, they're just more compact than the corresponding  synchronized  block. There's a reasonable argument to be made that this was a premature syntactic optimization in the first place, and that synchronized methods cause more problems than they solve, but that ship sailed a long time ago.) So, why are they dangerous? Synch

MappedSuperClass must be used to inherit properties, associations, and methods. Entity inheritance must be used when you have an entity, and several sub-entities. You can tell if you need one or the other by answering this questions: is there some other entity in the model which could have an association with the base class? If yes, then the base class is in fact an entity, and you should use entity inheritance. If no, then the base class is in fact a class that contains attributes and methods that are common to several unrelated entities, and you should use a mapped superclass. For example: You can have several kinds of messages: SMS messages, email messages, or phone messages. And a person has a list of messages. You can also have a reminder linked to a message, regardless of the kind of message. In this case, Message is clearly an entity, and entity inheritance must be used. All your domain objects could have a creation date, modification date and ID, and you could thus

If you're concerned about performance when iterating through your hash map, I suggest you have a look at  LinkedHashMap . From the docs: Iteration over the collection-views of a LinkedHashMap requires time proportional to the size of the map, regardless of its capacity. Iteration over a HashMap is likely to be more expensive, requiring time proportional to its capacity. HashMap.entrySet() The source-code for this implementation is available. The implementation basically just returns a new  HashMap.EntrySet . A class which looks like this: private final class EntrySet extends AbstractSet < Map . Entry < K , V >> { public Iterator < Map . Entry < K , V >> iterator () { return newEntryIterator (); // returns a HashIterator... } // ... } and a  HashIterator  looks like private abstract class HashIterator < E > implements Iterator < E > { Entry < K , V > next ; // next entry to ret