Java 8 Best practice

Java 8 Lambda Expression

What is a Java Functional Interface?In Java, a functional interface is basically an interface with a single abstract method. This kind of interfaces are also known as SAM (Single Abstract Method) types.

In Java, the lambda expressions are represented as objects, and so they must be bound to a particular object type known as a functional interface. This is called the target type.Since a functional interface can only have a single abstract method, the types of the lambda expression parameters must correspond to the parameters in that method, and the type of the lambda body must correspond to the return type of this method. Additionally, any exceptions thrown in the lambda body must be allowed by the throws clause of this method in the functional interface.

Simple example to demonstrate usage of lambda expressions for SAM(single abstract interface) interfaces.

Using Lamba expression for Custom Interface with default method

Implementation of interface

Traversing Collection using foreach of Iterable interface

Using Consumer Interface

Application of Predicate Interface

Java 8 Method References

If we only use a method of an object in another method, we still have to pass the full object as an argument. Wouldn't it be more practical to just pass the method as an argument?
A method reference is the shorthand syntax for a lambda expression that executes just ONE method. Here's the general syntax of a method reference:

First of all, a method reference can't be used for any method. They can only be used to replace a single-method lambda expression.
So to use a method reference, you first need a lambda expression with one method. And to use a lambda expression, you first need a functional interface, an interface with just one abstract method.

There are four types of method references:

• A method reference to a static method. 
• A method reference to an instance method of an object of a particular type. 
• A method reference to an instance method of an existing object. 
• A method reference to a constructor.

Java8 Interface Default MethodFor creating a default method in java interface, we need to use “default” keyword with the method signature. For example,

package com.journaldev.java8.defaultmethod;

public interface Interface1 {

 void method1(String str);
 
 default void log(String str){
  System.out.println("I1 logging::"+str);
 }
}

Note-:

1. If any class in the hierarchy has a method with same signature, then default methods become irrelevant. A default method cannot override a method from java.lang.Object. The reasoning is very simple, it’s because Object is the base class for all the java classes. So even if we have Object class methods defined as default methods in interfaces, it will be useless because Object class method will always be used. That’s why to avoid confusion, we can’t have default methods that are overriding Object class methods.
2. Java interface default methods are also referred to as Defender Methods or Virtual extension methods.

Java8 Interface Static MethodJava interface static method is similar to default method except that we can’t override them in the implementation classes. This feature helps us in avoiding undesired results incase of poor implementation in implementation classes. Let’s look into this with a simple example.

package com.journaldev.java8.staticmethod;

public interface MyData {

 default void print(String str) {
  if (!isNull(str))
   System.out.println("MyData Print::" + str);
 }

 static boolean isNull(String str) {
  System.out.println("Interface Null Check");

  return str == null ? true : "".equals(str) ? true : false;
 }
}

Note-:

1. Java interface static method is part of interface, we can’t use it for implementation class objects.
2. Java interface static method helps us in providing security by not allowing implementation classes to override them.

Java8 Stream API

The Stream interface is defined in java.util.stream package. Starting from Java 8, the java collections will start having methods that return Stream. This is possible because of another cool feature of Java 8, which is default methods. Streams can be defiled as a sequence of elements from a source that supports aggregate operations.

The source here refers to a Collection, IO Operation or Arrays who provides data to a Stream. Stream keeps the order of the data as it is in the source. Just like functional programming languages, Streams support Aggregate Operations. The common aggregate operations are filter, map, reduce, find, match, sort. These operations can be executed in series or in parallel.

The Streams also support Pipelining and Internal Iterations. The Java 8 Streams are designed in such a way that most of its stream operations returns Streams only. This help us creating chain of various stream operations. This is called as pipelining. The pipelined operations looks similar to a sql query.

In Java, we traditionally use for loops or iterators to iterate through the collections. These kind of iterations are called as external iterations and they are clearly visible in the code. Java 8 Stream operations has methods like foreach, map, filter, etc. which internally iterates through the elements. The code is completely unaware of the iteration logic in the background. These kind of iterations are called as internal iterations.

List<String> names =newArrayList<>();

for(Student student : students){

if(student.getName().startsWith("A")){

names.add(student.getName());

}

}

There is nothing special about this code. This is a traditional Java external iterations example. Now, have a look at the below code. This line is doing exactly the same thing but we can't see any iteration logic here and hence it is called as internal iterations.

List<string> names = students.stream().map(Student::getName).filter(name->name.startsWith("A"))

.collect(Collectors.toList());

For better understanding of Java 8 Stream API:https://dzone.com/articles/understanding-java-8-streams-1


Java 8 Optional class

Optional is a new type in Java 8 that wraps either a value or null, to represent the absence of a value. The main benefit is that it your code can now gracefully handle the existence of null values, as you don’t have to explicitly check for nulls anymore.

Optional is a monadic type you can map functions into, that will transform the value inside the Optional

See-:

https://www.mkyong.com/java8/java-8-optional-in-depth/

Java8 Nashorn engine

The Nashorn Javascript Engine is part of Java SE 8 and competes with other standalone engines like Google V8 (the engine that powers Google Chrome and Node.js). Nashorn extends Javas capabilities by running dynamic javascript code natively on the JVM. 

A simple HelloWorld in java code looks like this:

ScriptEngine engine = new ScriptEngineManager().getEngineByName("nashorn");
engine.eval("print('Hello World!');");

In order to evaluate javascript code from java, you first create a nashorn script engine by utilizing the javax.script package already known from Rhino (Javas legacy js engine from Mozilla).

Javascript code can either be evaluated directly by passing javascript code as a string as shown above. Or you can pass a file reader pointing to your .js script file:

ScriptEngine engine = new ScriptEngineManager().getEngineByName("nashorn");
engine.eval(new FileReader("script.js"));

GIT Beginners Tutorial

Introduction

Git (/ɡɪt/) is a distributed version control system (VCS) for tracking changes in computer files and coordinating work on those files among multiple people. It is primarily used for software development, but it can be used to keep track of changes in any files. More often it is used for source code management.
This blog is divided in two parts.
   1. Setting up git on local machine, and running commands locally
   2. This part covers git in depth and practical scenario(remote) is covered.

Download and Install

- Go to git-scm.com/downloads,  download executable for required operating system.

Check version of your Git bash

$ git --version

Configuring Username and email

$ git config --global username "vikasmishra12345"

$ git config --global user.email "vikasmishra@gmail.com"

To see if all setting are configured

$ git config --list    {use clear command to clear screen}

To see any specific settings,

$ git config user.email  

To see all commands

$ git help

or  $git help command name

Creating First Repository

To see, where git is currently looking, type 

$ pwd

And, to  change to custom folder

$ cd ..

$ cd User/Desktop/GitExample

Now to make folder a git project

$ git init

Git will reply

Initialized empty Git repository in .git/

You’ve now initialized the working directory—​you may notice a new directory created, named ".git".

Git(local) Architecture
This is an architecture of local only, ie. it commits changes into local repository and when we do it in remote repository i.e.github then further command are used

Commit changes

First check if there is any file in our project , type ls and to see hidden files ls -la

Note -To see content inside .git, type
$ ls -la .git
Inside .git folder, there is config folder which stores all changes made in project at one place

Now add some files inside folder manually. And to commit we need to follow two steps.

Next, tell Git to take a snapshot of the contents of all files under the current directory (note the .), with git add:

$ git add .      {Adds all changes made in folder. This is to let git know that we made changes. Unless we add any file, that file is not tracked by git. Also we can add specific file using command
$ git add abc.txt }

You can permanently store the contents of the index in the repository with git commit.To keep track of changes we need to commit these changes, commit command is used.
$ git commit -m "Any message"

Add command moves changes from local to staging area(also called index). Commit command moves changes from index to repository. It stores SHA-1 hash values of changes made. It does not save changed file but changed set(i.e.whole change as 1 set)

After we commit, in the following way git stores all commit history. Once commit cannot be unchanged. It ensures complete data integrity. Only changes are made in new or in the last data where HEAD is pointing.

To skip staging area and commit into repository. Note-: It pushes all changes in project to repository.

$ git commit -am "Pushing changes directly to repository"
$ git commit -a

View History & Status 

To view commit history, we use log command
$ git log
or
$ git log -p
$ git log --oneline

To view changes made on you project, we use status command. lets make some changes in one of our file and also add some new file in our project. Status commad help us to see difference in three tier ie. repository,staging index, working directory.
$ git status    {tells any change made within local copy in workspace}

View Specific Changes

To view difference between local and staging area.{In actual diff command compares repository and local, but when we run add command then file is moved to staging area. Hence no changed file present at local. Now no change present between local and repository, hence it seems as if comparing local and staging area. }

$ git diff
$ git diff abcd.txt                                 {Compares staging and working directory}

To view difference between staging area and repository
$ git diff --staged abcd.txt

Deleting Files

To delete file simply use rm command.

$ git rm abcd.txt     
$ git commit -m "Deletion point"  {This makes changes in repository}

Moving & Renaming Files

Here, move and rename are synonymous. For both purpose we use mv command:
$ git mv ActualFile RenameFile   { we can give complete address as well }
$ git commit -m "File renamed"

Undoing Changes

To checkout file from repository(local)
$ git checkout -- "checking out from repository"

To unstage File from staging area. It replaces file from staging index with repository.
$ git reset HEAD abcd.html

Checking out older Version from Repository
$ git checkout commitId    {this can be obtained from git log command, we can type Id partially}

To checkout specific file, file name can be given. No need to type complete commit Id we can type partially in above two example. This commits to staging index. It does not make any change in working repository
$ git checkout abcd73e  -- index.html    

$ git reset HEAD index.html

To update or amend last commit we use amend command. It does not remove previous commit but actually updates with latest commit including message.
$ git commit --amend -m "Make change comment"

To undo commit made in repository, we make changes in HEAD only always. For this we use revert command.
$ git revert 37ebhgsdhshd4578ss

Resetting pointer 
It resets current head to specified state. Remember save commit state of head pointer for any future references. We can move head both forward and backward direction. Hence to go in past state or to revert back to previous state, use reset state.

   To see where git header points to use following command:

Suppose, we have some untracked files in our directory, then use clean command:
$ git clean -f            {Removes all untracked from working directory}.

In order to ignore tracking of some file, we need to create .gitignore  file {for windows create file manually and save as '.gitignore' with type as 'All files'} in our working directory and need to add whatever file we want it to ignore.
$ git add .gitignore
$ git commit -m "Add ignoring file"

Make entry of all files and directory to be ignored are to be put in .gitignore file. for example

Generally following entries are ignored and its entry is made in .gitignore file.
Following are link to get detail info about 'to be ignored file'

In order to view commit,
$ git ls-tree branchName

Note-:blob generally refers to file and tree refers to directory. Tree inside tree is known as tree-ish

We can also compare two commit using SHA value of 2 commits
$ git diff xzwdg2334sd..wqrsfed12m

Branching
In order to create branch, use branch command
$ git branch  {to view all branches}
$ git branch newBranchName        {to create new branch}

In order to change branch name use:
$ git checkout branchName      {To switch from one branch to another}

$ git checkout -b branchName        {creation and switching in one step}

$ git diff oneBranch..anotherBranchName    {to see difference in two branches}

To rename branch,

$ git branch -m existing_Name new_Name


To delete branch, can only be deleted from other branch only(not same)
$ git branch -d branch_to_delete

Merging

To view merge branches in current branch:
$ git branch --merge

To merge changes from one branch to another use merge command, first checkout branch where changes are to be merged

$ git merge branch_name  {here branch name refers from where changes are to be merged into current checkout branch}

To abort merging in case of conflict

$ git merge --abort   

Stashing
In order to save our work without adding or commit in staging or in repository, we use stash. It temporarily stores in stash area.
$ git stash list   {enlist all stash items}
$ git stash save "any comment"  {to save in stash}
$ git stash show -p stash@{0}     {to view particular stash}
$ git stash pop stash@{0}           {to bring stash item in current directory and also removing it from stash are}
$ git stash drop stash@{0}  {delete stash item}


Finally, gitk command show graphical representation of changes:
$ gitk


Cloning

To clone project in our folder, we use clone command

$ git clone fromCopylocation toCopylocation

Git In Detail

Local Repositories

git (locally) has a directory (.git) which you commit your files to and this is your 'local repository'. This is different from systems like svn where you add and commit to the remote repository immediately.

git stores each version of a file that changes by saving the entire file. It is also different from svn in this respect as you could go to any individual version without 'recreating' it through delta changes.

git doesn't 'lock' files at all and thus avoid the 'exclusive lock' functionality for an edit (older systems like pvcs come to mind), so all files can always be edited, even when off-line. It actually does an amazing job of merging file changes (within the same file!) together during pulls or fetches/pushes to a remote repository such as github. The only time you need to do manual changes (actually editing a file) is if two changes involve the same line(s) of code.

---

Branches

Branches allow you to preserve the main code (the 'master' branch), make a copy (a new branch) and then work within that new branch. When you've finished, you merge the changes made in the branch back in to the master repository. Many organizations use branches for each piece of work whether it is a feature, bug or chore item. Other organizations only use branches for major changes such as version upgrades. With a branch you control and manage the branch, whereas with a fork someone else controls accepting the code back in.

Broadly speaking there are two main approaches to doing branches. The first is to keep most changes on the master branch, only using branches for larger and longer-running things like version changes where you want to have two branches available for different needs. The second is whereby you basically make a branch for every feature request, bug fix or chore and then manually decide when to actually merge those branches into the main master branch. Though this sounds tedious, this is a common approach and is the one that I currently use and recommend because this keeps the master branch cleaner and it's the master that we promote to production, so we only want completed, tested code, via the rebasing and merging of branches.

The standard way to bring a branch "in" to master is to do a merge. Branches can also be rebased to 'clean up' history. It doesn't affect the current state and is done to give a 'cleaner' history. Basically the idea is that you branched from a certain point (usually from master). Since you branched 'master' itself has moved forward. So it would be cleaner if all the changed you have done in a branch are played against the most recent master with all its changes. So the process is: save the changes; get the "new" master, and then reapply the changes again against that. Be aware that rebase, just like merge, can result in conflicts that you have to manually resolve (edit).

One 'guideline' to note: Only rebase if the branch is local and you haven't pushed it to remote yet! This is mainly because rebasing can alter the history that other people see which may include their own commits.

Tracking branches

These are the branches that are named origin/branch_name (as opposed to just branch_name). When you are pushing and pulling the code to/from remote repositories this is actually the mechanism through which that happens. For example when you git push a branch called 'building_groups', your branch goes first to origin/building_groups and then that goes to the remote repository (actually that's an over-simplification but good enough for now). Similarly if you do a git fetch building_groups the file that is retrieved is placed in your origin/building_groups branch. You can then choose to merge this branch into your local copy. Our practice is to always do a git fetch and a manual merge rather than just a git pull (which does both of the above in one step).

Fetching new branches.

Getting new branches: At the initial point of a clone you will have all the branches. However, if other developers add branches and push them to the remote there needs to be a way to 'know' about those branches and their names in order to be able to pull them down locally. This is done via a git fetch which will get all new and changed branches into the locally repository using the tracking branches (e.g. origin/). Once fetched, one can git branch --remote to list the tracking branches and git checkout [branch] to actually switch to any given one.

Merging

Merging is the process of combining code changes from different branches, or from different versions of the same branch (for example when a local branch and remote are out of sync.). If one has developed work in a branch and the work is complete, ready and tested, then it can be merged into the master branch. This is done by git checkout master to switch to the master branch, then git merge your_branch. The merge will bring all the different files and even different changes to the same files together. This means that it will actually change the code inside files to merge all the changes. When doing the checkout of master it's also recommended to do a git pull origin master to get the very latest version of the remote master merged into your local master. If the remote master changed, i.e. moved forward, you will see information that reflects that during that git pull. If that is the case (master changed) you are advised to git checkout your_branch and then rebase it to master so that your changes actually get "replayed" on top of the "new" master. Then you would continue with getting master up-to-date as shown in the next paragraph.

If there are no conflicts then master will have the new changes added in. If there are conflicts, this means that the same files have changes around similar lines of code that it cannot automatically merge. In this case git merge new_branch will report that there's conflict(s) to resolve. You 'resolve' them by editing the files (which will have both changes in them), selecting the changes you want, literally deleting the lines of the changes you don't want and then saving the file. The changes are marked with separators such as ======== and <<<<<<<<

Once you have resolved any conflicts you will once again git add and git commit those changes to continue the merge (you'll get feedback from git during this process to guide you). When the process doesn't work well you will find that git merge --abort is very handy to reset things.

Forks

There are two main approaches to collaboration in git repositories. The first, detailed above is directly via branches that people pull and push from/to. These collaborators have their ssh keys registered with the remote repository. This will let them push directly to that repository. The downside is that you have to maintain the list of users. The other approach - forking - allows anybody to 'fork' the repository, basically making a local copy in their own git repository account. They can then make changes and when finished send a 'pull request' (really it's more of a 'push' from them and a 'pull' request for the actual repository maintainer) to get the code accepted.
This second method, using forks, does not require someone to maintain a list of users for the repository

When you 'fork' - in the github web browser gui you can click on  - you create a copy ('clone') of the code in your github account. It can be a little subtle first time you do it, so keep making sure you look at whose repository a code base is listed under - either the original owner or 'forked from' and you

Clones

As indicated in the section on github, a clone is a copy of a repository. When you have a remote repository you issue the git clone command against its URL and you then end up with a local copy, or clone of the repository. This clone has everything, the files, the master branch, the other branches, all the existing commits, the whole shebang. It is this clone that you do your adds and commits against and then the remote repository itself is what you push those commits to. It's this local/remote concept that makes git (and systems similar to it such as Mercurial) a DVCS (Distributed Version Control System) as opposed to the more traditional CVS's (Code Versioning Systems) such as SVN, PVCS, CVS, etc. where you commit directly to the remote repository.

Pull

$git pull

Incorporates changes from a remote repository into the current branch. In its default mode, git pullis shorthand for git fetch followed by git merge FETCH_HEAD.

Git Aliasing

For this I have the following aliases in my ~/.bash_aliases file (which is called from my ~/.bashrc file for each terminal session:

# git
alias gst='git status' # Warning: gst conflicts with gnu-smalltalk (when used).
alias gb='git branch'
alias gco='git checkout'
alias gcob='git checkout -b '
alias ga='git add '
alias gc='git commit'
alias gg='git grep ' #  A great very FAST search option, easier then `find`




Basic Troubleshooting/Useful Tips







Finally, 6 key lifesavers:

1) You mess up your local branch and simply want to go back to what you had the last time you did a git pull:

git reset --hard origin/master  # You will need to be comfortable doing this!

2) You start making changes locally, you edit half a dozen files and then, oh crap, you're still in the master (or another) branch:

git checkout -b new_branch_name  # just create a new branch
git add .                      # add the changes files
git commit -m"your message"    # and commit them

3) You mess up one particular file in your current branch and want to basically 'reset' that file (lose changes) to how it was the the last time you pulled it from the remote repository: git checkout your/directories/filename This actually resets the file (like many git commands it is not well named for what it is doing here).

4) You make some changes locally, you want to make sure you don't lose them while you do a git reset or rebase: I often make a manual copy of the entire project (cp -r ../my_project ~/) when I am not sure if I might mess up in git or lose important changes.

5) You are rebasing but things gets messed up:

git rebase --abort # To abandon interactive rebase and merge issues

6) Add your git branch to your PS1 prompt (see https://unix.stackexchange.com/a/127800/10043), e.g. 




Basic differences




Git clone vs Git pull




Git clone is the equivalent of these three commands:

git init
git remote add origin [url]
git pull origin master




Git pull is the equivalent of these commands:
git fetch
git merge origin/master

The 'origin' here is the name of a 'remote'




Git clone vs checkout




git clone is to fetch your repositories from the remote git server.

git checkout is to checkout your desired status of your repository (like branches or particular files).

E.g., you are currently on master branch and you want to switch into develop branch.

git checkout develop_branch

E.g., you want to checkout to a particular status of a particular file

git checkout commit_point_A -- <filename>







Git push vs commit




Basically git commit "records changes to the repository" while git push "updates remote refs along with associated objects". So the first one is used in connection with your local repository, while the latter one is used to interact with a remote repository.

In short, basically git commit puts your changes into your local repo, while git push sends your changes to the remote location.




ForK vs Clone




Fork

• A copy to your remote repo (cloud) that links it to Joe's
• A copy you can then clone to your local repo and F*%$-up
• When you are done you can push back to your remote
• You can then ask Joe if he wants to use it in his project by clicking pull-request

Clone

• a copy to your local repo (hard drive)

GitHub

github (a remote repository) is a remote source that you normally push and pull those committed changes to if you have (or are added to) such a repository, so local and remote are actually quite distinct. Another way to think of a remote repository is that it is a .git directory structure that lives on a remote server.

Commonly used git commands

In order to wrap the text in git bash use, minus with shift+S and return. To move forward use F key and B for backward. Space bar to see rest of result.

To use it sign up on https://github.com/

How to fetch from remote branch

 go to master branch of that applicatipon

 git fetch

 git checkout -b Branch_X origin/Branch_X

 git branch

 git pull

How to merge multiple commit message in one commit(squashing)

  git log —oneline

   git reset --hard Head~5

   git merge --squash HEAD@{1}

   git commit -m 'comments here'

 git log --oneline