Things that i do at work.

Locking refers to actions taken to prevent data in a relational database from changing between the time it is read and the time that it is used. Your locking strategy can be either  optimistic  or  pessimistic . Locking strategies Optimistic Optimistic locking assumes that multiple transactions can complete without affecting each other, and that therefore transactions can proceed without locking the data resources that they affect. Before committing, each transaction verifies that no other transaction has modified its data. If the check reveals conflicting modifications, the committing transaction rolls back [ 1 ] . Pessimistic Pessimistic locking assumes that concurrent transactions will conflict with each other, and requires resources to be locked after they are read and only unlocked after the application has finished using the data. Hibernate provides mechanisms for implementing both types of locking in your applications. Optimistic When your ...

Path for java policy file: echo $JAVA_HOME/jre/lib/security/java.policy

Anti Pattern: Its a pattern which we repeatedly do and which brings negative results. Architecture by implication: Systems lacking a clear and document architecture. Cover Your Assets: Continuing to document and present alternatives, without ever making an architectural decision. Witches Brew: Architectures made by groups resulting in a mix of ideas and lack a clear vision. Gold Plating: Continuing to define an architecture well pass the time which results in no benefits to the architecture. Vendor King: A product dependent architectures leading to a loss of control of architecture and development costs Big Bang Architecture: Designing the entire architecture at the beginning of the project when you know the least about the system.

Identify the aspects of your application that varies and separate them from what stays the same. Program to an Interface, not to an Implementation. Strategy Pattern: Strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from the clients that uses it. Each pattern describes a problem that occurs over and over again in our environments.and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over without ever doing it the same way twice. Strategy using CDI and Producers: https://www.nicolaferraro.me/2016/02/24/strategy-pattern-using-cdi/

Crypto - Secret Graphy - To Write CryptoLogy - The science of secrets Symmetric Cryptography: Both the parties have the same keys. Asymmetric Cryptography: Both the parties do not have the same keys. They work on the concept of Public and Private Keys. Its also called as Public Key Cryptography. Its very expensive to encrypt and decrypt using Asymmetric Cryptography. Hence there are systems which use both Symmetric and Asymmetric Cryptography together like ECC. Don't implement your own Crypto. Its very easy to do it incorrectly. Side Channel: When you can observer properties of a function other than their functional behaviour it is called as Side Channel. E.g. Knowing how long it takes to encrypt a text, knowing the length of a particular encrypted text. In cryptography,  Kerckhoffs's principle  (also called  Kerckhoffs's  desideratum, assumption, axiom, doctrine or law) was stated by Netherlands born cryptographer Auguste  Kerckhoffs  in the ...

// These methods are all very similar, unfortunately there's no way to use Java templates to solve // The redundancy because annotations can not have inheritance, and the ".value()" function is specific // to each class Stripe Lock in Java: https://google.github.io/guava/releases/19.0/api/docs/com/google/common/util/concurrent/Striped.html http://codingjunkie.net/striped-concurrency/ The Simple Logging Facade for Java (SLF4J) serves as a simple facade or abstraction for various logging frameworks (e.g. java.util.logging, logback, log4j) allowing the end user to plug in the desired logging framework at  deployment time.

https://www.petrikainulainen.net/getting-started-with-gradle/

https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/ http://taligarsiel.com/ClientSidePerformance.html -- Client side performance tips https://ariya.io/ https://vertx.io/docs/ -- New exciting Framework, Must read. https://javaee.github.io/ -- Very good resource to see various javaee projects and explore enterprise architecture and design concepts. https://projects.eclipse.org/projects/ee4j -- Lots of interesting open source projects by eclipse http://openjdk.java.net/projects/mlvm/ -- the main project for supporting more dynamic languages to jvm. http://esprima.org/ -- EcmaScript parser http://c2.com/ppr/ and http://hillside.net/ -- Good place to learn patterns http://cr.openjdk.java.net/~briangoetz/lambda/Defender%20Methods%20v4.pdf https://validator.w3.org/nu/ -- This will validate your website css and js https://www.cellstream.com/intranet/reference-reading/faq/216-what-is-2-128.html http://shattered.io/ -- An example of SHA1 collision attack.

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

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

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 ; // ne...