HashMap allows null as a key and so hashcode for this will always be zero , even empty string can be given as a key and it also hols the hash code zero but internally they are stored in different indexes
Concurrent hashmap does not allow null as a key , Hash table also does not allow null key
Some sample example below
Oct 06, 2020 12:39:06 PM MapContainsGet logMapInfo
INFO: HashMap: {NEVADA=Carson City, WASHINGTON=Olympia, NORTH_DAKOTA=Bismark, MONTANA=null, ARIZONA=Phoenix, UTAH=Salt Lake City, OREGON=Salem, COLORADO=Denver, SOUTH_DAKOTA=Pierre, IDAHO=Boise, NEW_MEXICO=Sante Fe, CALIFORNIA=Sacramento, WYOMING=Cheyenne}
Oct 06, 2020 12:39:06 PM MapContainsGet demonstrateGetAndContains
INFO:
Map of type java.util.HashMap returns null for Map.get() using Montana
Map of type java.util.HashMap returns true for Map.containsKey() using Montana
Map of type java.util.HashMap returns null for Map.get() using Kansas
Map of type java.util.HashMap returns false for Map.containsKey() using Kansas
Oct 06, 2020 12:39:06 PM MapContainsGet logMapInfo
INFO: LinkedHashMap: {ARIZONA=Phoenix, CALIFORNIA=Sacramento, COLORADO=Denver, IDAHO=Boise, NEVADA=Carson City, NEW_MEXICO=Sante Fe, NORTH_DAKOTA=Bismark, OREGON=Salem, SOUTH_DAKOTA=Pierre, UTAH=Salt Lake City, WASHINGTON=Olympia, WYOMING=Cheyenne, MONTANA=null}
Oct 06, 2020 12:39:06 PM MapContainsGet demonstrateGetAndContains
INFO:
Map of type java.util.LinkedHashMap returns null for Map.get() using Montana
Map of type java.util.LinkedHashMap returns true for Map.containsKey() using Montana
Map of type java.util.LinkedHashMap returns null for Map.get() using Kansas
Map of type java.util.LinkedHashMap returns false for Map.containsKey() using Kansas
Oct 06, 2020 12:39:06 PM MapContainsGet generateStatesMap
SEVERE: java.util.concurrent.ConcurrentHashMap does not allow for null values - java.lang.NullPointerException
Oct 06, 2020 12:39:06 PM MapContainsGet logMapInfo
INFO: ConcurrentHashMap: {NEVADA=Carson City, WASHINGTON=Olympia, NORTH_DAKOTA=Bismark, ARIZONA=Phoenix, UTAH=Salt Lake City, OREGON=Salem, COLORADO=Denver, SOUTH_DAKOTA=Pierre, IDAHO=Boise, NEW_MEXICO=Sante Fe, CALIFORNIA=Sacramento, WYOMING=Cheyenne}
Oct 06, 2020 12:39:06 PM MapContainsGet demonstrateGetAndContains
INFO:
Map of type java.util.concurrent.ConcurrentHashMap returns null for Map.get() using Montana
Map of type java.util.concurrent.ConcurrentHashMap returns false for Map.containsKey() using Montana
Map of type java.util.concurrent.ConcurrentHashMap returns null for Map.get() using Kansas
Map of type java.util.concurrent.ConcurrentHashMap returns false for Map.containsKey() using Kansas
Oct 06, 2020 12:39:06 PM MapContainsGet logMapInfo
INFO: EnumMap: {ARIZONA=Phoenix, CALIFORNIA=Sacramento, COLORADO=Denver, IDAHO=Boise, MONTANA=null, NEVADA=Carson City, NEW_MEXICO=Sante Fe, NORTH_DAKOTA=Bismark, OREGON=Salem, SOUTH_DAKOTA=Pierre, UTAH=Salt Lake City, WASHINGTON=Olympia, WYOMING=Cheyenne}
Oct 06, 2020 12:39:06 PM MapContainsGet demonstrateGetAndContains
INFO:
Map of type java.util.EnumMap returns null for Map.get() using Montana
Map of type java.util.EnumMap returns true for Map.containsKey() using Montana
Map of type java.util.EnumMap returns null for Map.get() using Kansas
Map of type java.util.EnumMap returns false for Map.containsKey() using Kansas
Best link to read
https://www.devdiaries.net/blog/Java-Recruitment-Questions-HashCode/
Immutable objects are a very important element of application building, which makes applications more legible and consistent, as well as more error-proof. Every developer should know how to use immutable objects and what benefits are associated with their use.
Writing this post I didn’t think about the disadvantages of creating immutable classes. Fortunately, a user potracheno informed about it in the comment. Thanks!
Immutable objects have far more advantages than disadvantages. The only thing that comes to my mind is the cost of memory. With immutability, any time you need to modify data, you need to create a new object. This can be expensive. If you are sure that you will not need immutability (e.g. you are creating a simple single-threaded application) - do not create immutable code.
Advantages of immutable objects
These objects make us avoid accidental changes, often in very inappropriate places. If an object is changeable, there will definitely be someone who wants to change it where it should not.
A good example of such a situation is the object that we pass as a parameter of the method. Such an object can be passed between multiple application layers, between multiple method calls. It can be passed on very deep in the call hierarchy. This makes it very difficult to identify where it was changed. This can lead to many strange and difficult to solve problems.
Using immutable objects we do not have such problems and the design of our application improves.
Invariant objects are also safe for multithreaded use. If an object is not changed, it can be safely transferred between threads without synchronization.
Another advantage is that such objects are ideal as key objects in maps. In a situation where keys are variable, after changing the key object its hashcode changes, making it impossible to find the stored value in HashMap.
How to create immutable objects?
Such objects can be created in three ways. Through the constructor and that is the easiest way. But it has a fundamental disadvantage. The more fields to initiate, the more parameters in the constructor. That’s why you shouldn’t create objects that have more than 2-3 fields.
public final class Animal {
private final String name;
private final String ownerName;
public Animal(String name, String ownerName) {
this.name = name;
this.ownerName = ownerName;
}
public String getName() {
return name;
}
public String getOwnerName() {
return ownerName;
}
}
// Creation
Animal animal = new Animal("Tina", "John");Another way is the factory method. As with the constructor, the more fields, the more parameters. But this approach has such an advantage that we can create several such methods with a different names, with different set of parameters, which improves readability.
A third way to create immutable objects is to use the builder pattern. In order to use the builder, it must be implemented inside the class so that it has access to private class fields.
public final class User {
private int age;
private String firstName;
private String lastName;
public static Builder builder() {
return new Builder();
}
public static class Builder {
private User user = new User();
public Builder firstName(String firstName) {
user.firstName = firstName;
return this;
}
public Builder lastName(String lastName) {
user.lastName = lastName;
return this;
}
public Builder age(int age) {
user.age = age;
return this;
}
public User build(){
return user;
}
}
// Creation
User user = User.builder()
.firstName("John")
.lastName("People")
.age(45)
.build();We can write such a builder manually or use some kind of IDE plugin to generate it for us. Another option is to use Lombok and @Builder annotation.
What is an immutable object?
An immutable object is one which, after being created and initialized, remains unchanged and, importantly, cannot be changed (in a conventional way, of course). This means that such an object does not provide methods that allow changing its state. And all its fields are private (or public final).
This changeability is a little apparent, because, using reflection, you can change the field values in each class. However, this does not mean that for this reason, we should give up immutable objects.
How to ensure the object’s immutability?
Apart from the fact that all fields should be private, they should be final. And the class itself should be marked as final so that it cannot be inherited. Such an object should not provide methods to modify its internal state, e.g. setters.
But private, final fields are not everything. It is important what types of data we store in these fields. It should also be unchangeable! If the fields in your object are primitives, primitive wrappers or Strings then there is no problem. All these types are immutable. But if you use your own objects, you must ensure that they are unchangeable.
https://www.devdiaries.net/blog/Java-Recruitment-Questions-Immutable-Objects/
Strategy defines a family of interchangeable algorithms (in the form of classes) that are used to solve the same problem in several different ways.
Number converter with the strategy pattern
Imagine that you want to create a system to convert numbers into different Numeral Systems .
As in the previous example, we will start with the interface:
public interface ConvertingStrategy {
String convert(int number);
} Time for implementation. We will add support to convert number to octal, binary and hex system:
public class BinaryConverter implements ConvertingStrategy {
public String convert(int number) {
return Integer.toBinaryString(number);
}
}
public class HexaConverter implements ConvertingStrategy {
public String convert(int number) {
return Integer.toHexString(number);
}
}
public class OctaConverter implements ConvertingStrategy {
public String convert(int number) {
return Integer.toOctalString(number);
}
} According to the diagram at the beginning of the post - we will create a class Context that will use our strategies:
public class Context {
private ConvertingStrategy strategy;
public Context(ConvertingStrategy strategy) {
this.strategy = strategy;
}
public String convert(int number) {
return strategy.convert(number);
}
}An example of how to use a strategy to convert:
public class Main {
public static void main(String[] args) {
Context ctx = new Context(new HexaConverter());
System.out.println(ctx.convert(1000));
// Result: 3e8
// If you change HexaConverter to BinaryConverter, the result will be: 1111101000
}
}
https://www.devdiaries.net/blog/Java-Strategy-Design-Pattern-By-Examples/
https://www.devdiaries.net/blog/Java-Interview-Questions-Multithreading/
https://www.devdiaries.net/blog/10-Object-oriented-design-principles-everythone-should-know/
Best Practises while using Collections----------------------------------------Always use interface type as a reference type.
Always use interface type as a return type
Always use Interface Types as a method argument
Use generic type and diamond operator
You can declare a collection of a generic type like this:List<Employee> listEmployees = new ArrayList<Employee>();
Since Java 7, the compiler can infer the generic type on the right side from the generic type declared on the left side, so you can write:List<Employee> listEmployees = new ArrayList<>();
Prefer isEmpty() over a size()
Return empty collections or arrays, not nulls
Do not use the classic for loop.Use ForEach Loop which uses iterator behind the screen
Overriding equals() and hashCode() properly
Using Arrays and Collections utility classes
Prefer concurrent collections over synchronized wrappers
When you have to use collections in multi-threaded applications, consider using concurrent collections in the java.util.concurrent package instead of using the synchronized collections generated by the Collections.synchronizedXXX() methods.
It’s because the concurrent collections are designed to provide maximum performance in concurrent applications, by implementing different synchronization mechanisms like copy-on-write, compare-and-swap, and special locks. The following list shows you how to choose some concurrent collections (on the right) which are equivalent to the normal ones (on the left):
- HashMap -> ConcurrentHashMap
- ArrayList -> CopyOnWriteArrayList
- TreeMap -> ConcurrentSkipListMap
- PriorityQueue -> PriorityBlockingQueue
No comments:
Post a Comment