|
83 | 83 | ```
|
84 | 84 |
|
85 | 85 | ##String vs StringBuffer vs StringBuilder
|
86 |
| -- String is Immutable |
87 |
| -- StringBuilder is not synchronized |
88 |
| -- Performance |
| 86 | +- Immutability : String |
| 87 | +- Thread Safety : String(immutable), StringBuffer |
| 88 | +- Performance : StringBuilder (especially when a number of modifications are made.) |
89 | 89 | - [Example 1](src/main/java/com/in28minutes/java/string/StringBufferBuilderExamples.java)
|
90 | 90 |
|
91 | 91 | #OOPS Basics
|
|
94 | 94 | - Every Class Extends Object - See [Example](src/main/java/com/in28minutes/java/oops/inheritance/EveryClassExtendsObject.java)
|
95 | 95 | - [Example 1](src/main/java/com/in28minutes/java/oops/inheritance/InheritanceExamples.java)
|
96 | 96 | - Reuse Through Inheritance - [TestReuse.java](src/main/java/com/in28minutes/java/oops/inheritance/reuse/TestReuse.java) [Hero.java](src/main/java/com/in28minutes/java/oops/inheritance/reuse/Hero.java) [Actor.java](src/main/java/com/in28minutes/java/oops/inheritance/reuse/Actor.java) [Comedian.java](src/main/java/com/in28minutes/java/oops/inheritance/reuse/Comedian.java)
|
| 97 | +- Example in Java Api : HashMap & TreeMap extend AbstractMap. |
97 | 98 |
|
98 | 99 | ##Method Overloading
|
99 |
| -- [Example](src/main/java/com/in28minutes/java/oops/inheritance/overloading/OverloadingRules.java) |
| 100 | +- Java Example |
| 101 | + - Constructors |
| 102 | + - public HashMap(int initialCapacity, float loadFactor) |
| 103 | + - public HashMap() { |
| 104 | + - public HashMap(int initialCapacity) |
| 105 | + - Methods |
| 106 | + - public boolean addAll(Collection<? extends E> c) |
| 107 | + - public boolean addAll(int index, Collection<? extends E> c) |
| 108 | +- [Rules](src/main/java/com/in28minutes/java/oops/inheritance/overloading/OverloadingRules.java) |
100 | 109 |
|
101 | 110 | ##Method Overriding
|
| 111 | +- Java Example |
| 112 | + - HashMap public int size() overrides AbstractMap public int size() |
102 | 113 | - [Example](src/main/java/com/in28minutes/java/oops/inheritance/overriding/OverridingRules.java)
|
103 | 114 |
|
104 | 115 | ##Interface
|
105 | 116 | - An interface is a contract: the guy writing the interface says, "hey, I accept things looking that way"
|
106 | 117 | - Interface represents common actions between Multiple Classes.
|
107 | 118 | - Basic Example : [Flyable](src/main/java/com/in28minutes/java/oops/interfaces/Flyable.java)
|
108 | 119 | [Aeropane](src/main/java/com/in28minutes/java/oops/interfaces/Aeroplane.java) [Bird](src/main/java/com/in28minutes/java/oops/interfaces/Bird.java)
|
| 120 | +- Example in Java api : Map interface, Collection interface. |
109 | 121 | - Rules and Examples : [Rules](src/main/java/com/in28minutes/java/oops/interfaces/IntefaceRules.java) [More Examples](src/main/java/com/in28minutes/java/oops/interfaces/InterfaceExamples.java)
|
110 | 122 |
|
111 | 123 | ##Java and Multiple Inheritance
|
|
117 | 129 | - Abstract Class uses Inheritance and hence is an implementation of IS-A relationship between classes.
|
118 | 130 | - If you want to provide common, implemented functionality among all implementations of your component, use an abstract class. Abstract classes allow you to partially implement your class.
|
119 | 131 | - Example - Animal, Cat, Dog
|
120 |
| -- An example of an abstract class in the JDK is AbstractMap, which is part of the Collections Framework. Its subclasses (which include HashMap, TreeMap, and ConcurrentHashMap) share many methods (including get, put, isEmpty, containsKey, and containsValue) that AbstractMap defines. |
| 132 | +- An example of an abstract class in the JDK is AbstractMap, which is part of the Collections Framework. Its subclasses (which include HashMap, TreeMap, and ConcurrentHashMap) share many methods (including get, put, isEmpty, containsKey, and containsValue) that AbstractMap defines. |
| 133 | + - example abstract method : public abstract Set<Entry<K,V>> entrySet(); |
121 | 134 | - [Another Example - Spring AbstractController] (https://github.com/spring-projects/spring-framework/blob/master/spring-webmvc/src/main/java/org/springframework/web/servlet/mvc/AbstractController.java)
|
122 | 135 | - [More Details](docs/abstract-class.md)
|
123 | 136 |
|
124 | 137 | ##Abstract Class vs Interface
|
125 | 138 | - Real Difference - Apple vs Orange
|
126 |
| -- Syntactical Differences For a Dumb Interviewer |
| 139 | +- Syntactical Differences |
127 | 140 | - Methods and members of an abstract class can have any visibility. All methods of an interface must be public.
|
128 | 141 | - A concrete child class of an Abstract Class must define all the abstract methods. An Abstract child class can have abstract methods. An interface extending another interface need not provide default implementation for methods inherited from the parent interface.
|
129 | 142 | - A child class can only extend a single class. An interface can extend multiple interfaces. A class can implement multiple interfaces.
|
|
134 | 147 |
|
135 | 148 | ##Abstraction
|
136 | 149 | - Base of all programming
|
| 150 | +- Example: |
| 151 | + - Consider simple statement : a = b + c; |
| 152 | + - Add two values stored in two memory locations and store it into a third memory location. |
| 153 | + - Actual operation involves registers, instruction sets, program counters etc. High level language we use abstracts those complex details. |
137 | 154 |
|
138 | 155 | ##Encapsulation
|
139 | 156 | - [Example](src/main/java/com/in28minutes/java/oops/encapsulation/EncapsulationExample.java)
|
|
146 | 163 |
|
147 | 164 | ##Final Modifier
|
148 | 165 | - [Final Class](src/main/java/com/in28minutes/java/classmodifiers/nonaccess/finalclass/FinalClass.java)
|
| 166 | +- Final Class examples : String, Integer, Double and other wrapper classes |
149 | 167 | - [Final Member Variable](src/main/java/com/in28minutes/java/membermodifiers/nonaccess/FinalMemberModifiersExample.java)
|
| 168 | +- Final Variable example : java.lang.Math.PI |
| 169 | +- Final Method example : java.lang.Math.PI |
150 | 170 |
|
151 | 171 | ##Member Access Modifiers
|
152 | 172 | - [Examples](src/main/java/com/in28minutes/java/membermodifiers/access)
|
153 | 173 |
|
154 | 174 | ##Class Access Modifiers
|
155 | 175 | - [Examples](src/main/java/com/in28minutes/java/classmodifiers/)
|
156 |
| -- TODO - A few classes missing here????????????????? |
| 176 | +- public - Accessible from everywhere. |
| 177 | +- private and protected cannot be used on a class. |
157 | 178 |
|
158 | 179 | ##Static Modifier
|
159 | 180 | - [Example](src/main/java/com/in28minutes/java/membermodifiers/nonaccess/StaticModifierExamples.java)
|
| 181 | +- Examples in Java Api : Methods in Math class. |
160 | 182 |
|
161 | 183 | #Constructors
|
162 | 184 |
|
163 | 185 | ##Constructors
|
164 | 186 | - [Example](src/main/java/com/in28minutes/java/object/constructors/ConstructorExamples.java)
|
| 187 | +- Examples in Java Api : HashMap has 2 constructors |
165 | 188 |
|
166 | 189 | ##Static Initializers
|
167 | 190 | - [Example](src/main/java/com/in28minutes/java/initializers/InitializerExamples.java)
|
168 | 191 |
|
169 | 192 | #Collections
|
170 | 193 |
|
171 | 194 | ##Why do we need Collections?
|
172 |
| -- Arrays are static in Size. |
| 195 | +- Arrays are not resizable. |
| 196 | +- Java Collections Framework allows you to use the right data structure, because one size does not fit all. |
| 197 | +- Java Collections Framework provides the correct abstractions, List, Map, Set |
173 | 198 |
|
174 | 199 | ##Hierarchy of Collection Interface?
|
175 | 200 | - [Hierarchy](src/main/java/com/in28minutes/java/collections/CollectionHierarchy.java)
|
|
202 | 227 | - [All Collections Examples](src/main/java/com/in28minutes/java/collections/examples/CollectionExamples.java)
|
203 | 228 |
|
204 | 229 | ##Concurrency in Collections
|
205 |
| -- TODO - More Code Examples |
206 | 230 | - Synchronized collections are implemented using synchronized methods and synchronized blocks. Only one thread can executing any of the synchronized code at a given point in time. This places severe restrictions on the concurrency of threads – thereby affecting performance of the application. All the pre Java 5 synchronized collections (HashTable & Vector, for example) use this approach. Post Java 5, collections using new approaches to synchronization are available in Java. These are called concurrent collections. More details below.
|
| 231 | +- When many threads are expected to access a given collection, a ConcurrentHashMap is normally preferable to a synchronized HashMap, and a ConcurrentSkipListMap is normally preferable to a synchronized TreeMap. A CopyOnWriteArrayList is preferable to a synchronized ArrayList when the expected number of reads and traversals greatly outnumber the number of updates to a list. |
207 | 232 | - Copy on Write
|
208 | 233 | - All values in collection are stored in an internal immutable (not-changeable) array. A new array is created if there is any modification to the collection.
|
209 | 234 | - Read operations are not synchronized. Only write operations are synchronized.
|
210 | 235 | - Copy on Write approach is used in scenarios where reads greatly out number write’s on a collection. CopyOnWriteArrayList & CopyOnWriteArraySet are implementations of this approach. Copy on Write collections are typically used in Subject – Observer scenarios, where the observers very rarely change. Most frequent operations would be iterating around the observers and notifying them.
|
211 |
| -- Compare and Swap |
212 |
| - - Compare and Swap is one of the new approaches (Java 5) introduced in java to handle synchronization. In traditional approach, a method which modifies a member variable used by multiple threads is completely synchronized – to prevent other threads accessing stale value. |
213 |
| - - In compare and swap approach, instead of synchronizing entire method, the value of the member variable before calculation is cached. After the calculation, the cached value is compared with the current value of member variable. If the value is not modified, the calculated result is stored into the member variable. If another thread has modified the value, then the calculation can be performed again. Or skipped – as the need might be. |
214 |
| - - ConcurrentLinkedQueue uses this approach. |
| 236 | + - Example : CopyOnWriteArrayList : public boolean add(E e) |
215 | 237 | - Locks
|
| 238 | + - CopyOnWriteArrayList : final ReentrantLock lock = this.lock; |
216 | 239 | - When 10 methods are declared as synchronized, only one of them is executed by any of the threads at any point in time. This has severe performance impact.
|
217 | 240 | - Another new approach introduced in Java 5 is to use lock and unlock methods. Lock and unlock methods are used to divide methods into different blocks and help enhance concurrency. The 10 methods can be divided into different blocks, which can be synchronized based on different variables.
|
218 | 241 |
|
219 |
| -##Fail Safe vs Fail Fast |
220 |
| -- TODO - Code Examples |
221 |
| -- Fail Fast Iterators throw a ConcurrentModificationException if there is a modification to the underlying collection is modified. This was the default behavior of the synchronized collections of pre Java 5 age. |
222 |
| -- Fail Safe Iterators do not throw exceptions even when there are changes in the collection. This is the default behavior of the concurrent collections, introduced since Java 5. |
| 242 | +##Concurrent Modification & Fail Safe vs Fail Fast |
| 243 | +- Concurrent Modification : Changes made to collection when one or more threads are iterating over it. |
| 244 | +- Fail Fast : Throws Concurrent Modification Exception if there are Concurrent Modifications |
| 245 | +- Fail Safe : Fail Safe Iterator makes copy of the internal data structure (object array) and iterates over the copied data structure. |
| 246 | +- Fail Safe is efficient when traversal operations vastly outnumber mutations |
| 247 | +- [FailFast](src/main/java/com/in28minutes/java/collections/FailFast.java) |
| 248 | +- [FailSafe](src/main/java/com/in28minutes/java/collections/FailSafe.java) |
223 | 249 |
|
224 | 250 | ##Atomic Operations
|
225 | 251 | - Atomic Access Java Tutorial states “In programming, an atomic action is one that effectively happens all at once. An atomic action cannot stop in the middle: it either happens completely, or it doesn't happen at all. No side effects of an atomic action are visible until the action is complete”.
|
|
250 | 276 | ## New Exception Handling Features
|
251 | 277 | - TODO - Code Examples
|
252 | 278 |
|
253 |
| -## Puzzles on Exception Handling |
254 |
| -- TODO |
255 |
| - |
256 | 279 | ## Hierarchy of Exception Related Classes
|
257 | 280 | - [Example 1](src/main/java/com/in28minutes/java/exceptionhandling/ExceptionHandlingExample1.java)
|
258 | 281 | - [Example 2](src/main/java/com/in28minutes/java/exceptionhandling/ExceptionHandlingExample2.java)
|
@@ -378,6 +401,10 @@ obj2.hashCode(). Two unequal objects MIGHT have the same hashCode.
|
378 | 401 | ##Lambda Expressions
|
379 | 402 | - TODO
|
380 | 403 |
|
| 404 | +## 20 Puzzles to Test Yourselves |
| 405 | +- TODO |
| 406 | + |
| 407 | + |
381 | 408 | #Others
|
382 | 409 | - [Basics of Objects and Classes](docs/basics-class-object.md)
|
383 | 410 | - [Arrays](docs/arrays.md)
|
|
0 commit comments