DEV Community: Md. Rakibul Hasan

Encrypting Sensitive Data in Spring Boot: AES-256-GCM Explained with a Real-World Example

Md. Rakibul Hasan — Wed, 28 Oct 2026 17:45:21 +0000

When building an insurance application, we often store sensitive information such as a driver's date of birth (DOB), driver's license number, phone number, and other personally identifiable information (PII).

But what happens if someone gets access to our database?

Database authentication and access control are important, but they do not necessarily protect data from someone who obtains a database dump or gains unauthorized direct database access.

One way to add another layer of protection is application-level encryption.

In this article, we'll explore how AES-256-GCM works, how encryption keys are managed, and how to implement field-level encryption in a Spring Boot application.

1. The Problem: Storing Sensitive Data in Plaintext

Imagine our insurance application stores driver information in PostgreSQL.

A database record might look like this:

id	date_of_birth	driver_license
101	2000-05-15	D1234567

The application can read this information directly from the database. Unfortunately, anyone who obtains an unauthorized copy of the database can read it too.

We could hash these values, but hashing is a one-way operation. We need to recover a driver's original date of birth when calculating age or performing underwriting checks.

Therefore, we need encryption, not ordinary hashing.

2. Encryption vs. Hashing

These two concepts serve different purposes.

Encryption transforms readable data into ciphertext using a key. The original data can be recovered using the appropriate decryption key.

Hashing transforms data into a fixed-length digest. A cryptographic hash is designed to be one-way, so the original input cannot practically be recovered from the hash.

For our insurance application:

DOB: Use encryption because the application may need the original value.
Driver's license number: Use encryption if the original value must be recovered.
Passwords: Use a dedicated password-hashing algorithm such as Argon2id, not reversible encryption.

Now let's look at how encryption works.

3. How AES-256-GCM Works

AES stands for Advanced Encryption Standard. It is a symmetric encryption algorithm, meaning the same secret key is used for encryption and decryption.

AES-256 uses a 256-bit key, which is 32 bytes long.

GCM stands for Galois/Counter Mode. It is an authenticated encryption mode that provides two important security properties:

Confidentiality: Unauthorized readers cannot recover the plaintext without the key.
Integrity and authenticity: Modifications to the ciphertext are detected during decryption.

Let's walk through the process.

Step 1: Start with plaintext

Suppose the user enters the following information:

DOB: 2000-05-15
Driver's License: D1234567

This is plaintext: the original, readable information.

Step 2: Generate a random IV

Before encrypting the data, the application generates a random 12-byte initialization vector (IV).

An IV is a value used by the encryption algorithm to ensure that encrypting the same plaintext with the same key does not normally produce the same ciphertext.

For example, encrypting the same license number twice should produce different encrypted outputs.

The IV is not a secret. It can be stored alongside the ciphertext.

However, with AES-GCM, an IV must never be reused with the same encryption key.

Step 3: Encrypt the plaintext

The application passes three things to the encryption algorithm:

The plaintext.
The secret AES-256 key.
The randomly generated IV.

AES-GCM produces ciphertext and an authentication tag.

Conceptually:

Plaintext + Secret Key + Random IV
                  |
                  v
             AES-256-GCM
                  |
                  v
       Ciphertext + Authentication Tag

The authentication tag allows the application to detect tampering when decrypting the data.

Step 4: Store the encrypted result

The application stores the IV, ciphertext, and authentication tag together, usually encoded as Base64 for convenient database storage.

The database might now contain:

id	dob_encrypted	license_encrypted
101	Base64-encoded ciphertext	Base64-encoded ciphertext

The values shown here are illustrative; actual encrypted values are longer and look like opaque encoded strings.

Base64 is not encryption. It is only an encoding format for storing binary data in a text column.

The security comes from AES-GCM and proper key management, not from Base64.

4. Where Should the Encryption Key Be Stored?

This is one of the most important parts of the design.

Suppose we encrypt every driver's DOB and license number but store the encryption key in the same database.

An attacker who obtains both the database records and the key can decrypt the data.

That defeats much of the intended protection.

Instead, keep the key separate from the database.

For example:

                 Spring Boot
                      |
          +-----------+-----------+
          |                       |
          v                       v
    PostgreSQL              Key Management
    Encrypted data           Secret key

For a small deployment, a protected environment variable can be a starting point. In a production environment, a managed Key Management Service (KMS) or secrets-management system provides stronger separation and additional operational controls.

The encryption key should never be committed to Git, embedded in the Docker image, or printed in application logs.

You must also maintain secure backups of the key. If the key is permanently lost, the corresponding encrypted data may become unrecoverable.

5. Implementing Encryption in Spring Boot

Java provides cryptographic APIs through the Java Cryptography Architecture (JCA), so we do not need an external library just to use AES-GCM.

First, generate a random 256-bit key in a trusted environment:

openssl rand -base64 32

Store the generated value securely and expose it to Spring Boot through your deployment's secret configuration.

In application.yml:

app:
  encryption:
    key: ${QUOTE_ENCRYPTION_KEY}

Next, create a service responsible for encryption and decryption.

@Service
public class FieldEncryptionService {

    private static final String TRANSFORMATION =
            "AES/GCM/NoPadding";

    private static final int IV_LENGTH = 12;
    private static final int TAG_LENGTH = 128;

    private final SecretKey key;
    private final SecureRandom secureRandom =
            new SecureRandom();

    public FieldEncryptionService(
            @Value("${app.encryption.key}") String base64Key) {

        byte[] keyBytes =
                Base64.getDecoder().decode(base64Key);

        if (keyBytes.length != 32) {
            throw new IllegalArgumentException(
                    "AES-256 requires a 32-byte key");
        }

        this.key = new SecretKeySpec(keyBytes, "AES");
    }

    public String encrypt(String plaintext) {
        if (plaintext == null) {
            return null;
        }

        try {
            byte[] iv = new byte[IV_LENGTH];
            secureRandom.nextBytes(iv);

            Cipher cipher =
                    Cipher.getInstance(TRANSFORMATION);

            cipher.init(
                    Cipher.ENCRYPT_MODE,
                    key,
                    new GCMParameterSpec(TAG_LENGTH, iv)
            );

            byte[] ciphertext = cipher.doFinal(
                    plaintext.getBytes(StandardCharsets.UTF_8)
            );

            ByteBuffer buffer = ByteBuffer.allocate(
                    iv.length + ciphertext.length
            );

            buffer.put(iv);
            buffer.put(ciphertext);

            return Base64.getEncoder()
                    .encodeToString(buffer.array());

        } catch (GeneralSecurityException e) {
            throw new IllegalStateException(
                    "Encryption failed", e);
        }
    }

    public String decrypt(String encryptedValue) {
        if (encryptedValue == null) {
            return null;
        }

        try {
            byte[] combined = Base64.getDecoder()
                    .decode(encryptedValue);

            if (combined.length <= IV_LENGTH + TAG_LENGTH / 8) {
                throw new IllegalArgumentException(
                        "Invalid encrypted payload");
            }

            ByteBuffer buffer = ByteBuffer.wrap(combined);

            byte[] iv = new byte[IV_LENGTH];
            buffer.get(iv);

            byte[] ciphertext = new byte[buffer.remaining()];
            buffer.get(ciphertext);

            Cipher cipher =
                    Cipher.getInstance(TRANSFORMATION);

            cipher.init(
                    Cipher.DECRYPT_MODE,
                    key,
                    new GCMParameterSpec(TAG_LENGTH, iv)
            );

            byte[] plaintext = cipher.doFinal(ciphertext);

            return new String(
                    plaintext,
                    StandardCharsets.UTF_8
            );

        } catch (GeneralSecurityException e) {
            throw new IllegalStateException(
                    "Decryption failed", e);
        }
    }
}

The imports are omitted for readability. They include the relevant javax.crypto, java.security, java.nio, java.nio.charset, and java.util classes.

Notice that the IV is stored together with the ciphertext. During decryption, the application extracts the IV, reconstructs the GCM parameters, and verifies the authentication tag as part of doFinal().

If the ciphertext or authentication tag has been modified, decryption fails instead of returning unauthenticated plaintext.

In a production implementation, malformed Base64, authentication failures, and other decryption errors should be handled safely without exposing sensitive information in logs or API responses.

6. Encrypt the Data Before Saving It

Now let's connect encryption to our insurance quote workflow.

Suppose our database entity stores encrypted values as strings:

@Entity
@Table(name = "quote_driver")
public class QuoteDriver {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(name = "dob_encrypted")
    private String dobEncrypted;

    @Column(name = "license_encrypted")
    private String licenseEncrypted;

    // Other fields, constructors, and accessors
}

When a quote is submitted, the service encrypts the values before persistence.

public QuoteDriver saveDriver(
        LocalDate dob,
        String licenseNumber) {

    QuoteDriver driver = new QuoteDriver();

    driver.setDobEncrypted(
            encryptionService.encrypt(dob.toString())
    );

    driver.setLicenseEncrypted(
            encryptionService.encrypt(licenseNumber)
    );

    return quoteDriverRepository.save(driver);
}

The flow becomes:

Angular Form
     |
     v
Spring Boot API
     |
     v
Validate Input
     |
     v
Encrypt Sensitive Fields
     |
     v
Save to PostgreSQL

The browser does not need to encrypt these fields with the server's encryption key. The server performs encryption inside its trusted application boundary after receiving the request over HTTPS.

When an authorized operation needs the original DOB, the service decrypts it and converts it back to a LocalDate.

LocalDate dob = LocalDate.parse(
        encryptionService.decrypt(
                driver.getDobEncrypted()
        )
);

The same approach applies to the driver's license number.

Keep decrypted values inside the business-service boundary where possible. Do not automatically expose them in API responses simply because they have been decrypted.

7. What Happens When We Need to Validate a Driver's Age?

This is an important consideration for insurance systems.

Suppose the business rule requires drivers to be at least 18 years old.

Because DOB is encrypted in the database, we cannot directly perform ordinary date comparisons against that ciphertext.

Instead, the application retrieves the encrypted value, decrypts it in the authorized service, and performs the validation:

LocalDate dob = LocalDate.parse(
        encryptionService.decrypt(
                driver.getDobEncrypted()
        )
);

int age = Period.between(
        dob,
        LocalDate.now()
).getYears();

if (age < 18) {
    throw new IllegalArgumentException(
            "Driver must be at least 18 years old");
}

The example demonstrates the flow; production validation should use the application's agreed business rules, clock and timezone.

Encryption does not remove the need for normal validation. It changes how sensitive information is stored and accessed.

If the application needs frequent age checks, carefully evaluate whether the original DOB must be retrieved each time or whether an appropriate derived value can meet the requirement. Any derived field should be designed to avoid introducing unnecessary privacy risks.

8. Can We Search Encrypted Data?

Randomized AES-GCM encryption creates a challenge for database queries.

Consider the same license number encrypted twice:

D1234567 -> Ciphertext A
D1234567 -> Ciphertext B

The ciphertexts differ because the IVs differ.

Consequently, a normal SQL query cannot find a license number by comparing the plaintext against the encrypted column.

If exact matching is necessary, a separate keyed HMAC-SHA-256 lookup value can be stored alongside the encrypted license number. The HMAC key must be independent of the encryption key.

The application can calculate the HMAC for a search request and compare it with the stored lookup value without decrypting every record.

This design requires careful handling of key rotation, normalization and access control. HMAC lookup values also reveal equality: records with the same normalized input produce the same lookup value under the same key.

Do not add searchable derived fields unless the business actually requires them.

9. Common Mistakes to Avoid

1. Hardcoding the encryption key

Never commit a real key to Git or embed it in source code.

2. Reusing the IV

Generate a fresh, cryptographically random IV for every encryption under the same AES-GCM key.

3. Assuming Base64 is encryption

Base64 can be decoded by anyone. It does not provide confidentiality.

4. Logging plaintext

Application logs, exception messages, debugging statements and monitoring systems can inadvertently expose sensitive information.

5. Forgetting key rotation

Encryption keys have a lifecycle. Store a key version with encrypted data or use a versioned ciphertext format so the application can identify which key is required for decryption.

6. Ignoring existing database records

Adding encryption to a new entity does not automatically encrypt previously stored plaintext. Existing records need a controlled migration, verification and removal of the original plaintext values.

7. Decrypting everything unnecessarily

Decrypt sensitive data only when an authorized operation needs it. Apply role-based access controls and audit access to sensitive fields.

10. Is Application-Level Encryption Enough?

Application-level encryption is one layer of a broader security strategy.

For a production insurance application, consider combining:

HTTPS/TLS for data in transit.
AES-256-GCM for sensitive fields at the application layer.
A managed KMS or vault for encryption-key management.
Database access controls and encryption at rest.
Secure backups and recovery procedures.
Least-privilege access, audit logging and data-retention policies.
Protection against sensitive information appearing in logs, traces and API responses.

Also remember that if an attacker compromises the running application and can access both the encryption key and the decryption functionality, they may still obtain plaintext. Encryption does not replace application security.

Conclusion

Protecting sensitive insurance data requires more than securing database credentials.

With AES-256-GCM, Spring Boot can encrypt DOB and driver's license numbers before saving them to PostgreSQL and decrypt them when authorized business operations need the original values.

The essential principles are straightforward:

Encrypt sensitive fields before persistence.
Use authenticated encryption with a fresh IV for every operation.
Keep encryption keys separate from the encrypted database.
Control decryption through the application’s authorization layer.
Plan for key rotation, migration, backups and data retention.

The result is a stronger security boundary: someone who obtains only the database contents cannot directly read the original sensitive values.

Further reading: OWASP Cryptographic Storage Cheat Sheet and Java Cryptography Architecture (JCA) documentation.

two-sum

Md. Rakibul Hasan — Tue, 14 Jul 2026 16:30:32 +0000

Given an array of integers nums and an integer target, return indices of the two numbers such that they add up to target.

You may assume that each input would have exactly one solution, and you may not use the same element twice.

You can return the answer in any order.

Example 1:

Input: nums = [2,7,11,15], target = 9
Output: [0,1]
Explanation: Because nums[0] + nums[1] == 9, we return [0, 1].
Example 2:

Input: nums = [3,2,4], target = 6
Output: [1,2]
Example 3:

Input: nums = [3,3], target = 6
Output: [0,1]

Thinking::
The problem saying that we require to find those two index, if we sum those two, it will match to the target.

Solution #1:
First approach we can do is, do bruiteforce, so that we can point one and then find another one which will led to the solution.

class Solution {
    public int[] twoSum(int[] nums, int target) {

        for(int i = 0; i < nums.length; i++) {
            for(int j = i + 1; j < nums.length; j++) {
                if(nums[i] + nums[j] == target) {
                    return new int[] {i, j};
                }
            }
        }
        return new int[] {};
    }
}

Solution #2:
The bruiteforce approach takes about O(n^2), but what we can do is.
We can find nextDigit by subtracting the num[i] from target value.

ex:
Input: nums = [3,2,4], target = 6
here,
the target is 6,
so during traversing of nums array,
we can subtract nums[i]
so nextDigit = target - nums[i];
when, i = 0, = 6 - 3 = 3

So we need to find out 3 value on the next indexes.
In order to do this,
We can keep all the values in the hashMap and simply find out the nextDigit value on o(1). If it matches then we have the next first and next index.

class Solution {
    public int[] twoSum(int[] nums, int target) {
        Map<Integer, Integer> hashMap = new HashMap<>();
        for(int i = 0; i < nums.length; i++) {
            int nextNum = target - nums[i];
            if(hashMap.containsKey(nextNum)) {
                return new int[] {hashMap.get(nextNum), i};
            }
            hashMap.put(nums[i], i);
        }
        return new int[] {};
    }
}

Spring vs Spring Boot

Md. Rakibul Hasan — Tue, 16 Jun 2026 17:12:20 +0000

Spring and Spring Boot are popular frameworks in the Java ecosystem that simplify the development of enterprise and microservices-based applications. They provide powerful features to reduce boilerplate code and improve productivity while building robust systems.

Enables development of scalable and production-ready applications
Reduces complexity through simplified configuration and auto-setup
Promotes modular design using reusable components

Spring
Spring is a comprehensive Java framework that provides support for building robust and scalable enterprise applications. It focuses on dependency injection, aspect-oriented programming, and modular architecture.

Dependency Injection (DI): Simplifies object creation and management, promoting loose coupling.
Modular Framework: Offers various modules like Spring MVC, Spring Security, Spring Data, allowing selective use.
Flexible Configuration: Supports XML, annotations, and Java-based configuration for application setup.

Example: Spring application manually configured with beans and controllers:

@Configuration
@ComponentScan(basePackages = "com.example")
public class AppConfig {
    @Bean
    public UserService userService() {
        return new UserServiceImpl();
    }
}

@Controller
@RequestMapping("/users")
public class UserController {
    @Autowired
    private UserService userService;

    @GetMapping
    public String getUsers(Model model) {
        model.addAttribute("users", userService.getAllUsers());
        return "userList"; // JSP or HTML view
    }
}

// Main class deployed as WAR on external server like Tomcat
public class Main {
    public static void main(String[] args){

        // Deploy this app manually to an external server
    }
}

Introduction to Spring Boot

Md. Rakibul Hasan — Tue, 16 Jun 2026 16:45:45 +0000

Spring is one of the most popular frameworks for building enterprise applications, but traditional Spring projects require heavy XML configuration, making them complex for beginners. Spring Boot solves this problem by providing a ready-to-use, production-grade framework on top of Spring, eliminating boilerplate configuration and enabling rapid development.

Reduces development time by simplifying project setup
Provides opinionated defaults for faster decision-making
Makes it easier to build and deploy standalone applications

Features:

Spring Boot provides all the features of Spring while being significantly easier to use. Here are its key features:

Auto-Configuration: Spring Boot automatically configures the application based on the dependencies present in the project
Embedded Server: Spring Boot includes embedded servers like Tomcat, Jetty, or Undertow, allowing applications to run without external server installation.
Easy Deployment: Spring Boot applications can be packaged as JAR or WAR files and deployed directly to servers or cloud environments. By 2025, it offers seamless integration with Docker and Kubernetes for easier cloud-native deployment and scaling.
Standalone Application: Applications can run as executable JAR files using a simple main() method.
Microservice-Based Architecture: Spring Boot supports building independent, modular services instead of a monolithic application, improving scalability, maintainability, and deployment flexibility.

Evolution of Spring Boot

Spring Boot was introduced in 2013 following a JIRA request by Mike Youngstrom to simplify Spring bootstrapping.

Major Spring Boot Versions:

Spring Boot 1.0 (April 2014)
Spring Boot 2.0 (March 2018)
Spring Boot 3.0 (November 2022) (Introduced Jakarta EE 9+, GraalVM support)
Latest Version (2025): Spring Boot 3.x (Enhancements in observability, native images and containerization)

Spring Boot Architecture

To understand the architecture of Spring Boot, let’s examine its different layers and components.

Let’s understand the layered architecture in application development, which helps organize code by separating responsibilities into different layers, improving maintainability and scalability.

Client Layer: The external user or system that sends HTTP/HTTPS requests to interact with the application.
Controller Layer (Presentation Layer): Handles client requests, processes them, and forwards them to the service layer while returning responses.
Service Layer (Business Logic Layer): Contains the business logic and coordinates operations between the controller and repository layers.
Repository Layer (Data Access Layer): Manages database operations such as create, read, update, and delete (CRUD).
Model Layer (Entity Layer): Represents the application's data structure and maps Java objects to database tables.
Database Layer: The storage system where application data is permanently stored and retrieved.

Request Flow in Spring Boot

Client ->Controller ->Service ->Repository ->Database ->Response

A Client makes an HTTPS request (GET/POST/PUT/DELETE).
The request is handled by the Controller, which is mapped to the corresponding route.
If business logic is required, the Controller calls the Service Layer.
The Service Layer processes the logic and interacts with the Repository Layer to retrieve or modify data in the Database.
The data is mapped using JPA with the corresponding Model/Entity class.
The response is sent back to the client. If using Spring MVC with JSP, a JSP page may be returned as the response if no errors occur.

Applications of Spring Boot

Spring Boot is widely used in modern software development because of its simplicity, scalability and production-ready features. Here are some of its major applications:

Enterprise Applications: Build complex applications such as Hospital Management Systems, Banking Systems or ERP solutions with minimal configuration.
Cloud-Native Applications: Seamless integration with Docker, Kubernetes and cloud platforms (AWS, Azure, GCP) for deployment and scaling.
Real-Time Applications: Supports Reactive Programming for chat applications, streaming platforms, IoT systems and event-driven systems.
Batch Processing Applications: With Spring Batch, Spring Boot is used for ETL (Extract, Transform, Load), report generation and large data processing.

How I Learned Unit Testing in Spring Boot by Building One Simple Project

Md. Rakibul Hasan — Sat, 06 Jun 2026 15:05:58 +0000

What Building a Simple Spring Boot CRUD API Taught Me About Unit Testing

When I first started learning Spring Boot, I constantly heard senior developers talking about Unit Testing, JUnit, Mockito, and Test-Driven Development (TDD).

The problem?

Most tutorials were either too simple or too complicated.

So instead of watching endless videos, I decided to build a small project and learn testing through actual code.

The Project

I created a simple Task Management API with the following features:

Create Task
Update Task
Delete Task
Get Task by ID
List All Tasks

Nothing fancy.

The goal wasn't to build another Todo application.

The goal was to learn testing.

What I Learned

1. Not Everything Needs a Spring Context

My first mistake was using @SpringBootTest everywhere.

As a result, tests became slower because the entire Spring application context was loading for every test.

For service-layer testing, plain JUnit 5 and Mockito were more than enough.

Lesson: Use the lightest testing approach that gets the job done.

2. Mock Dependencies, Not the Class Under Test

One of the biggest testing concepts I learned was that the class being tested should be real, while its dependencies should be mocked.

Example:

@Mock
private TaskRepository taskRepository;

@InjectMocks
private TaskService taskService;

This allowed me to verify business logic without connecting to a database.

Lesson: Test the service. Mock the repository.

3. Test Behavior, Not Implementation

Initially, I focused on internal method calls and implementation details.

Later, I realized that tests become more maintainable when they verify outcomes instead.

Instead of checking how many methods were called internally, I started verifying whether the correct result was produced.

Lesson: Users care about results, not implementation details.

4. Edge Cases Matter More Than Happy Paths

Most bugs don't happen during ideal scenarios.

They happen when unexpected input appears.

Some examples I tested:

Task not found
Null input
Empty task title
Duplicate task creation

Writing tests for these scenarios increased my confidence in the application significantly.

Lesson: Edge cases often reveal the most valuable bugs.

5. Testing Improves Design

This was the biggest surprise.

The more tests I wrote, the more obvious poor design decisions became.

Large service classes became difficult to test.

Complex methods became harder to mock and verify.

Those pain points naturally pushed me toward better architecture and cleaner code.

Testing didn't just improve code quality.

It improved the design itself.

Lesson: Good tests encourage good architecture.

My Recommended Learning Path

If you're new to Spring Boot testing, here's the path I would recommend:

Learn JUnit 5 basics
Learn Mockito fundamentals
Build a small CRUD project
Write service-layer tests
Add controller tests using MockMvc
Learn integration testing afterward

Don't start with advanced topics.

Start small.

Write tests consistently.

Improve gradually.

Final Thoughts

Unit testing felt intimidating when I started.

Today, I see it as one of the most valuable skills a backend developer can learn.

If you're struggling with testing, stop watching tutorials for a moment.

Build a small project.

Write one test.

Then write another.

You'll learn much faster by doing than by consuming content.

Happy coding! 🚀

Question for the community:
What was the biggest challenge you faced when learning unit testing in Spring Boot?

What to do if Java command is not recognized by terminal.

Md. Rakibul Hasan — Wed, 05 Aug 2020 10:13:44 +0000

Now a days we install java in our windows for our own work.But it's quite annoying while it's not recognized by the terminal.Sometimes we even run java file from terminal so it needs to be fixed.
So here is the thing that you can do.
Step 1:
First of all right click on this pc.

Step 2:
Go to properties and click advanced system settings.

Step 3:
Now click on environment variables.

Step 4:
Now look at user variables. Look if there is any path variable.
If there is path variable then look at Method 1..
If there is no path variable then look at Method 2..

Method 1:
in your case if there is path variable.You have to select path variable and click edit.

Now click on new . And paste the location of your java bin folder.

Click and copy the location.In my case it's location is:
C:\Program Files\Java\jdk-14.0.1\bin

Now click on ok .Then open the terminal.
write--> "Java -version".

it should show your java version.
If it's not then reinstall java by downloading java executable file from https://www.oracle.com/java/technologies/javase-downloads.html

Method 2
If there is no path variable then click on new.

write the variable name as "path" And paste the location of your java bin folder in variable value box.

Click and copy the location.In my case it's location is:
"C:\Program Files\Java\jdk-14.0.1\bin"

So i have wrote the variable name as "path" and pasted "C:\Program Files\Java\jdk-14.0.1\bin"

Hope it will help you. Thanks !