#Java_Interview_Question
141) What is the difference between Set and Map?
Set contains values only whereas Map contains key and values both.
@javaCode☕️
141) What is the difference between Set and Map?
Set contains values only whereas Map contains key and values both.
@javaCode☕️
👍2
#Java_Interview_Question
142) What is the difference between HashSet and HashMap?
HashSet contains only values whereas HashMap contains entry(key,value). HashSet can be iterated but HashMap need to convert into Set to be iterated.
@javaCode☕️
142) What is the difference between HashSet and HashMap?
HashSet contains only values whereas HashMap contains entry(key,value). HashSet can be iterated but HashMap need to convert into Set to be iterated.
@javaCode☕️
#Java_Interview_Question
143) What is the difference between HashMap and TreeMap?
HashMap maintains no order but TreeMap maintains ascending order.
@javaCode☕️
143) What is the difference between HashMap and TreeMap?
HashMap maintains no order but TreeMap maintains ascending order.
@javaCode☕️
#Java_Interview_Question
144) What is the difference between HashMap and Hashtable?
1) HashMap is not synchronized. Hashtable is synchronized.
2) HashMap can contain one null key and multiple null values.
@javaCode☕️
144) What is the difference between HashMap and Hashtable?
1) HashMap is not synchronized. Hashtable is synchronized.
2) HashMap can contain one null key and multiple null values.
@javaCode☕️
👍1
#Java_Interview_Question
145) What is the difference between Collection and Collections?
Collection is an interface whereas Collections is a class.
Collection interface provides normal functionality of data structure to List, Set and Queue.
But, Collections class is to sort and synchronize collection elements.
@javaCode☕️
145) What is the difference between Collection and Collections?
Collection is an interface whereas Collections is a class.
Collection interface provides normal functionality of data structure to List, Set and Queue.
But, Collections class is to sort and synchronize collection elements.
@javaCode☕️
#Java_Interview_Question
👉The rules for #overriding a method are as follows:
* The argument list must exactly match that of the overridden method. If they don't match, you can end up with an overloaded method you didn't intend.
* The return type must be the same as, or a subtype of, the return type declared in the original overridden method in the superclass.
* The access level can't be more restrictive than the overridden method's.
* The access level CAN be less restrictive than that of the overridden method.
* Instance methods can be overridden only if they are inherited by the subclass. A subclass within the same package as the instance's superclass can override any superclass method that is not marked private or final. A subclass in a different package can override only those non-final methods marked pub- lic or protected (since protected methods are inherited by the subclass).
* The overriding method CAN throw any unchecked (runtime) exception, regardless of whether the overridden method declares the exception.
* The overriding method must NOT throw checked exceptions that are new or broader than those declared by the overridden method. For example, a method that declares a FileNotFoundException cannot be overridden by a method that declares a SQLException, Exception, or any other non-runtime exception unless it's a subclass of FileNotFoundException.
* The overriding method can throw narrower or fewer exceptions. Just because an overridden method "takes risks" doesn't mean that the overriding subclass' exception takes the same risks. Bottom line: an overriding method doesn't have to declare any exceptions that it will never throw, regardless of what the overridden method declares.
* You cannot override a method marked final.
* You cannot override a method marked static.
* If a method can't be inherited, you cannot override it. Remember that overriding implies that you're reimplementing a method you inherited!
@javaCode☕️
👉The rules for #overriding a method are as follows:
* The argument list must exactly match that of the overridden method. If they don't match, you can end up with an overloaded method you didn't intend.
* The return type must be the same as, or a subtype of, the return type declared in the original overridden method in the superclass.
* The access level can't be more restrictive than the overridden method's.
* The access level CAN be less restrictive than that of the overridden method.
* Instance methods can be overridden only if they are inherited by the subclass. A subclass within the same package as the instance's superclass can override any superclass method that is not marked private or final. A subclass in a different package can override only those non-final methods marked pub- lic or protected (since protected methods are inherited by the subclass).
* The overriding method CAN throw any unchecked (runtime) exception, regardless of whether the overridden method declares the exception.
* The overriding method must NOT throw checked exceptions that are new or broader than those declared by the overridden method. For example, a method that declares a FileNotFoundException cannot be overridden by a method that declares a SQLException, Exception, or any other non-runtime exception unless it's a subclass of FileNotFoundException.
* The overriding method can throw narrower or fewer exceptions. Just because an overridden method "takes risks" doesn't mean that the overriding subclass' exception takes the same risks. Bottom line: an overriding method doesn't have to declare any exceptions that it will never throw, regardless of what the overridden method declares.
* You cannot override a method marked final.
* You cannot override a method marked static.
* If a method can't be inherited, you cannot override it. Remember that overriding implies that you're reimplementing a method you inherited!
@javaCode☕️
#Java_Interview_Question
👉The rules for #overloading a method are as follows:
■ Overloaded methods MUST change the argument list.
■ Overloaded methods CAN change the return type.
■ Overloaded methods CAN change the access modifier.
■ Overloaded methods CAN declare new or broader checked exceptions.
■ A method can be overloaded in the same class or in a subclass. In other words, if class A defines a doStuff(int i) method, the subclass B could define a doStuff(String s) method without overriding the superclass version that takes an int. So two methods with the same name but in different classes can still be considered overloaded, if the subclass inherits one version of the method and then declares another overloaded version in its class definition.
@javaCode☕️
👉The rules for #overloading a method are as follows:
■ Overloaded methods MUST change the argument list.
■ Overloaded methods CAN change the return type.
■ Overloaded methods CAN change the access modifier.
■ Overloaded methods CAN declare new or broader checked exceptions.
■ A method can be overloaded in the same class or in a subclass. In other words, if class A defines a doStuff(int i) method, the subclass B could define a doStuff(String s) method without overriding the superclass version that takes an int. So two methods with the same name but in different classes can still be considered overloaded, if the subclass inherits one version of the method and then declares another overloaded version in its class definition.
@javaCode☕️
👍2
#Java_Interview_Question
☑️NOTICE:
Which overridden version of the method to call (in other words, from which class in the inheritance tree) is decided at runtime based on object type, but which overloaded version of the method to call is based on the reference type of the argument passed at compile time.
@javaCode☕️
☑️NOTICE:
Which overridden version of the method to call (in other words, from which class in the inheritance tree) is decided at runtime based on object type, but which overloaded version of the method to call is based on the reference type of the argument passed at compile time.
@javaCode☕️
#Java_Interview_Question
👉Rules for #Constructors
■ Constructors can use any access modifier, including private. (A private constructor means only code within the class itself can instantiate an object of that type, so if the private constructor class wants to allow an instance of the class to be used, the class must provide a static method or variable that allows access to an instance created from within the class.)
■ The constructor name must match the name of the class.
■ Constructors must not have a return type.
■ It's legal (but stupid) to have a method with the same name as the class, but that doesn't make it a constructor. If you see a return type, it's a method rather than a constructor. In fact, you could have both a method and a constructor with the same name—the name of the class—in the same class, and that's not a problem for Java. Be careful not to mistake a method for a constructor—be sure to look for a return type.
■ If you don't type a constructor into your class code, a default constructor will be automatically generated by the compiler.
■ The default constructor is ALWAYS a no-arg constructor.
■ If you want a no-arg constructor and you've typed any other constructor(s) into your class code, the compiler won't provide the no-arg constructor (or any other constructor) for you. In other words, if you've typed in a constructor with arguments, you won't have a no-arg constructor unless you type it in yourself!
■ Every constructor has, as its first statement, either a call to an overloaded constructor (this()) or a call to the superclass constructor (super()), although remember that this call can be inserted by the compiler.
■ If you do type in a constructor (as opposed to relying on the compiler-gener- ated default constructor), and you do not type in the call to super() or a call to this(), the compiler will insert a no-arg call to super() for you, as the very first statement in the constructor.
■ A call to super() can be either a no-arg call or can include arguments passed to the super constructor.
■ A no-arg constructor is not necessarily the default (i.e., compiler-supplied) constructor, although the default constructor is always a no-arg constructor. The default constructor is the one the compiler provides! While the default constructor is always a no-arg constructor, you're free to put in your own no- arg constructor.
■ You cannot make a call to an instance method, or access an instance variable, until after the super constructor runs.
■ Only static variables and methods can be accessed as part of the call to super() or this().
■ Abstract classes have constructors, and those constructors are always called when a concrete subclass is instantiated.
■ Interfaces do not have constructors. Interfaces are not part of an object's inheritance tree.
■ The only way a constructor can be invoked is from within another constructor.
@javaCode☕️
👉Rules for #Constructors
■ Constructors can use any access modifier, including private. (A private constructor means only code within the class itself can instantiate an object of that type, so if the private constructor class wants to allow an instance of the class to be used, the class must provide a static method or variable that allows access to an instance created from within the class.)
■ The constructor name must match the name of the class.
■ Constructors must not have a return type.
■ It's legal (but stupid) to have a method with the same name as the class, but that doesn't make it a constructor. If you see a return type, it's a method rather than a constructor. In fact, you could have both a method and a constructor with the same name—the name of the class—in the same class, and that's not a problem for Java. Be careful not to mistake a method for a constructor—be sure to look for a return type.
■ If you don't type a constructor into your class code, a default constructor will be automatically generated by the compiler.
■ The default constructor is ALWAYS a no-arg constructor.
■ If you want a no-arg constructor and you've typed any other constructor(s) into your class code, the compiler won't provide the no-arg constructor (or any other constructor) for you. In other words, if you've typed in a constructor with arguments, you won't have a no-arg constructor unless you type it in yourself!
■ Every constructor has, as its first statement, either a call to an overloaded constructor (this()) or a call to the superclass constructor (super()), although remember that this call can be inserted by the compiler.
■ If you do type in a constructor (as opposed to relying on the compiler-gener- ated default constructor), and you do not type in the call to super() or a call to this(), the compiler will insert a no-arg call to super() for you, as the very first statement in the constructor.
■ A call to super() can be either a no-arg call or can include arguments passed to the super constructor.
■ A no-arg constructor is not necessarily the default (i.e., compiler-supplied) constructor, although the default constructor is always a no-arg constructor. The default constructor is the one the compiler provides! While the default constructor is always a no-arg constructor, you're free to put in your own no- arg constructor.
■ You cannot make a call to an instance method, or access an instance variable, until after the super constructor runs.
■ Only static variables and methods can be accessed as part of the call to super() or this().
■ Abstract classes have constructors, and those constructors are always called when a concrete subclass is instantiated.
■ Interfaces do not have constructors. Interfaces are not part of an object's inheritance tree.
■ The only way a constructor can be invoked is from within another constructor.
@javaCode☕️
Java_Performance_In_Depth_Advice_for_Tuning_and_Programming_Java.pdf
10.1 MB
#Java ☕️
#Book 📚📕
Coding and testing are generally considered separate areas of expertise. In this practical book, Java expert Scott Oaks takes the approach that anyone who works with Java should be adept at understanding how code behaves in the Java Virtual Machine—including the tunings likely to help performance. This updated second edition helps you gain in-depth knowledge of Java application performance using both the JVM and the Java platform.
@javaCode☕️
#Book 📚📕
Coding and testing are generally considered separate areas of expertise. In this practical book, Java expert Scott Oaks takes the approach that anyone who works with Java should be adept at understanding how code behaves in the Java Virtual Machine—including the tunings likely to help performance. This updated second edition helps you gain in-depth knowledge of Java application performance using both the JVM and the Java platform.
@javaCode☕️
👍2
Modern_Java_Recipes_Simple_Solutions_to_Difficult_Problems_in_Java.pdf
2.2 MB
#Book 📚📕
Modern Java Recipes: Simple Solutions to Difficult Problems in #Java ☕️ 8 and 9
Kousen, Ken
The introduction of functional programming concepts in Java SE 8 was a drastic change for this venerable object-oriented language. Lambda expressions, method references, and streams fundamentally changed the idioms of the language, and many developers have been trying to catch up ever since. This cookbook will help. With more than 70 detailed recipes, author Ken Kousen shows you how to use the newest features of Java to solve a wide range of problems.
@javaCode☕️
Modern Java Recipes: Simple Solutions to Difficult Problems in #Java ☕️ 8 and 9
Kousen, Ken
The introduction of functional programming concepts in Java SE 8 was a drastic change for this venerable object-oriented language. Lambda expressions, method references, and streams fundamentally changed the idioms of the language, and many developers have been trying to catch up ever since. This cookbook will help. With more than 70 detailed recipes, author Ken Kousen shows you how to use the newest features of Java to solve a wide range of problems.
@javaCode☕️
👍2
Get Programming with Java by Peggy Fisher.pdf
8.7 MB
#Book 📚📕
Get Programming with #Java ☕️
Peggy Fisher (2019)
Get Programming with Java teaches you to write programs in the Java language, starting from the most basic building blocks. In her relatable and personable style, author Peggy Fisher begins by helping you set up a Java programming environment on your computer. Once you’re up and running, you’ll start working with the foundations of Java and object-oriented programming, including classes and objects. Always practical and clear, this carefully-designed tutorial swaps the usual heavy-handed theory for concrete examples and easy-to-follow scenarios.
@javaCode☕️
Get Programming with #Java ☕️
Peggy Fisher (2019)
Get Programming with Java teaches you to write programs in the Java language, starting from the most basic building blocks. In her relatable and personable style, author Peggy Fisher begins by helping you set up a Java programming environment on your computer. Once you’re up and running, you’ll start working with the foundations of Java and object-oriented programming, including classes and objects. Always practical and clear, this carefully-designed tutorial swaps the usual heavy-handed theory for concrete examples and easy-to-follow scenarios.
@javaCode☕️
👍4
# What is the difference between JVM Heap and Stack Memory? 🧠
Understanding Memory Allocation in Java ☕
The JVM splits memory into two primary regions: Heap and Stack, each serving distinct purposes in application execution. The #Heap is a shared, runtime memory area where all objects and class instances reside. It's allocated at JVM startup and managed by the #GarbageCollector, which handles automatic deallocation of objects that are no longer referenced. The Heap is further divided into generations (Young, Old, Metaspace in modern JVMs), optimizing garbage collection performance.
The #Stack, in contrast, is thread-private and stores method frames, local variables, and primitive values. Each thread gets its own stack, and memory here follows LIFO (Last In, First Out) methodology. Stack memory is faster but limited in size, throwing #StackOverflowError when exhausted. Unlike Heap objects, stack variables cannot be shared between threads, ensuring thread safety for primitive data.
Key Differences at a Glance 🛠️
- Storage Type: #Heap stores objects and arrays; #Stack stores primitives and object references
- Lifetime: Heap objects live until GC collects them; Stack frames exist only during method execution
- Thread Safety: Heap is shared (requires synchronization); Stack is thread-private by design
- Size: Heap is large (configured via -Xmx); Stack is smaller (configured via -Xss)
- Access Speed: Stack is faster (no GC overhead); Heap is slower (managed by GC)
- Error Types: #OutOfMemoryError (Heap); #StackOverflowError (Stack)
When to Use Which? 🏗️
- Use Heap for: Shared data, large objects, database connections, caching
- Use Stack for: Method-local variables, recursion depth control, thread-safe operations
🔗 Reference: JVM Memory Management Documentation
---
📌 Follow for more Java deep dives!
@javaCode☕
#JVM #Java #MemoryManagement #Heap #Stack #GarbageCollection #Programming #SoftwareEngineering #JavaDeveloper #TechKnowledge
Understanding Memory Allocation in Java ☕
The JVM splits memory into two primary regions: Heap and Stack, each serving distinct purposes in application execution. The #Heap is a shared, runtime memory area where all objects and class instances reside. It's allocated at JVM startup and managed by the #GarbageCollector, which handles automatic deallocation of objects that are no longer referenced. The Heap is further divided into generations (Young, Old, Metaspace in modern JVMs), optimizing garbage collection performance.
The #Stack, in contrast, is thread-private and stores method frames, local variables, and primitive values. Each thread gets its own stack, and memory here follows LIFO (Last In, First Out) methodology. Stack memory is faster but limited in size, throwing #StackOverflowError when exhausted. Unlike Heap objects, stack variables cannot be shared between threads, ensuring thread safety for primitive data.
Key Differences at a Glance 🛠️
- Storage Type: #Heap stores objects and arrays; #Stack stores primitives and object references
- Lifetime: Heap objects live until GC collects them; Stack frames exist only during method execution
- Thread Safety: Heap is shared (requires synchronization); Stack is thread-private by design
- Size: Heap is large (configured via -Xmx); Stack is smaller (configured via -Xss)
- Access Speed: Stack is faster (no GC overhead); Heap is slower (managed by GC)
- Error Types: #OutOfMemoryError (Heap); #StackOverflowError (Stack)
When to Use Which? 🏗️
- Use Heap for: Shared data, large objects, database connections, caching
- Use Stack for: Method-local variables, recursion depth control, thread-safe operations
🔗 Reference: JVM Memory Management Documentation
---
📌 Follow for more Java deep dives!
@javaCode☕
#JVM #Java #MemoryManagement #Heap #Stack #GarbageCollection #Programming #SoftwareEngineering #JavaDeveloper #TechKnowledge