Managing Multiple JDK Versions with SDKMAN!

In today’s software development landscape, working with multiple Java Development Kit (JDK) versions is not uncommon. Different projects may require different JDK versions due to compatibility issues, language features, or performance optimizations. Managing these JDK versions manually can be cumbersome and error-prone. That’s where SDKMAN! comes to the rescue! What is SDKMAN!? SDKMAN! is a tool that simplifies managing multiple software development kits (SDKs) on your system. It provides a convenient way to install, manage, and switch between different versions of JDKs, JVMs, build tools, and more. With SDKMAN!, you can effortlessly handle different JDK versions without the hassle of manual installation and configuration. ...

February 23, 2024 · 3 min · Nitin

Java 8 End of Life (EOL)?

Introduction A few days ago, someone asked me has Java 8 reached the end of its life, and should we upgrade to Java 11 or Java 17. If you have the same question, let’s try to understand the situation, and do you need an upgrade or you can wait? You should consider upgrading to a newer version of Java to ensure security, performance, and ongoing support, but Java 8 has a complex End-of-Life (EOL) situation. ...

February 22, 2024 · 3 min · Nitin

SOLID principles

SOLID is an acronym that represents a set of five design principles in object-oriented programming and software design. These principles aim to create more maintainable, flexible, and scalable software by promoting a modular and clean code structure. The SOLID principles were introduced by Robert C. Martin and have become widely adopted in the software development industry. Here’s a brief overview of each principle: Single Responsibility Principle (SRP): A class should have only one reason to change, meaning that it should have only one responsibility or job. This principle encourages the separation of concerns and helps to ensure that a class is focused on doing one thing well. // Before SRP class Report { public void generateReport() { // code for generating the report } public void saveToFile() { // code for saving the report to a file } } // After SRP class Report { public void generateReport() { // code for generating the report } } class ReportSaver { public void saveToFile(Report report) { // code for saving the report to a file } } Open/Closed Principle (OCP): Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. This encourages developers to add new functionality through the creation of new classes or modules rather than altering existing ones. // Before OCP class Rectangle { public double width; public double height; } class AreaCalculator { public double calculateArea(Rectangle rectangle) { return rectangle.width * rectangle.height; } } // After OCP interface Shape { double calculateArea(); } class Rectangle implements Shape { private double width; private double height; // constructor and other methods @Override public double calculateArea() { return width * height; } } class Circle implements Shape { private double radius; // constructor and other methods @Override public double calculateArea() { return Math.PI * radius * radius; } } Liskov Substitution Principle (LSP): Subtypes should be substitutable for their base types without altering the correctness of the program. This principle ensures that objects of a derived class can be used in place of objects of the base class without affecting the program’s functionality. // Before LSP class Bird { public void fly() { // code for flying } } class Ostrich extends Bird { // Ostrich is a bird, but it can't fly } // After LSP interface FlyingBird { void fly(); } class Sparrow implements FlyingBird { @Override public void fly() { // code for flying } } class Ostrich { // Ostrich doesn't implement FlyingBird, as it can't fly } Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they do not use. It advocates for the creation of small, specific interfaces rather than large, general-purpose ones, to avoid clients being forced to implement methods they don’t need. // Before ISP interface Worker { void work(); void eat(); void sleep(); } class Engineer implements Worker { @Override public void work() { // code for working } @Override public void eat() { // code for eating } @Override public void sleep() { // code for sleeping } } // After ISP interface Workable { void work(); } interface Eatable { void eat(); } interface Sleepable { void sleep(); } class Engineer implements Workable, Eatable, Sleepable { @Override public void work() { // code for working } @Override public void eat() { // code for eating } @Override public void sleep() { // code for sleeping } } Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions. This principle promotes the use of abstractions (like interfaces or abstract classes) to decouple high-level and low-level modules, making the system more flexible and easier to change. // Before DIP class LightBulb { public void turnOn() { // code for turning on the light bulb } public void turnOff() { // code for turning off the light bulb } } class Switch { private LightBulb bulb; public Switch(LightBulb bulb) { this.bulb = bulb; } public void operate() { // code for operating the switch if (/* some condition */) { bulb.turnOn(); } else { bulb.turnOff(); } } } // After DIP interface Switchable { void turnOn(); void turnOff(); } class LightBulb implements Switchable { @Override public void turnOn() { // code for turning on the light bulb } @Override public void turnOff() { // code for turning off the light bulb } } class Switch { private Switchable device; public Switch(Switchable device) { this.device = device; } public void operate() { // code for operating the switch if (/* some condition */) { device.turnOn(); } else { device.turnOff(); } } } Adhering to SOLID principles can result in code that is easier to understand, maintain, and extend. These principles contribute to the overall goal of creating robust and scalable software systems.

February 19, 2024 · 4 min · Nitin

A Comprehensive Guide to Java Monitoring and Diagnostics Tools: jps, jstat, jcmd, and jmap

jps (Java Process Status) Usage: Sample Usage: Understanding the Output: jstat (JVM Statistics Monitoring Tool) Usage: Sample Usage: Understanding the Output: jcmd (JVM Diagnostic Command) Usage: Sample Usage: Understanding the Output: jmap (Memory Map for Java) Usage: Sample Usage: Understanding the Output: Conclusion Java applications often run in complex and dynamic environments, making it essential to monitor their performance and diagnose issues efficiently. Fortunately, the Java Development Kit (JDK) comes with a set of powerful tools for this purpose. In this guide, we will explore four essential tools: jps, jstat, jcmd, and jmap. We’ll discuss their functionalities, sample usage, and how to interpret their output effectively. ...

February 19, 2024 · 3 min · Nitin

A Comprehensive Guide to Running Programs in Java with Maven

Introduction Java developers often need to execute programs as part of their development process, whether they are testing, building, or deploying applications. Maven, a popular build automation tool primarily used for Java projects, provides a convenient way to manage dependencies, build, and run Java programs. In this guide, we will explore various methods and best practices for running programs in Java using Maven. Setting Up Maven Before diving into running programs with Maven, it’s essential to ensure that Maven is properly installed on your system. Maven can be downloaded and installed from the official Apache Maven website (https://maven.apache.org/download.cgi). Once installed, make sure to set up the PATH environment variable to include Maven’s bin directory, allowing you to run Maven commands from any location in your terminal or command prompt. ...

February 13, 2024 · 3 min · Nitin