The best way to unwrap the optional in java Instead of using the null checks I tried using Optional and safely unwrapping the optional.

Approach 1

My first approach of unwrapping the Optional is using map() followed by orElseThrow().

Approach 2

My second approach if unwrapping the Optional is using orElseThrow() and setting the value to a variable and using it.

Service

@Inject 
private UserConfigurationRepository userConfigurationRepository;

public UserConfiguration updateConfigUsingOrElseThrow(User user, String value) {
    UUID configurationId = user.getConfigurationId().orElseThrow();
    UserConfiguration userConfiguration = userConfigurationRepository
            .findById(configurationId).orElseThrow();
    return updateUserConfiguration(userConfiguration, value); // Performs update operation
}

public UserConfiguration updateConfigUsingMapOrElseThrow(User user, String value) {
    return user.getConfigurationId().map(configurationId -&gt;{
        return userConfigurationRepository.findById(configurationId).map(userConfiguration -&gt; {
            return updateUserConfiguration(userConfiguration, value); // Performs update operation
        }).orElseThrow();
    }).orElseThrow();
}

private UserConfiguration updateUserConfiguration(UserConfiguration userConfiguration, String value)
{
    userConfiguration.setValue(value);
    // Business Logics
    return userConfigurationRepository.save(userConfiguration);
}


Repository

public interface UserConfigurationRepository extends JpaRepository&lt;UserConfiguration, UUID&gt;{}


Model

public class User {
   private int id;
   private String name;
   private String email;
   private UUID configurationId;

   public Optional&lt;UUID&gt; getConfigurationId() {
       return Optional.ofNullable(configurationId);
   }

   public void setConfigurationId(UUID configurationId) {
       this.configurationId = configurationId;
   }

   //Ignored getters and setters of other properties those are not used in this part of code                  
}

public class UserConfiguration {
   private UUID id;
   private String value;

   public UUID getId() {
       return id;
   }

   public void setId(UUID id) {
       this.id = id;
   }

   public String getValue() {
       return value;
   }

   public void setValue(String value) {
       this.value = value;
   }
}


I am used to using null check using if statement and since I am new to this style of programming I am not sure which one is the best approach and gives more readability, Or is there any other recommended way to do this?

The task of this service is to get the configuration id and a configuration message from front end and update the data in the configuration table. And returns the updated configuration information. Not all the users will have an entry in the configuration so there is a possibility of getting null value for configurationId in the User model thats is why the getter returns the optional of configurationId.

Since this is my client code I am unable to expose the complete code, So I provided the structure of the model, services and repository. Hope I have provided necessary information.
I think you want flatMap. 
Those returns and braces are unnecessary noise.
I would consider not throwing but returning Optional&lt;UserConfiguration&gt; instead. Part of learning this style is realising that unwrapping is rarely necessary. At the call site, you can do something along the lines of update(user).ifPresentOrElse(...). [*]

public Optional&lt;UserConfiguration&gt; update(User user) {
    return user.getConfigurationId() // Optional&lt;UUID&gt;
        .flatMap(configurationId -&gt; userConfigurationRepository.findById(configurationId)) // Optional&lt;UserConfiguration&gt;
        .map(userConfiguration -&gt; updateUserConfiguration(userConfiguration)); // Optional&lt;UserConfiguration&gt;
}

However, if you insist on unwrapping, nothing's stopping you, technically.

public UserConfiguration update(User user) {
    return user.getConfigurationId() // Optional&lt;UUID&gt;
        .flatMap(configurationId -&gt; userConfigurationRepository.findById(configurationId)) // Optional&lt;UserConfiguration&gt;
        .map(userConfiguration -&gt; updateUserConfiguration(userConfiguration)) // Optional&lt;UserConfiguration&gt;
        .orElseThrow();
}

consider method references. Sometimes they make code more readable, other times they don't. But mostly yes.

public Optional&lt;UserConfiguration&gt; update(User user) {
    return user.getConfigurationId() // Optional&lt;UUID&gt;
        .flatMap(userConfigurationRepository::findById) // Optional&lt;UserConfiguration&gt;
        .map(this::updateUserConfiguration); // Optional&lt;UserConfiguration&gt;
}



[*] - Getting into this mindset would help you a lot when you will start working with other wrapper types that rely on the same abstractions, such as the standard library's Stream, RxJava, Spring 5-reactive stack / Project Reactor, or classes provided by the vavr library. Although possible, unwrapping some of these is considered a very bad idea, e.g. in case of RxJava and Reactor it is a blocking action which you want to avoid at all costs when writing reactive software. But even in the case of Optional, why not have the fact that the value might be missing captured by the type system rather that throwing Exceptions around that might be invisible up the stack until there is actually an issue.