Monday, November 26, 2018

Should we migrate projects from Java 8 to Java 9 or 10

If you're on Java 8, you might be thinking should we migrate the projects from Java 8 to Java 9 or 10?

Big NO!!

It doesn’t worth the effort. It’s better if you migrate your projects directly to Java 11 which is an LTS version.

Java 9 and Java 10 are non-LTS versions.

“For product releases after Java SE 8, Oracle will designate a release, every three years, as a Long-Term-Support (LTS) release. Java SE 11 (18.9 LTS) is an LTS release. For the purposes of Oracle Premier Support, non‑LTS releases are considered a cumulative set of implementation enhancements of the most recent LTS release. Once a new feature release is made available, any previous non‑LTS release will be considered superseded. For example, Java SE 9 was a non‑LTS release and immediately superseded by Java SE 10 (also non‑LTS), Java SE 10 in turn is immediately superseded by Java SE 11. Java SE 11 however is an LTS release, and therefore Oracle Customers will receive Oracle Premier Support and periodic update releases, even after Java SE 12 is released.”

For long-term support, Oracle is recommending remaining on Java 8 or move to Java 11.  Refer to the following:

Java 8 Release support:
Premier support: March 2022
Extended support: March 2025

Java 9:
Premier support: March 2018
Extended support: Not available

Java 10:
Premier support: Sept 2018
Extended support: Not available

Java 11:
Premier support: Sept 2023
Extended support: Sept 2026

Wednesday, November 21, 2018

Selecting multiple lines of code in Github file

To select a single line of code, we can just click on the line number to highlight the line. That provides the url with a single line code selection.


To select multiple lines of code, click the number of the first line in the range to highlight the line of code. Then, hover over the last line of the code range, press Shift, and click the line number to highlight the range.


Monday, November 19, 2018

Which one to use OpenJDK or OracleJDK?

With Java 11 release, there is no difference between OpenJDK and OracleJDK. All the features and licenses are exactly the same. Oracle has moved the Java license from BCL to GPL2 (+ ClassPath Exception ) license which is the same license used by OpenJDK as well.

Broadly, I can categorize them based on my understanding:
  1. OpenJDK
  2. OracleJDK for free 
  3. OracleJDK with commercial - Java SE subscription Model. 

When to use what?

  • Use OpenJDK if you want to customize VM and language features and package it with your product.
  • If you don’t want to make any changes in JDK and VM, also not looking for any support from Oracle - then prefer OracleJDK for free.
  • If you have many applications which are still running with the older JDK versions like 6,7,8 which are not under LTS now, but you are still looking for security updates and support from Oracle - then go for OracleJDK with a commercial support.

Earlier, there were some commercial features(Heap Analyzer, Java Flight recorder,etc.) in OracleJDK but after Java 9 they slowly offloaded commercial features from the OracleJDK and contributed to OpenJDK.

Now with Java 11 - features, licenses and release cycle dates everything is same! 


Long live Java!!

How to run a sprint retrospective

This is a very nice post on how to run a sprint retrospective meeting

Wednesday, November 14, 2018

Git commit message format standards

Here is my earlier post on this:

Here is something new which I found. Probably, industry will align with these standards sooner or later.

Format suggested:
<type>[optional scope]: <description>
[optional body]

[optional footer]

The commit contains the following structural elements, to communicate intent to the consumers of your library:
  1. fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in semantic versioning).
  2. feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in semantic versioning).
  3. BREAKING CHANGE: a commit that has the text BREAKING CHANGE: at the beginning of its optional body or footer section introduces a breaking API change (correlating with MAJOR in semantic versioning). A breaking change can be part of commits of any type. e.g., a fix:feat: & chore: types would all be valid, in addition to any other type.
  4. Others: commit types other than fix: and feat: are allowed, for example commitlint-config-conventional (based on the the Angular convention) recommends chore:docs:style:refactor:perf:test:, and others. We also recommend improvement for commits that improve a current implementation without adding a new feature or fixing a bug. Notice these types are not mandated by the conventional commits specification, and have no implicit effect in semantic versioning (unless they include a BREAKING CHANGE, which is NOT recommended). 
    A scope may be provided to a commit’s type, to provide additional contextual information and is contained within parenthesis, e.g., feat(parser): add ability to parse arrays.