interview q4

 diff b/w @get and @getmapping:

@GetMapping is a composed annotation that acts as a shortcut for @RequestMapping(method = RequestMethod.GET).

In the @javax.ws.rs package there are annotations for each HTTP method. @GET, @POST, @PUT, @DELETE

 no sql db in aws : dynamo db

@controller vs @restcontroller:

@restcontroller combination of the @controller and @ResponseBody annotation.

What is the difference between @controller and @component?

@Component is a generic stereotype for any Spring-managed component or bean. @Repository is a stereotype for the persistence layer. @Service is a stereotype for the service layer. @Controller is a stereotype for the presentation layer (spring-MVC).

@Component vs @Bean:

@Component is a class level annotation whereas @Bean is a method level annotation 

@Bean annotation has to be used with @Configuration.

@Configuration
class MyConfiguration{
    @Bean
    public User getUser() {
        return new User();
    }
}

class User{
}    
        
// Getting Bean 
User user = applicationContext.getBean("getUser");

@Component
class User {
}

// to get Bean
@Autowired
User user;

Relational db in aws:

Amazon RDS

hashmap implementation in java 8:

In Java 8, HashMap replaces linked list with a binary tree when the number of elements in a bucket reaches certain threshold. While converting the list to binary tree, hashcode is used as a branching variable. If there are two different hashcodes in the same bucket, one is considered bigger and goes to the right of the tree and other one to the left. But when both the hashcodes are equal, HashMap assumes that the keys are comparable, and compares the key to determine the direction so that some order can be maintained. It is a good practice to make the keys of HashMap comparable.

what happens if we don't override hashcode

Overriding only equals() method without overriding hashCode() causes the two equal instances to have unequal hash codes, which violates the hashCode contract (mentioned in Javadoc) that clearly says, if two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.

diff between runnable and callable

Runnable object does not return a result whereas a Callable object returns a result.

future vs CompletableFuture:

ompletableFuture has some functional features that a regular Future does not have, like the ability to chain executions with thenApply or thenAccept that take a function that process the result after it´s available. get() is blocking which is present in Future. But if you do not need the results for further processing (Eg. you just want to insert the results in a Database) a CompletableFuture will have the advantage that you can provide a function that takes the result and does something with it. Eg. like this completableFuture.thenAccept(result -> DB::storeInDB); This way you would not have to wait for the result with get().

how to join results from multiple futures?

CompletableFuture<String> future1 = CompletableFuture.supplyAsync(() -> "Hello"); CompletableFuture<String> future2 = CompletableFuture.supplyAsync(() -> "Beautiful"); CompletableFuture<String> future3 = CompletableFuture.supplyAsync(() -> "World");

String combined = Stream.of(future1, future2, future3) .map(CompletableFuture::join) .collect(Collectors.joining(" ")); assertEquals("Hello Beautiful World", combined);

asynchronous process : we can achieve in 2 ways 1) ExecutorService 2) CompletableFuture

A) ExecutorService executorService = Executors.newFixedThreadPool(3);
  Runnable service1 = () -> {
     MyFileService.service1();
  };

  Runnable service2 = () -> {
      MyFileService.service2();
  };

  Runnable service3 = () -> {
      MyFileService.service3();
  };

  executorService.submit(service1);
  executorService.submit(service2);
  executorService.submit(service3);

B) CompletableFuture.supplyAsync(() -> MyFileService.service1();

    CompletableFuture.supplyAsync(() ->  MyFileService.service2();
    CompletableFuture.supplyAsync(() ->  MyFileService.service3();

CompletableFuture API allows to easily chain more calls with thenApply(), thenCompose().

CompletableFuture.allOf() : wait for all futures

CompletableFuture runAsync vs supplyAsync:

runAsync :it does not return any result

suppyAsync: it takes Supplier as argument and returns result