If you found the contents in this blog useful, then please make a donation to keep this blog running. You can make donations via Skrill with email address

Tuesday, October 3, 2017

Java + Spring Boot implementation of Blockchain

Blockchain is the buzz word these days as it is technology used by Cryptocurrencies which is taking over the world like crazy. There are so many articles written on the Theory of Blockchain like this one but there are very little implementations. But recently I stumbled upon an article by Daniel van Flymen who happens to have written a Python based implementation of the Blockchain.

According to him and I am pretty sure many Software Engineers would agree that the best way to learn something is to actually implement it so that you learn more than you get to learn while reading theory documentation.

So this inspired me to write Java + Spring Boot based Implementation of Daniel's work so that I can learn the Blockchain workings. For everyone who is interested following is a basic version of how a Blockchain will look like in the wild.

So Daniel talks a lot about the details of the Blockchain which you can read but in short following are the Steps required to write a Blockchain implementation.

  1. Building a Blockchain
  2. Building an API to access the Blockchain
  3. Interacting with the Blockchain 
  4. Consensus
You can see all above Steps implemented in Java + Spring Boot at

Monday, September 18, 2017

Server Sent Event Processing in Spring MVC 4.2

In a previous post I spoke about the features Spring MVC 4.2 has from Streaming Request Processing. I have discussed how we can StreamingResponseBody to send large data asynchronously in a streaming manner. 

In this post I am planning to talk about SseEmitter which is another way to send semi structured data clients in an asynchronous streaming manner.

If you want to learn more about the definition and structure of a Server Sent Event you can read the Mozilla Documentation. But in short a Server Sent Event is a push event from a server which will be taking place inside of a single TCP/IP Socket connection from Client to Server. This event being push means it eliminates the need for constant polling of the Server for data thus reduces unwanted load on Server and the Client can receive the data in real time.

In Spring MVC following controller code can be written to send server sent events easily and in the client end Javascript can be used to read these events and present in the web page. For demo purpose I am showing a live Cricket match score and commentary coming down to a Web page client in real time. The server code will look like below; 

And Javascript client client code will look like below;

And as you can see from the image below there is only one request being initiated to /score end point but multiple commentary data being received through that long lived connection.

Saturday, September 9, 2017

Spring Web Flux - The Non Blocking Asynchronous Functional Reactive Web Framework - 2

Spring Web Flux Framework can be used with its latest Release Candidate Release 5.0.0.RC3 if you want to try it out. You just need to add the Spring Milestone Repository in your gradle or maven file.

I have written the following service which emulates a delay of maximum 1000 milliseconds in a service to test how the conventional Spring Web MVC vs Spring Web Flux work.

And the following controller implementations one with a Blocking conventional Spring Web MVC Controller method which returns a list to get people and a Non Blocking Spring Web Flux Controller method which returns a Fluxwhich is a defferred result and processed differently.

And Tested sending 1000 concurrent requests to both methods using a Gatling test. The Application was running inside of a Tomcat Container.

Spring Web MVC results were

And Spring Web Flux results were

If you compare the 99th Percentile, Max and Mean response times of the both results you can see Spring Web Flux is considerably faster without any code changes to improve performance. This is a promising sign. The numbers can be improved even more if we use the Netty Reactive Servers instead of conventional Tomcat servers in my understanding.

Spring Web Flux - The Non Blocking Asynchronous Functional Reactive Web Framework - 1

Spring has a very diverse eco system of projects from Batch Jobs to Web Security. The best part of Spring project is that they are always ahead of time and do innovative work which sometimes are adopted by the Java Platform itself. For Example the @Autowired Annotation introduced by Spring was later standardized in JSR 330 as @Inject

Spring 5 is something they are working on right now (Have released 5.0.0 Release Candidate 3 Version as of writing this post) and has a lot of innovative features. Following are a list of those features;
  • Reactive programming: introducing our Spring WebFlux framework built on Reactor 3.1, with support for RxJava 1.3 & 2.1 and running on Tomcat, Jetty, Netty or Undertow.
  • Functional style with Java 8 & Kotlin: several API refinements and Kotlin extensions across the framework, in particular for bean registration and functional web endpoints.
  • Integration with Java EE 8 APIs: support for Servlet 4.0, Bean Validation 2.0, JPA 2.2, as well as the JSON Binding API (as an alternative to Jackson/Gson in Spring MVC).
  • Ready for JDK 9: fully aligned with JDK 9 at runtime, on the classpath as well as the module path (on the latter: as filename-based “automatic modules” for the time being).
One of most interesting is the introduction of Spring Web Flux - A Non Blocking Functional Reactive Web Framework. Reactive Programming has been alive for sometime in form of RxJava project and many more programming frameworks like Akka, NodeJS etc.

In simple terms reactive programming is about writing non blocking software that are asynchronous and event driven which require a small number of threads to scale vertically (Scale up inside a single JVM) instead of horizontally (Scale out to different nodes by means of clustering). 

If we take a look at the Spring Web MVC framework which was a Synchronous Blocking Framework based on Servlet (Prior to Servlet 3.x). Every Request Reaching a Spring Web MVC Controller would use the Request Thread that came a long with the Client Request to cater that request and will be blocking, Which meant that the scale-ability was bound to the maximum number of Request Threads a Web Container had. 

This was partially solved by the introduction of Servlet 3.x with asynchronous servlets where now a Request Thread would delegate the task of catering the request to a Separate Thread. Spring Web MVC framework allowed to return a DefferedResult from a Controller method which meant that the Request thread will not be blocking until the processing of the request by the Controller method.

Spring Web Flux uses a completely new approach of using Reactive Streams instead of the Servlet API. A key aspect of reactive is that it won't overwhelm the consumers when producers produce at a rate which is faster than the consumers can consume. This concept is called back pressure.

Reactive Programming will not let this happen (Image Courtesy : iStock)



Monday, August 28, 2017

Java 9 : The Future 3

Why is a module path better than a class path? 

Class path 

  • Class path can get in trouble when multiple classpath elements contain the same package 
  • Class path is searched (linearly) every time a new class is requested 

Module Path 

  • Modules form a partition of packages 
    • no package can be in more than one runtime module
  • Modules perform a directed search 
    • Once the runtime finds a module,it remembers its packages 
    • Never has to search for those packages again 
    • Class loading becomes O(1), not O(n)

So now instead Dependency List as with Classpath, we have a Module Dependency Graph which is Directed Graph on Dependencies. 

Following is the Dependency Graph for module which is the Entire JVM Utilities available out of the box.

Breaking a single rt.jar into modules which can be defined in the graph shown above was the reason why Java 9 release took longer than other Java releases. It must have been very difficult task for the Engineering team and hats off to them.

So what about Backward Compatibility??

All Old Codes which are not modularized (available in Classpath) will be put into a one big module called the "Unnamed Module". That module will by default
  • Requires every other module
  • Exports / opens every package available in that module 
  • Maximum compatibility with classpath behavior 
This sort of behavior allows Java code to incrementally modularized when and if required. 

Tuesday, August 8, 2017

Java 9 : The Future 2

This is a continuation of Java 9 : Future 1 Post

Modules enforce Strong Encapsulation as we discussed in the previous post. Now a Package is not public by default to all other modules unless it is explicitly exported in the Module Descriptor.

Can Class D from Module A access Class F from Module B?

With the Module Descriptors mentioned below, yes it is possible as Module A has mentioned as it requires Module B and Module B has exports package Z.

Strong Encapsulation

  • Module must require other Modules to be used in them.
  • Module exports packages to specific Modules or to all.
  • Module opens packages explicitly for reflection.
  • Accessibility is enforced by compiler, JVM and Reflection.

But why Modules again?

Remember packages starting with sun.* or com.* that were available in rt.jar (JVM Runtime) which were only specific for certain JVM Vendor Implementations and not all. Java programmers have been constantly warned not to use these packages as they will break Platform Independence. But up until Java 9 Modules there was no way to completely stop developers from using those packages.

Enter java.base Module

Following is the Module Descriptor for java.base module. With this as you can see only certain packages are exported and com.*/sun.* packages are only available within the module.

module java.base { 
      exports java.lang;  
      exports java.util; 

Every Module in Java 9 implicitly will have require to java.base. Just like every class in Java will automatically import java.lang.*. 

So what does this means?

This means that now there can be a Java Application which is 100% modular with all Jar files being modules. Which means we can't use classpath in those scenarios. 

Enter Module Path

  • Path containing directories which contain modules
  • Modules can be exploded directories, or modular JARs (other forms too) 
  • The runtime searches the module path when looking for a module.
Plus a Java Application can be an hybrid of Modular as well as Backward Compatible Application in those cases there will be both a Module Path and Class Path.

To be continued..

Wednesday, August 2, 2017

Java 9 : The Future 1

There is much so talk and hype about Java 9 and its features. There are so many posts about Java 9 and specially on Java 9 Jigshaw or Modules. As a Java Developer for almost a decade now, I was really cautious and concerned about the new features of Java 9 and wanted to learn about it in depth. What better way than learning from the creators of Java 9 itself. Recently I got the chance to view an InfoQ video on a Presentation done by Karen Kinnear who is the Technical Lead for the Hotspot Java Virtual Machine Runtime team at Oracle. This lead me to realize Java 9 is far beyond Modules and the in depth nature of the Modules and the necessity for such time and resource consuming change in the Java Language Framework and Java Virtual Machine.

To start off if we look at all the features available in Java 9, we can list the followings;

102: Process API Updates
110: HTTP 2 Client
143: Improve Contended Locking
158: Unified JVM Logging
165: Compiler Control
193: Variable Handles
197: Segmented Code Cache
199: Smart Java Compilation, Phase Two
200: The Modular JDK
201: Modular Source Code
211: Elide Deprecation Warnings on Import Statements
212: Resolve Lint and Doclint Warnings
213: Milling Project Coin
214: Remove GC Combinations Deprecated in JDK 8
215: Tiered Attribution for javac
216: Process Import Statements Correctly
217: Annotations Pipeline 2.0
219: Datagram Transport Layer Security (DTLS)
220: Modular Run-Time Images
221: Simplified Doclet API
222: jshell: The Java Shell (Read-Eval-Print Loop)
223: New Version-String Scheme
224: HTML5 Javadoc
225: Javadoc Search
226: UTF-8 Property Files
227: Unicode 7.0
228: Add More Diagnostic Commands
229: Create PKCS12 Keystores by Default
231: Remove Launch-Time JRE Version Selection
232: Improve Secure Application Performance
233: Generate Run-Time Compiler Tests Automatically
235: Test Class-File Attributes Generated by javac
236: Parser API for Nashorn
237: Linux/AArch64 Port
238: Multi-Release JAR Files
240: Remove the JVM TI hprof Agent
241: Remove the jhat Tool
243: Java-Level JVM Compiler Interface
244: TLS Application-Layer Protocol Negotiation Extension
245: Validate JVM Command-Line Flag Arguments
246: Leverage CPU Instructions for GHASH and RSA
247: Compile for Older Platform Versions
248: Make G1 the Default Garbage Collector
249: OCSP Stapling for TLS
250: Store Interned Strings in CDS Archives
251: Multi-Resolution Images
252: Use CLDR Locale Data by Default
253: Prepare JavaFX UI Controls & CSS APIs for Modularization
254: Compact Strings
255: Merge Selected Xerces 2.11.0 Updates into JAXP
256: BeanInfo Annotations
257: Update JavaFX/Media to Newer Version of GStreamer
258: HarfBuzz Font-Layout Engine
259: Stack-Walking API
260: Encapsulate Most Internal APIs
261: Module System
262: TIFF Image I/O
263: HiDPI Graphics on Windows and Linux
264: Platform Logging API and Service
265: Marlin Graphics Renderer
266: More Concurrency Updates
267: Unicode 8.0
268: XML Catalogs
269: Convenience Factory Methods for Collections
270: Reserved Stack Areas for Critical Sections
271: Unified GC Logging
272: Platform-Specific Desktop Features
273: DRBG-Based SecureRandom Implementations
274: Enhanced Method Handles

Modular JDK feature is just a small part of it but is a significant one, in this part I am planning to talk about it in depth with some coding examples;

The Why of Modular JDK?

The main reason for a Modular JDK was to avoid Classpath Hell. People who have experience Deploying Java Applications in Production or Pre Production Environments would agree that creating and maintaining the Classpath for a Java Application with the focus to enable future maintenance is a Nightmare and can become a Hell very soon if not done properly. 

OSGi Framework tried to address this by creating an Engine in which Classloader Isolated Bundles can run with Strict Contracts to Export and Import Dependency. This was a good approach to solve Classpath hell but the problem was an OSGi Bundle is a Jar on Steroids (Had to have a META-INF/MANIFEST.MF Bundle Descriptor). So Normal Jar Files had to be converted to a OSGi Bundle before those can be used inside an OSGi Engine. Making OSGi Bundles of already existing millions of Jars and maintaining them through latest versions in its entirety could be classified as Hell. So OSGi didn't catch up to its fullest potential. 

Plus JVM Classpath scanning was Sequential where when a Class is requested by an Application running in JVM it will scan the Classpath Jars one after the other until it finds the requested Class. This is an O(n) problem which needed to be addressed to improve performance.

The Official Java Team had to come up with something off the shelf. This is the reason Why Modular JDK was created with all the difficulties.

The How of the Modular JDK?

Up until Java 8, there were only 2 concepts of code containers; 

1. Package (Public to all)
2. Class inside Package (default or package private, Public to all)

From Java 9 there are 3 concepts of code containers;

1. Module (A module is group of packages with a Module Descriptor)
2. Package inside Module (Public to All modules which can access the module contain the package)
3. Class inside Package (Public within module, Public to certain modules, Public to all modules)

How to create a Module in Java 9?

A module is a same old Java Jar file with a Module Descriptor. A Module Descriptor is a Java Source file with the name residing in the root of the source directory. 

The Structure of the Module Descriptor