Java Core

* Set -> Doesn't allow duplicates, doesn't allow null objects, unordered.
* List -> Order in-coming, allow null objects, allow duplicates.
* Queue -> ordered, data structured FIFO. access data
* Map -> Order, doesn't allow null objects, Key- value.

* If you define a equals() method then you must define a hashCode() method as well. Also, it means that if you have two objects that are equal then they must have the same hashCode, however, the reverse is not true.
* If .equals() returns true, the hash code should return true as well.
* If you are overriding the equals method then you should override hashcode() also.
* If two objects are equal then they must have the same hashcode.
* If two objects have the same hashcode then they may or may not be equal
* Always use same attributes to generate equals and hashcode as in our case we have used name.

* The default method in Java 8, allows overriding one method which repeats on an interface.

* For methods for calling without creating an instance, classes, and attributes to don't allow creating copies and be static a position in the memory.

* Interface: members like a contract. Abstract class: default implementation (properties or methods for an exclusive class).
* Abstract classes can have constants, members, method stubs (methods without a body) and defined methods, whereas interfaces can only methods headers, (Java 8 Interface default method).
* Methods and members of an abstract class can be defined with any visibility, whereas all methods of an interface must be defined as public (they are defined public by default).
* When inheriting an abstract class, a concrete child class must define the abstract methods, whereas an abstract class can extend another abstract class and abstract methods from the parent class don't have to be defined.
* Similarly, an interface extending another interface is not responsible for implementing methods from the parent interface. This is because interfaces cannot define any implementation.

* A child class can only extend a single class (abstract or concrete), whereas an interface can extend or a class can implement multiple other interfaces.
* A child class can define abstract methods with the same or less restrictive visibility, whereas a class implementing an interface must define the methods with the exact same visibility (public).

* Members: constants.
* Classes, Methods: Don't allow be instanced nor override;

* Only is possible inside an anonymous class.

* LinkedHashSet internally contains a double-linked list running through all of its entries that define the order of elements. This class allows null elements.
* Both implementations are not synchronized, so they must be synchronized externally.
* LinkedHashMap allows null objects.

* The Java 8 Streams can be seen as lazily constructed Collections, where the values are computed when the user demands it. Actual Collections behave absolutely opposed to it and they are set off eagerly computed values (no matter if the user demands a particular value or not).

* A functional interface is valid even if the @FunctionalInterface annotation would be omitted. It is only for informing the compiler to enforce a single abstract method inside the interface.

* Cohesion:
- high -> when a class has an only reason for the change.
- low -> when the class has more than one reason.
* Coupling:
- high -> when the class knows deeply the other classes or his implementations (inheritance).
- low -> when the class doesn't know about the others classes. Dependency Injection reduces the coupling.

* Both OOP and FP have the shared goal of creating understandable, flexible programs that are free of bugs. But they have two different approaches for how to best create those programs.
* In all programs, there are two primary components: the data (the stuff a program knows) and the behaviors (the stuff a program can do to/with that data).
* OOP says that bringing together data and its associated behavior in a single location (called an "object") makes it easier to understand how a program works.
* FP says that data and behavior are distinctively different things and should be kept separate for clarity.
* http://www.codenewbie.org/blogs/object-oriented-programming-vs-functional-programming

* Yes, but must be enclosed into a method with throws clause, or a containing try-catch.

* No, only is possible to "relax" the restriction (e.g. protected -> public) but not otherwise (e.g. protected -> private).

* None.

* No, but they can be subclassed.

* No, because subclasses need to see superclasses abstract methods.

* No, only from an instantiated object.

* Yes
- How?
* this(<<arguments>>)

* No.

- Why?
* Because it is final.

* Yes, because only the object reference cannot be updated.

* Thread t = new Thread(<<Runnable Object>> or anonymous Runnable)

* java.lang.Object

* Within a serialized context (streams, files, network), transient applies for non-serializable fields.

* 65535.

* Override hashCode method as well.

* Checked exceptions are those errors that are meant to be known by the programmer, thus, giving the chance of propagating/catching the error on different application layers.
* Unchecked exceptions are those how to fail on semantic errors.

because String is immutable and remains in memory until GC collects it, in between, memory dump can reveal it.

making the class final (Strong Immutability, cannot be extended) or making your methods final (Weak immutability cannot override properties).

* They are generally used as a global instance, why is that so bad? Because you hide the dependencies of your application in your code, instead of exposing them through the interfaces. Making something global to avoid passing it around is a code smell.
* They violate the single responsibility principle: by virtue of the fact that they control their own creation and life cycle.
* They inherently cause code to be tightly coupled. This makes faking them out under test rather difficult in many cases.
* They carry state around for the lifetime of the application. Another hit to testing since you can end up with a situation where tests need to be ordered which is a big no for unit tests. Why? Because each unit test should be independent of the other.

why?

why?

Java is too verbose (highly typed language) and sometimes devs don't know/use it

Mutability is desirable if and only if it is isolated from the client.

When failing due to exceptions, all previous blocks are retracted until the exception is caught in one stack frame (ultimately the main frame).

in a class cannot be overridden by its subclasses

* Session Bean -> An interaction between a client and the service, the client creates a session with the server. It is stateless(Not maintain a conversational state, no states persisted along with the method calls), stateful(it does maintain, an object lives through the sessions calls), or singleton (one session per application)
* Entity Bean -> Conserves the nature of objects (they can be designed and used as objects), representing the persisted data.
* Message-Driven Bean -> Asynchronous calls between systems.

* @EJB: Other EJB references
* @Resource: Datasources or singletons EJB's

@Interceptors and @AroundInvoke

* REQUIRED -> If there is a transaction, used it, otherwise, create it.
* REQUIRES_NEW -> If there is a transaction, suspend it, then create one.
* SUPPORTS -> If there is a transaction, the method will use it, else, no transaction is used.
* NOT_SUPPORTED -> If there is a transaction, suspend it, no new transaction is started.
* MANDATORY -> If there is no transaction, throws an exception, otherwise, uses it.
* NEVER -> If there is a transaction, throws an exception, no new transaction is started.

* @DeclareRoles -> Indicates that the class will accept the declared roles. Class level
* @RolesAllowed -> Indicates that a method can be accessed by the user of the role specified. Method or class level
* @PermitAll -> Indicates that a business method is accessible to all. Method or class level
* @DenyAll -> Indicates that a business method is not accessible to any of the user-specified at class or at method level.

* Enum can implement an interface in Java. Since enum is a type, similar to class and interface, it can implement an interface.
* Overrides the methods of the interface(s) once.

* No, Enum can not extend a class in Java, because already Extends java.lang.Enum.

* Yes, you can create Enum without any instance in Java.

* No, Enum doesn't have any public constructor, and the compiler doesn't allow you to provide any public constructor in Enum.

* Yes, you can only declare either private or package-private constructor inside enum.

* Gives the index of the element within the enum.

* Enum implements the Comparable interface, which is the main requirement to be used in Sorted Collection like TreeSet and TreeMap.