<h2 id="introduction">Introduction</h2>
CSV stands for <a rel="nofollow" target="_blank" href="https://en.wikipedia.org/wiki/Comma-separated_values">Comma Separated Values</a>, a method of formatting data which has been used even before the use of personal computers became widespread. The format gained popularity because the first computers used <a rel="nofollow" target="_blank" href="https://en.wikipedia.org/wiki/Punched_card">punched cards</a> to process data, and comma separated values are easier to 'punch' in than traditional table-formatted data in fixed columns.
In the present, CSV files are typically used to transfer data between applications or systems, acting as a common format to export data from one system and import it back to another.
The CSV format typically consists of information organized with lines consisting of multiple fields separated by a delimiter, with one line equivalent to one data record. The delimiter can be a comma, semi-colon, or tab character. There is no specific format, although a specification called <a rel="nofollow" target="_blank" href="https://tools.ietf.org/html/rfc4180">RFC 4180</a> has been introduced in an attempt to standardize how a CSV file should ideally behave.
<h2 id="rfc4180">RFC 4180</h2>
&quot;RFC&quot; stands for Request for Comments, meaning that the document is just meant to be a set of common specifications or guidelines, and not accepted rules.
There are many deviations from the specified format in the way CSV files are generated and read by modern applications, but most systems adhere to the initial guidelines set out by RFC 4180.
According to RFC 4180, CSV files should have the following commonalities:
<ul>
<li>Each record should be on a separate line, with a character break at the end of the line.</li>
<li>There may or may not be a header line. The presence of a header can be specified in the <code>header</code> parameter of the <a rel="nofollow" target="_blank" href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME type</a>.</li>
<li>The MIME type for CSV files officially registered with <a rel="nofollow" target="_blank" href="https://www.iana.org/">IANA</a> is &quot;text/csv&quot;.</li>
<li>Each record may consist of one or more comma-separated fields, and the same number of fields should persist throughout the file (there should be an equal number of fields in all records).</li>
<li>If a field contains commas, line breaks or double-quotes, it should be enclosed in double quotes itself.</li>
</ul>
<h2 id="whyusecsvsforiooperationswithjava">Why use CSVs for IO operations with Java</h2>
CSV files are human-readable, and simpler to understand than other data transfer formats like <a target="_blank" href="/reading-and-writing-xml-in-java">XML</a> or <a target="_blank" href="/reading-and-writing-json-in-java">JSON</a>.
CSV files can be imported into most spreadsheet applications like Excel, Google Sheets and OpenOffice Calc, and easy to generate - an existing <code>.xls</code> or <code>.xlsx</code> file can be converted to CSV format within Excel itself, as long as the file contains just characters and not any macros, images, etc.
The format is compact and usually smaller in size, leading to faster processing and generation. In comparison, XML requires repetition; typically the column header name is repeated twice for each row with the start and end tags (along with syntax-related characters), whereas CSV only requires the column headers once, usually in the very first row.
Given all these factors, being able to read from and write to CSV files is a key skill for any Java developer.
<h2 id="readingandwritingcsvsincorejava">Reading and Writing CSVs in Core Java</h2>
Owning to the popularity and widespread use of CSV as a format for data transfer, there are many parser libraries that can be used along with Java.
Third-party parsers define common formats and are able to work with various delimiters, handle special characters, and sometimes even read non-binary data. However, it is still important to be able to handle CSV files with core Java, without the use of any additional libraries.
A simple combination of <code>FileReader</code>, <code>BufferedReader</code>, and <code>String.split()</code> can facilitate reading data from CSVs.
<ul>
<li><a target="_blank" href="/reading-and-writing-csvs-in-java">Reading and Writing CSVs Java</a></li>
</ul>
<h2 id="readingandwritingcsvswithapachecommonscsv">Reading and Writing CSVs with Apache Commons CSV</h2>
The <a rel="nofollow" target="_blank" href="http://commons.apache.org/proper/commons-csv/download_csv.cgi">Apache Commons CSV</a> library is the Apache Software Foundation's version of a Java CSV parser. According to the <a rel="nofollow" target="_blank" href="https://commons.apache.org/proper/commons-csv/summary.html">project summary</a>, it attempts to &quot;provide a simple interface for reading and writing CSV files of various types&quot;.
As with all libraries associated with Apache, it operates with an <a rel="nofollow" target="_blank" href="https://www.apache.org/licenses/LICENSE-2.0">Apache license</a>, meaning it can be used, distributed, and modified freely.
<ul>
<li><a target="_blank" href="/reading-and-writing-csvs-in-java-with-apache-commons-csv/">Reading and Writing CSVs in Java with Apache Commons CSV</a></li>
</ul>
<h2 id="readingandwritingcsvswithopencsv">Reading and Writing CSVs with OpenCSV</h2>
<a rel="nofollow" target="_blank" href="http://opencsv.sourceforge.net/">OpenCSV</a> is one of the simplest and easiest CSV parsers to understand, using standard <code>Reader</code>/<code>Writer</code> classes and offering a <code>CSVReader</code> implementation on top.
Just like Apache Commons CSV, OpenCSV operates with an Apache 2.0 license. Before downloading and deciding whether to use OpenCSVs parsers, you can browse through the <a rel="nofollow" target="_blank" href="https://sourceforge.net/p/opencsv/source/ci/master/tree/">source code and Java docs</a>, and even check out their JUnit test suite, which is included in their git repository.
<ul>
<li><a target="_blank" href="/reading-and-writing-csvs-in-java-with-opencsv/">Reading and Writing CSVs in Java with OpenCSV</a></li>
</ul>
<h2 id="thirdpartylibrariesforcsviooperations">Third-Party Libraries for CSV IO operations</h2>
Knowing how to read from and write to a CSV file in core Java is important, and usually sufficient for most basic operations. However, there are instances where relying on a third party library is the way to go.
For example, our own usage of <code>split</code> to parse a CSV file, without using libraries above, would fail if the fields themselves contained commas. We could extend our logic to fit this scenario, but why reinvent the wheel when there are already proven solutions available for use?
This is where libraries come in - most of them support various configurations and identify escape characters and end of file characters frequently used by different systems, product suites and databases so that we don't have to track, implement, and unit-test each configuration ourselves.
There are a multitude of different parsing libraries available for free, each with different strengths. Let's consider some of the more popular libraries for CSV parsing with Java, comparing their pros and cons.
<h2 id="othercsvlibraries">Other CSV libraries</h2>
In addition to Apache Commons CSV and OpenCSV, there are a variety of other CSV parsers available for use. Let's take a quick look at some of the other libraries, and <a rel="nofollow" target="_blank" href="https://github.com/robert-bor/CSVeed/wiki/Comparison-of-Java-CSV-libraries">compare their usage</a>, advantages, and disadvantages:
<h3 id="supercsv">SuperCSV</h3>
<a rel="nofollow" target="_blank" href="http://super-csv.github.io/super-csv/index.html">SuperCSV</a> is another dominant CSV parsing library. The SuperCSV implementation supports formats that are not considered by other mainstream parsers.
Similar to the OpenCSV annotation methods, SuperCSV offers POJO support for dealing with Java Beans, in addition to the usual lists and maps.
Encoding and decoding is also handled by the library as long as the file is compliant to the format outlined in the <a rel="nofollow" target="_blank" href="http://super-csv.github.io/super-csv/csv_specification.html">SuperCSV specification</a>. If the file is non-compliant, you can still define a custom delimiter, quote character, or new line character as required, or extend the source code to facilitate specific requirements.
Parsing is made easier by data formatting options available with SuperCSV, which allows trimming and regex replacements while processing. The library also supports stream-based input and output, making it manageable in terms of performance and memory constrained systems.
The SuperCSV library also allows partial reading and partial writing, which is not supported by the other CSV parsers we've discussed throughout this article. You can choose to set specific header column values to <code>null</code> and proceed with processing the remaining columns, or write a dataset which contains optional values without adding your own error-handling.
A big downside that deserves mentioning is that the library does not appear to be maintained - the last published date is four years ago - in 2015, although the <a rel="nofollow" target="_blank" href="https://github.com/super-csv/super-csv">git repository</a> has more recent contributions.
<h3 id="univocitycsvparser">UniVocity CSV Parser</h3>
<a rel="nofollow" target="_blank" href="https://www.univocity.com/pages/about-parsers">UniVocity CSV Parser</a> loudly <a rel="nofollow" target="_blank" href="https://github.com/uniVocity/csv-parsers-comparison">claims to be the fastest CSV parser</a> in a 2018 comparison among 18 different publicly available CSV parsers. UniVocity parser allows you to select the fields you want to parse, skipping the unnecessary or non-mandatory fields in a single file, giving it the ability to filter columns of a CSV.
It has more customization options than OpenCSV and Apache Commons CSV, which makes it harder to set up and get started with. Code readability might also be less when compared to some other libraries since UniVocity parser requires that the format, line separator, and header extraction method be declared before parsing is attempted.
On the positive side, the variety of <a rel="nofollow" target="_blank" href="https://www.univocity.com/pages/univocity_parsers_tutorial#settings">formatting and customization options</a> makes it suitable to deal with the 'edge-cases' involving CSV files which are not RFC4180 compliant.
Similar to both OpenCSV and Apache Commons CSV, you can use either an iterator or defined parser class (in this case either <code>CsvParser</code> or <code>TsvParser</code>). UniVocity CSV Parsers also supports reading into beans with a more complex setup when compared to OpenCSV.
Writing is a similarly complicated, but configurable process with the UniVocity CSV parser, with specific use cases like the ability to define value conversions and column selection. Writing directly from a map or annotated Java Beans is also supported.
<h3 id="flatpackcsvparser">FlatPack CSV Parser</h3>
<a rel="nofollow" target="_blank" href="http://flatpack.sourceforge.net/">FlatPack CSV Parser</a> is fast and more suitable for handling extremely large files, dealing with file sorting before parsing and fixed width parsing. It can be used in a scenario where your CSV does not have a specific delimiter but is comprised of fixed width text for example. The parser also supports column mapping through XML specifications, where the fields in the XML and the data fields in the CSV are in the same order.
The <code>BuffReaderDelimiterFactory</code> allows streaming larger files to avoid everything being contained in memory when parsing data. Columns can also be added, removed, or ignored as needed.
Since the library focusses on being friendly for larger files, it also allows the option to exclude bad data, and add it to an error collection for later processing. This avoids a massive dataset needing to be re-processed due to one or two errors and simplifies error handling.
The library is currently maintained, with the most recent publication being in 2019. It has specific strengths, but can be complicated to set up and understand due to the multitude of options and customization features introduced to handle very specific scenarios that are not RFC4180 compliant.
<h2 id="conclusion">Conclusion</h2>
The most basic CSV reading and writing scenarios can be handled using core Java IO with <code>BufferedReader</code>s , <code>FileWriter</code>s, and customized error handling. However, external libraries provide tried and tested solutions when it comes to more complex operations that involve being able to support larger files that may or may not be RFC 4180 compliant, with varying delimiters and different requirements.
The performance and flexibility of your application depend on the option you choose - some parsers are better at memory management, while others are more flexible and customizable.
You can use this article as a guide to identify which library best suits your needs, and learn the basics of CSV file handling, and reading and writing CSVs in Java.

Jean Fernando

Libraries for Reading and Writing CSVs in Java

<h2 id="introduction">Introduction</h2>
This is the first article in a short series dedicated to <a target="_blank" href="/libraries-for-reading-and-writing-csvs-in-java">Libraries for Reading and Writing CSVs in Java</a>.
<h2 id="readingandwritingcsvsincorejava">Reading and Writing CSVs in Core Java</h2>
Owning to the popularity and widespread use of CSV as a format for data transfer, there are many parser libraries that can be used along with Java.
Third-party parsers define common formats and are able to work with various delimiters, handle special characters, and sometimes even read non-binary data. However, not all programs require all of those features, so it is still important to be able to handle CSV files with core Java, without the use of any additional libraries.
A simple combination of <code>FileReader</code>, <code>BufferedReader</code>, and <code>String.split()</code> can facilitate reading data from CSVs. Let's consider the steps to open a basic CSV file and parse the data it contains:
<ul>
<li>Use <code>FileReader</code> to open the CSV file</li>
<li>Create a <code>BufferedReader</code> and <a target="_blank" href="https://stackabuse.com/reading-a-file-line-by-line-in-java/">read the file line by line</a> until an &quot;End of File&quot; (<a rel="nofollow" target="_blank" href="https://en.wikipedia.org/wiki/End-of-file">EOF</a>) character is reached</li>
<li>Use the <code>String.split()</code> method to identify the comma delimiter and split the row into fields</li>
</ul>
<pre><code class="hljs">BufferedReader csvReader = new BufferedReader(new FileReader(pathToCsv));
while ((row = csvReader.readLine()) != null) {
 String[] data = row.split(&quot;,&quot;);
 // do something with the data
}
csvReader.close();
</code></pre>
The <code>data</code> String array will contain a list of the fields in each row of the file found in the <code>pathToCsv</code> file location. If the CSV file has a delimiter other than a comma, it can be specified in the <code>split</code> method. For example, another common delimeter is the tab for Tab-Separated-Value (TSV) files.
The data can be passed to a separate method for processing or writing to a database from within the loop, or stored in a <a target="_blank" href="/java-collections-the-list-interface/">Java Collection</a> for later use. For example, if you're writing a large amount of data to a database, constraint violations (like primary key violations, for example) caused by human errors when generating the CSV, can be avoided by using a hash map. If there is a duplicate entry in the CSV, the hash map will store the most recent 'read' and overwrite the previous entry.
Since you're writing the parser from scratch you'll need to take care of simple error handling on your own. Like if you're unsure whether the file exists, it is always safer to enclose the read operation within a <code>try/catch</code> block or add logic to determine the existence of the file before processing.
To check whether the file exists, the following modification can be made to our code:
<pre><code class="hljs">File csvFile = new File(pathToCsv);
if (csvFile.isFile()) {
 // create BufferedReader and read data from csv
}
</code></pre>
With some simple error handling and strict requirements on the CSV format, creating a simple parser yourself using core Java components is a task most programmers can take on.
<h3 id="writingcsvsincorejava">Writing CSVs in Core Java</h3>
Most third-party parsers also support writing to CSV files. However, there is a simple way to write to CSV files, just like any other file type, without using any libraries.
The simplest way is to use a <code>FileWriter</code> object and treat the CSV file as any other text file. In our example the data is stored in some <code>List</code> objects, which we just iterate over and append to the writer:
<pre><code class="hljs">// Our example data
List&lt;List&lt;String&gt;&gt; rows = Arrays.asList(
 Arrays.asList(&quot;Jean&quot;, &quot;author&quot;, &quot;Java&quot;),
 Arrays.asList(&quot;David&quot;, &quot;editor&quot;, &quot;Python&quot;),
 Arrays.asList(&quot;Scott&quot;, &quot;editor&quot;, &quot;Node.js&quot;)
);

FileWriter csvWriter = new FileWriter(&quot;new.csv&quot;);
csvWriter.append(&quot;Name&quot;);
csvWriter.append(&quot;,&quot;);
csvWriter.append(&quot;Role&quot;);
csvWriter.append(&quot;,&quot;);
csvWriter.append(&quot;Topic&quot;);
csvWriter.append(&quot;\n&quot;);

for (List&lt;String&gt; rowData : rows) {
 csvWriter.append(String.join(&quot;,&quot;, rowData));
 csvWriter.append(&quot;\n&quot;);
}

csvWriter.flush();
csvWriter.close();
</code></pre>
When using a <code>FileWriter</code> always make sure you flush and close the stream. This improves the performance of the IO operation and indicates that there is no more data to be written to the output stream.
<h2 id="conclusion">Conclusion</h2>
There are several ways to read and write CSV files in Java, the simplest being using Core Java components. Although this also leaves you more vulnerable to bugs and will be less robust than a proven third-party solution.
If you're interested in reading about other ways to read and write CSVs in Java, make sure to check out our other articles:
<ul>
<li><a target="_blank" href="/reading-and-writing-csvs-in-java-with-apache-commons-csv/">Reading and Writing CSVs in Java with Apache Commons CSV</a></li>
<li><a target="_blank" href="/reading-and-writing-csvs-in-java-with-opencsv/">Reading and Writing CSVs in Java with OpenCSV</a></li>
</ul>

Reading and Writing CSVs in Java

Whether you've been programming for decades or just started out, at some point in your career you'll need to share your changes to a codebase. Or maybe if you're like me, you might just be paranoid and want to store everything in a remote repository, like GitHub, for safe-keeping in case you do something stupid on your local machine.
Either way, there are many ways to do so, one of which would be to push a local branch to a remote repo. In this short article that's exactly what I'll go over.
For now let's assume that you've created a new branch in your repository, possibly to implement a new feature or fix a bug:
<pre><code class="hljs">$ git checkout -b &lt;branch-name&gt;
</code></pre>
Now that you have a new branch for your feature, you make some changes and additions to your code, commit it, and are ready to share it with the rest of your team.
Pushing the branch to the remote repository and tracking the upstream branch can be done in one command:
<pre><code class="hljs">$ git push -u &lt;repo-name&gt; &lt;branch-name&gt;
</code></pre>
As you probably guessed, the branch <code>&lt;branch-name&gt;</code> is pushed to <code>&lt;repo-name&gt;</code> in this case.
One important thing to point out is the <code>-u</code> option. This option is an alias for <code>--set-upstream</code>, which will add an upstream tracking reference for the branch you're pushing.
This is useful since adding this tracking reference, among other benefits, makes the specified remote branch become the default for commands like <code>git pull</code> or <code>git rebase</code> when no other arguments are given.
So, a common use of this command looks like this:
<pre><code class="hljs">$ git push -u origin master
</code></pre>
Here we're pushing the &quot;master&quot; branch of our local repository to the remote labeled &quot;origin&quot;. In many cases, &quot;origin&quot; is a remote repo shared by your team, like a repository on GitHub.
This same command can be used for any branch. So if you've been working on fixing a bug in its own branch, named &quot;bug-184&quot;, you can push that as well:
<pre><code class="hljs">$ git push -u origin bug-184
</code></pre>

Scott Robinson

Git: Push Local Branch and Track It

As a beginner programmer, or even for many experienced programmers, Git version control can be difficult to learn and master. Much of the reason, in my opinion, is due to the many different commands that exist and the small differences between them.
One such example is the difference between <code>git fetch</code> and <code>git pull</code>. At first glance the name of the commands don't give much hint as to how they differ, so in this article I'll be explaining the difference between the <code>git fetch</code> and <code>git pull</code> commands.
<h2 id="gitfetch">Git Fetch</h2>
The <code>fetch</code> command retrieves any commits, references (like tags), branches and files from a remote repository, along with any other corresponding objects. However, not all tags are retrieved as this command only takes the ones that point to commits that you are retrieving. Basically this command fetches anything needed to reconstruct the history of the particular branch you're interested in.
The basic syntax is the following:
<pre><code class="hljs">$ git fetch &lt;remote-repo&gt; &lt;remote-branch&gt;
</code></pre>
Specifying <code>&lt;remote-branch&gt;</code> will only fetch changes from that branch. If this parameter is omitted then changes from all branches are retrieved.
The interesting thing about the <code>fetch</code> command is that it doesn't actually affect anything in your local repo. No working changes will be lost, and you'll see no direct affect on your local branches. This is because Git keeps fetched content separate from your own repo's content until it is merged in.
So, let's say you want to view changes for the &quot;master&quot; branch from the &quot;origin&quot; remote repo before deciding to merge them in to your repo. To do this you could use the following commands:
<pre><code class="hljs">$ git fetch origin master
</code></pre>
Now that you have the changes in your repository, you'll likely want to actually view them, which you can do by just checking out the branch:
<pre><code class="hljs">$ git checkout origin/master
</code></pre>
This will allow you to see the changes, and it still isn't merged in to any of your own branches.
A quicker way to view these changes would be to just look at the commit logs, which you can do with:
<pre><code class="hljs">$ git log master..origin/master
</code></pre>
Note that this is considered a &quot;safer&quot; method than <code>pull</code> since it does not actually make any changes to your local branches.
Now that we've seen what <code>fetch</code> does and a bit about how it works, let's take a look at <code>pull</code>.
<h2 id="gitpull">Git Pull</h2>
The <code>git pull</code> command is what I'd call a &quot;high level&quot; command. By that I mean that it performs the actions of a few other Git commands in sequence, which I'll explain more about below. In this section, after I describe the difference between <code>fetch</code> and <code>pull</code>, I'll also briefly talk about the numerous different ways the command can be used.
The general syntax is the following:
<pre><code class="hljs">$ git pull &lt;remote-repo&gt; &lt;remote-branch&gt;
</code></pre>
Both the <code>&lt;remote-repo&gt;</code> and <code>&lt;remote-branch&gt;</code> parameters are optional, as long as your current branch is tracking a remote one.
Probably the simplest way to explain this command, and how it's different from <code>fetch</code>, is that it's an alias for two other Git commands, when used in its default mode: <code>fetch</code> and <code>merge</code>. So by running <code>git pull</code> you are essentially running these two commands in sequence:
<pre><code class="hljs">$ git fetch &lt;remote-repo&gt;
$ git merge FETCH_HEAD
</code></pre>
Here <code>FETCH_HEAD</code> is a reference to tip of the last fetch, which is being merged in to your current branch.
So obviously the big difference between <code>fetch</code> and <code>pull</code> is that <code>pull</code> actually performs a <code>fetch</code> in addition to a <code>merge</code>.
Although depending on the option you give to <code>git pull</code>, it may work differently than this. For example, if you add the <code>--rebase</code> option then it will instead use <code>git rebase</code> instead of <code>git merge</code>.
There is also the <code>--no-commit</code> option, which will perform the <code>merge</code> command, but will (as stated in the official documentation) &quot;pretend the merge failed&quot; and not autocommit it. This allows you to take a look at the changes you just fetched before actually committing it to your code.
There are quite a few more options available, most of which are beyond the scope of this article. I'd recommend taking a look at the <a rel="nofollow" target="_blank" href="https://git-scm.com/docs/git-pull">official documentation</a> for more info.

Git: Difference Between 'git fetch' and 'git pull'

<h2 id="whataredesignpatterns">What are Design Patterns?</h2>
Design Patterns are simply sets of standardized practices used in the software development industry. They represent solutions, provided by the community, to common problems faced in every-day tasks regarding software development.
There's a myriad of design patterns, and you're probably familiar with some of them already. Being familiar with them and knowing them by heart can help you increase the speed and quality of your development.
By using already clearly defined approaches instead of reinventing the wheel, as well as well-known industry standards you both help your team and yourself produce high-quality applications that are easier to maintain and improve.
Another important thing to mention is the uniformity and universality. Instead of explaining a common concept to someone else, you can simply tell them to utilize a certain pattern.
Most of these patterns apply to multiple languages, not just Java, but some, like the J2EE Design Patterns are applicable mostly to Java, or rather Java EE.
There are three main design pattern categories: Creational Patterns, Structural Patterns and Behavioral Patterns, but we'll also dive into J2EE Patterns.
Creational Patterns, as the name implies, are most concerned about solutions and options revolving around instantiating objects, and how to do so more efficiently in the most varied of circumstances.
Structural Patterns are concerned about providing solutions and efficient standards regarding class compositions and object structures. Also, they rely on the concept of inheritance and interfaces to allow multiple objects or classes to work together and form a single working whole.
Behavioral Patterns are concerned about providing solutions regarding object interaction - how do they communicate, how are some dependent on others, and how to segregate them to be both dependent and independent and provide both flexibility and testing capabilities.
J2EE Patterns are concerned about providing solutions regarding Java EE. These patterns are widely accepted by other frameworks and projects, like for an example <a rel="nofollow" target="_blank" href="https://spring.io/">Spring</a>.
<h2 id="designpatternsinjava">Design Patterns in Java</h2>
In that name, we've compiled a list of all the Design Patterns you'll encounter or use as a software developer, implemented in Java.
<h3 id="creationalpatterns">Creational Patterns</h3>
<ul>
<li><a target="_blank" href="/creational-design-patterns-in-java#factorymethod">Factory Method/Template</a></li>
<li><a target="_blank" href="/creational-design-patterns-in-java#abstractfactory">Abstract Factory</a></li>
<li><a target="_blank" href="/creational-design-patterns-in-java#builder">Builder</a></li>
<li><a target="_blank" href="/creational-design-patterns-in-java#prototype">Prototype</a></li>
<li><a target="_blank" href="/creational-design-patterns-in-java#singleton">Singleton</a></li>
</ul>
<h3 id="structuralpatterns">Structural Patterns</h3>
<ul>
<li><a target="_blank" href="/structural-design-patterns-in-java#adapter">Adapter</a></li>
<li><a target="_blank" href="/structural-design-patterns-in-java#bridge">Bridge</a></li>
<li><a target="_blank" href="/structural-design-patterns-in-java#filter">Filter</a></li>
<li><a target="_blank" href="/structural-design-patterns-in-java#composite">Composite</a></li>
<li><a target="_blank" href="/structural-design-patterns-in-java#decorator">Decorator</a></li>
<li><a target="_blank" href="/structural-design-patterns-in-java#facade">Facade</a></li>
<li><a target="_blank" href="/structural-design-patterns-in-java#flyweight">Flyweight</a></li>
<li><a target="_blank" href="/structural-design-patterns-in-java#proxy">Proxy</a></li>
</ul>
<h3 id="behavioralpatterns">Behavioral Patterns</h3>
<ul>
<li><a target="_blank" href="/behavioral-design-patterns-in-java#interpreter">Interpreter</a></li>
<li><a target="_blank" href="/behavioral-design-patterns-in-java#templatemethod">Template Method/Pattern</a></li>
<li><a target="_blank" href="/behavioral-design-patterns-in-java#chainofresponsibility">Chain of Responsibility</a></li>
<li><a target="_blank" href="/behavioral-design-patterns-in-java#command">Command</a></li>
<li><a target="_blank" href="/behavioral-design-patterns-in-java#iterator">Iterator</a></li>
<li><a target="_blank" href="/behavioral-design-patterns-in-java#mediator">Mediator</a></li>
<li><a target="_blank" href="/behavioral-design-patterns-in-java#memento">Memento</a></li>
<li><a target="_blank" href="/behavioral-design-patterns-in-java#observer">Observer</a></li>
<li><a target="_blank" href="/behavioral-design-patterns-in-java#state">State</a></li>
<li><a target="_blank" href="/behavioral-design-patterns-in-java#strategy">Strategy</a></li>
<li><a target="_blank" href="/behavioral-design-patterns-in-java#visitor">Visitor</a></li>
</ul>
<h3 id="j2eepatterns">J2EE Patterns</h3>
<ul>
<li><a target="_blank" href="/java-j2ee-design-patterns/#mvcpattern">MVC Pattern</a></li>
<li><a target="_blank" href="/java-j2ee-design-patterns/#businessdelegatepattern">Business Delegate Pattern</a></li>
<li><a target="_blank" href="/java-j2ee-design-patterns/#compositeentitypattern">Composite Entity Pattern</a></li>
<li><a target="_blank" href="/java-j2ee-design-patterns/#dataaccessobjectpattern">Data Access Object Pattern</a></li>
<li><a target="_blank" href="/java-j2ee-design-patterns/#frontcontrollerpattern">Front Controller Pattern</a></li>
<li><a target="_blank" href="/java-j2ee-design-patterns/#interceptingfilterpattern">Intercepting Filter Pattern</a></li>
<li><a target="_blank" href="/java-j2ee-design-patterns/#servicelocatorpattern">Service Locator Pattern</a></li>
<li><a target="_blank" href="/java-j2ee-design-patterns/#transferobjectpattern">Transfer Object Pattern</a></li>
</ul>

David Landup

There are three main design pattern categories: Creational Patterns, Structural Patterns and Behavioral Patterns, but we'll also dive into J2EE Patterns.

Design Patterns in Java

Did you make a mistake in naming your Git branch? Or maybe &quot;branch-2&quot; wasn't descriptive enough? Luckily in Git you can rename a local branch pretty easily. And while it is also possible with remote branches, the process is a bit more involved with the use of a workaround, but still works as intended.
In this short article I'll show you how to rename Git branches for both local and remote repositories.
<h2 id="renamealocalgitbranch">Rename a Local Git Branch</h2>
To rename a local branch, you'll want to use the <code>branch</code> command like this:
<pre><code class="hljs">$ git branch -m &lt;old-branch-name&gt; &lt;new-branch-name&gt;
</code></pre>
The <code>-m</code> option is an alias for <code>--move</code>, which is analog to the Unix <code>mv</code> command.
Continuing with the convention we saw with the <a target="_blank" href="/git-delete-branch-locally-and-remotely/">delete branch option</a>, capitalizing the flag as <code>-M</code>, which is an alias for <code>--move --force</code>, allows you to &quot;force&quot; the change. Using the option in this way will let you rename the branch even if the new branch name already exists in your repository.
If you're wanting to rename the branch that is currently checked out, then you can omit the <code>&lt;old-branch-name&gt;</code> option, which looks like this:
<pre><code class="hljs">$ git branch -m &lt;new-branch-name&gt;
</code></pre>
<h2 id="renamearemotegitbranch">Rename a Remote Git Branch</h2>
Renaming a remote branch is a bit more involved, and isn't actually possible in the same way it is for renaming local branches. To do it, you'll need to rename the local branch, delete the remote branch, and then push the renamed local branch to the remote repo again.
In terms of Git commands, here is how the process looks:
<pre><code class="hljs">$ git branch -m &lt;old-branch-name&gt; &lt;new-branch-name&gt;
$ git push &lt;remote-repo&gt; -d &lt;old-branch-name&gt;
$ git push &lt;remote-repo&gt; &lt;new-branch-name&gt;
$ git checkout &lt;new-branch-name&gt;
$ git push &lt;remote-repo&gt; -u &lt;new-branch-name&gt;
</code></pre>
In plain English, here is what is happening line-by-line:
<ol>
<li>Rename the local branch using the same method shown the first section</li>
<li>Delete the remote branch that is to be renamed</li>
<li>Push the new branch to the remote repo</li>
<li>Switch to the new branch</li>
<li>Reset the upstream reference for the renamed branch</li>
</ol>
Once you understand what is going on, it isn't too bad, but it certainly requires more steps than simply renaming a local branch.

Git: Rename a Local and Remote Branch

Dhananjay Singh

In this tutorial, we'll dive into configuring Spring Boot properties through property files and values.

Spring Boot: Configuring Properties

If I've learned anything in my 15+ years of programming, it's that mistakes are common, and I make a lot of them. This equally applies to version control tools as well. Whether you accidentally commit changes, or just realized your previous committed code isn't what you wanted, oftentimes you'll need to revert a previous commit in Git.
In this article I'll show a few ways to revert your commits, depending on your use-case. This is a complicated topic (which is true for many Git topics in general), so make sure you follow the instructions that best suit your needs.
<h2 id="deleteunpublishedcommits">Delete Unpublished Commits</h2>
If you haven't yet published your commits to a remote repository, like GitHub, then you can essentially delete previous commits by using the <code>reset</code> command.
While this is an effective solution, it's a dangerous one since you're rewriting history and leaving the &quot;deleted&quot; commits unreferenced, or &quot;orphaned&quot;. The only way to find and recover these unreferenced commits is with <code>git reflog</code>.
The <code>reset</code> command has three different options, two of which we'll describe here:
<pre><code class="hljs">$ git reset --hard &lt;hash-or-ref&gt;
</code></pre>
Using the <code>--hard</code> option, everything is reverted back to the specific commit. This includes the commit history reference pointers, the staging index, and your working directory.
This means that by using just this command you'll not only revert to a previous commit, but you'll lose all working changes in the process. To avoid losing any working changes, you can use the <code>stash</code> and <code>stash pop</code> commands:
<pre><code class="hljs">$ git stash
$ git reset --hard &lt;hash-or-ref&gt;
$ git stash pop
</code></pre>
The <code>stash</code> command saves your working changes (without any commits or changes to the tree), and then <code>stash pop</code> brings them back.
The other option you may consider is the <code>--soft</code> option. This option works much the same way as <code>git reset --hard &lt;hash-or-ref&gt;</code>, but it only affects the commit history, not your working directory or staging index.
<pre><code class="hljs">$ git reset --soft &lt;hash-or-ref&gt;
</code></pre>
So if you have uncommitted changes that you want to keep, then this is likely the option you want.
<h2 id="deletingpublishedcommits">Deleting Published Commits</h2>
So let's say you committed your code and then pushed it to the remote repository. At this point it's highly advised that you do not use something like <code>git reset</code> since you'd be rewriting history.
Instead, the recommended approach would be to use the <code>revert</code> command. This command works by undoing changes that were made in the specific commit by creating a new commit and not actually removing any previous commits. This is ideal for published changes because then the true history of the repo is preserved. Here is the command:
<pre><code class="hljs">$ git revert &lt;hash-or-ref&gt;
</code></pre>
So let's say you have a text file in your repo with the following content:
<pre><code class="hljs">This is my sample text
</code></pre>
And then you change it to:
<pre><code class="hljs">This is my awesome sample text
</code></pre>
Your commit history might look something like this:
<pre><code class="hljs">$ git log --pretty=oneline
676ec97a9cb2cebbb5c77904bbc61ced05b86f52 Added &#x27;awesome&#x27; to text
735c5b43bf4b5b7107a9cc3f6614a3890e2889f6 Initial commit
</code></pre>
If we decide we don't want &quot;awesome&quot; in our text anymore, but we don't want to delete the <code>676ec</code> commit, we can use <code>revert</code> to undo that change:
<pre><code class="hljs">$ git revert 676ec
[master f68e546] Revert &quot;Added &#x27;awesome&#x27; to text&quot;
 1 file changed, 1 insertion(+), 1 deletion(-)
</code></pre>
After being prompted to enter a commit message, we can now see in our commit history that there is actually a new commit:
<pre><code class="hljs">$ git log --pretty=oneline
f68e546ac2ae240f22b2676b5aec499aab27f1ca Revert &quot;Added &#x27;awesome&#x27; to text&quot;
676ec97a9cb2cebbb5c77904bbc61ced05b86f52 Added &#x27;awesome&#x27; to text
735c5b43bf4b5b7107a9cc3f6614a3890e2889f6 Initial commit
</code></pre>
As a result of this, the first and third commits represent the exact same project state. The commit has been reverted, and no history was lost.
Note that there are quite a few other ways to use this command, like if you want to revert back 2 commits, you can use:
<pre><code class="hljs">$ git revert HEAD~2
</code></pre>
Or if you want to revert many non-continuous commits you specify them individually:
<pre><code class="hljs">$ git revert 676ec 735c5
</code></pre>
<h2 id="cherrypickingacommit">Cherry-Picking a Commit</h2>
In Git, &quot;cherry-picking&quot; refers to the process of applying a specific commit from one branch to another. This allows you to selectively apply changes made in the past without affecting the current state of the repository.
To cherry-pick a commit, first identify the commit hash of the commit you want to apply. You can do this by running the <code>git log</code> command and looking for the hash of the commit you want to cherry-pick.
Once you have identified the commit hash, switch to the branch you want to apply the changes to, and run the following command:
<pre><code class="hljs">$ git cherry-pick &lt;commit-hash&gt;
</code></pre>
This will apply the changes made in the specified commit to the current branch, creating a new commit that contains only those changes. If the changes conflict with the current state of the branch, Git will prompt you to resolve the conflicts before continuing.
It's important to note that cherry-picking a commit does not merge the entire branch that the commit is on. It only applies the changes made in the specified commit. This can be useful if you want to apply a specific fix or feature from one branch to another without merging the entire branch.
Cherry-picking a commit can also be used to revert changes made in a previous commit. To do this, simply cherry-pick the commit you want to revert, and then apply the changes to the current branch. This will create a new commit that undoes the changes made in the original commit.
<h2 id="temporarilycheckoutapreviouscommit">Temporarily Checkout a Previous Commit</h2>
By &quot;reverting a commit&quot;, you might mean that you temporarily want to go back to a previous state in your repo, but without making any actual changes to the tree. In this case you'd probably just want to checkout the commit, allowing you to go back to master or any other state when you're done:
<pre><code class="hljs">$ git checkout &lt;hash-or-ref&gt;
</code></pre>
This will change your working directory to the contents of that commit, as well as the location HEAD points to, none of which is irreversible. Any changes you make here can either be committed to a branch or stashed for later use.

Git: Revert to a Previous Commit

While it's very common to need to create and delete branches in Git, unfortunately the syntax isn't very easy to remember for everyone. Even as a long-time user of Git I need to look up the syntax as a reminder, which admittedly is actually the main motivation behind writing this short article.
The next two sections will describe how to delete branches in Git, for both local and remote repositories, along with some alternative flags and syntax.
<h2 id="deletingalocalbranch">Deleting a Local Branch</h2>
This is the easy part since you're just working on the Git repository that you (presumably) own and control. Here is the command you'll likely need:
<pre><code class="hljs">$ git branch -d &lt;local_branch&gt;
</code></pre>
Here the <code>-d</code> option tells Git to delete the branch specified, and is actually an alias for the <code>--delete</code> flag. Another alternative is to use <code>-D</code> instead, which forces the delete and is an alias for <code>--delete --force</code>:
<pre><code class="hljs">$ git branch -D &lt;local_branch&gt;
</code></pre>
This will delete the branch, even if it is not merged yet, so keep this in mind when using it. In general you should use the <code>-d</code> option since it's considered safer.
Another thing to note - you can't delete the branch that branch that is currently checked out, even with the <code>-D</code> option, which we show here with the <code>issue-260</code> branch:
<pre><code class="hljs">$ git checkout issue-260
Switched to branch &#x27;issue-260&#x27;
$ git branch -D issue-260
error: Cannot delete branch &#x27;issue-260&#x27; checked out at &#x27;/Users/scott/projects/git-examples&#x27;
</code></pre>
First, checkout a different branch, like <code>master</code> or your dev branch, and then delete it:
<pre><code class="hljs">$ git checkout master
Switched to branch &#x27;master&#x27;
Your branch is up-to-date with &#x27;origin/master&#x27;.
$ git branch -d issue-260
Deleted branch issue-260 (was 3acde55).
</code></pre>
Now we're able to delete the branch without issue.
<h2 id="deletingaremotebranch">Deleting a Remote Branch</h2>
Deleting a remote branch is slightly more involved than deleting a local one since you're working with a repository that is likely not even on your machine. The syntax you can use also depends on your version of Git, so take note.
<pre><code class="hljs">$ git push &lt;remote_repo&gt; --delete &lt;remote_branch&gt;
</code></pre>
This was added to Git in v1.7.0, and in Git v2.8.0 they added the ability to use <code>-d</code> instead of the full <code>--delete</code> flag.
The format shown above, in my opinion, is the easiest syntax to remember. But if you have an older version of Git (v1.5.0+) then you'll need to use this instead:
<pre><code class="hljs">$ git push &lt;remote_repo&gt; :&lt;remote_branch&gt;
</code></pre>
To remember this, Scott Chacon puts it very well in <a rel="nofollow" target="_blank" href="http://git-scm.com/book/en/Git-Branching-Remote-Branches">his book</a>:
<blockquote>
A way to remember this command is by recalling the <code>git push [remotename] [localbranch]:[remotebranch]</code> syntax that we went over a bit earlier. If you leave off the <code>[localbranch]</code> portion, then you're basically saying, &quot;Take nothing on my side and make it be <code>[remotebranch]</code>.&quot;
</blockquote>
Now that the branch is gone from the remote repository, other machines will want to update themselves as well. To do this, they'll want to <code>fetch</code> the update:
<pre><code class="hljs">$ git fetch --all --prune
</code></pre>
The <code>--prune</code> option tells Git to remove all remote-tracking references (i.e. our branch) that no longer exist in the remote repo. Keep in mind, however, that this pruning does not apply to tags. You'll want to use <code>--prune-tags</code> for that.