You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Java, the String class is **immutable**, meaning once a String object is created, its value cannot be changed. If you try to modify it (for example, by concatenating text), Java creates a new String object instead of altering the original one. Due to this behavior, the internal state of a string remains the same throughout the execution of the program.
281
282
282
-
Strings are immutable, that means the contents of string objects can't be modified after their creation. i.e, When you try to alter the string, it creates a new string. Due to this behavior, the internal state of a string remains the same throughout the execution of the program. This characteristic of immutability helps with the benefits of caching, security, synchronization, and performance.
283
+
One major reason for this is **security**. Strings are used for sensitive data like file paths, database URLs, and class names. If strings were mutable, their values could be changed after validation, leading to security risks. Immutability ensures the value remains safe once created.
284
+
285
+
Another reason is the **String Constant Pool**, where identical string literals share the same memory. This saves memory and improves performance. Since strings are immutable, multiple references can safely point to the same object without affecting each other.
286
+
287
+
Immutability also provides **thread safety**. Multiple threads can use the same String object without synchronization because its value cannot change. Additionally, strings are commonly used as keys in hash-based collections, and immutability ensures their hash codes remain consistent.
288
+
289
+
In summary, String is immutable in Java for security, memory efficiency, thread safety, and reliable behavior in collections.
**2. hashCode:** The `hashCode()` method returns the integer hash code value of the object. This method must be overridden in every class which overrides `equals()` method. The general contract of hashCode is:
320
327
321
-
1. While execution of the application, the multiple invocations of `hashCode()` on the object should return the same integer value, unless the object property used in the `equals()` method is being modified.
322
-
2. During the multiple executions of the application, the object's hashCode can change.
323
-
3. If two objects are equal based on `equals()` method, then their object's hash code must be same.
324
-
4. If two objects are unequal based on `equals()` method, their hash code value may or may not be equal.
328
+
5. While execution of the application, the multiple invocations of `hashCode()` on the object should return the same integer value, unless the object property used in the `equals()` method is being modified.
329
+
6. During the multiple executions of the application, the object's hashCode can change.
330
+
7. If two objects are equal based on `equals()` method, then their object's hash code must be same.
331
+
8. If two objects are unequal based on `equals()` method, their hash code value may or may not be equal.
325
332
326
333
Together, the implementation of `equals()` and `hashCode()` should follow these rules.
327
334
328
-
1. If `x.equals(y)` is true, then `x.hashCode() === y.hashCode()` should always be true.
329
-
2. If `x.hashCode() === y.hashCode()` is true, then it doesn't required to be `x.equals(y)` always true.
335
+
9. If `x.equals(y)` is true, then `x.hashCode() === y.hashCode()` should always be true.
336
+
10. If `x.hashCode() === y.hashCode()` is true, then it doesn't required to be `x.equals(y)` always true.
For example, the following method doesn't have any errors during compile time. But it will throw `ArithmeticException` during runtime because of division by zero.
There are also alternatives for marker interfaces.
538
545
539
-
1.**Internal flags:** They can be used in place of marker interfaceto indicate any specific operation.
540
-
2. **Annotations:** They are used as tags to represent the metadata attached to classes, interfaces, or methods to indicate additional information required by JVM.
546
+
4.**Internal flags:** They can be used in place of marker interfaceto indicate any specific operation.
547
+
5. **Annotations:** They are used as tags to represent the metadata attached to classes, interfaces, or methods to indicate additional information required by JVM.
0 commit comments