3 Reasons Why Java Is The Future Of Big Data, And The IoT

While Java’s been around for a little over 20 years, Big Data has only been a buzzword in corporate environments for a little over 5 years. While the concept has existed much longer than that, the majority of us hadn’t heard the word. Because it’s so new to so many of us, the term “Big 
Data” is still evolving, and can mean different things to different people.

To most people, the term describes any voluminous amount of structure data that can be used, mined, or better understood for information or intentional use.

“The rate at which we’re generating data is rapidly outpacing our ability to analyze it,” Professor Patrick Wolfe, Executive Director of the University College of London’s Big Data Institute, tells Business Insider. “The trick here is to turn these massive data streams from a liability into a strength.”

According to Antonio Regalado, Senior Editor for the MIT Technology Review, because of the sheer volume of data being being created, only about 0.5% of all data is ever analyzed. With this problem in mind, it’s no wonder developers are working around the clock to increase our computation capacity to understand and translate this vast amount of data into actionable insight.

With the amount of data we produce projected to continue its torrid, exponential growth, the need to analyze that vast amount of data will only continue to increase as well.
The gold standard in batch computational computing power to this point has been Hadoop, a free, java-based programming framework sponsored by the Apache Software Foundation that’s capable of processing large amount of data sets. With the past predicated on Java, it’s no wonder Java is expected to be the gold standard of big data and the Internet of Things for the foreseeable future.

  1. The big guys are turning to Java

    When Facebook speaks, the rest of the tech community listens. Running with the likes of Apple, and Google, Facebook has been on the main-stage of technology development for over ten years. In a recent statement about the future of their mobile app, Facebook has completely ruled out a return to HTML5, and is dedicating their future to its own Reactive Native, JavaScript framework.

    Originally reported by The Register, Facebook’s Director of Developer Infrastructure, David Mortenson, said the company will focus its mobile application development exclusively on the open-source React Native JavaScript Framework.

  2. 3 Great collection of open source libraries

    With its roots deeply engrained in open-source communities, a huge benefit to using Java is the amount of publicly available code that already exists. Companies like Apache, Google and other industry giants have even contributed to these vast libraries of code and information. With the amount of readily available code for use by anyone who needs to use it, the Internet of Things’ early development will benefit greatly from this already vast expanse of information and knowledge.

    It’s never a bad idea to search for a functionality code in Google, before writing it for yourself. After 20 years, there’s a pretty good chance that it’s already coded, tested and available for use.

  3. Java is everywhere already

    Java’s already on desktop, mobile, tablet, PC and Mac, and so are the programmers and developers who make it happen. Not only that, there’s also surging popularity in learning how to code Java. This abundance of information and thirst for learning it is why a lot of organizations prefer to choose Java for the development of apps over any other language.

    Its relevancy on every platform combined with the abundance of open-source code Java currently available makes Java one of the most in-demand skills now, and in the future.

The future of data analysis is, unequivocally, Java.

Parcelable vs. Java Serialization in Android App Development

Android developers often face a predicament while passing object references to activities of whether to go with the Java Serialization method or opt for
Android Parcelable. This blog is my attempt to compare the two techniques and cite an example to help decide which one of these is the best approach for
passing an object from one activity to another.

Passing primitive data types like string, integer, float, etc. through intents is quite easy in Android. All you have to do is put the data with unique
key in intents and send it to another activity. If a user wants to send Java objects through intent, Java class should be implemented using the Parcelable
interface. Serialization, on the other hand, is a Java interface that allows users to implement the interface which gets marked as Serializable.

During the Android application development process, developers often have to send Java class objects from one activity to another activity using the intent.
Developers can opt from the two types of object passing techniques, i.e. Serialization and Parcelable of object.  The fact that Parcelable is faster than
Serialization makes it a preferred choice of approach while passing an object. Here’s why:


Android Parcelable implementation allows objects to read and write from Parcels which can contain flattened data inside message containers.

If a developer wants to convert a Java object into Parcelable, then the best way to do so is by implementing the Parcelable interface and overriding the
writeToParcel() methods in its own class. The first step is to override the writeToParcel() method and  write all object members into parcel objects. The
second is to create a static Parcelable.Creator object to de-serialize the Java object.

Differences between Serialization and Parcelable

Parcelable and Serialization are used for marshaling and unmarshaling Java objects.  Differences between the two are often cited around implementation
techniques and performance results. From my experience, I have come to identify the following differences in both the approaches:

·         Parcelable is well documented in the Android SDK; serialization on the other hand is available in Java. It is for this very reason that Android
developers prefer Parcelable over the Serialization technique.

·         In Parcelable, developers write custom code for marshaling and unmarshaling so it creates less garbage objects in comparison to Serialization.
The performance of Parcelable over Serialization dramatically improves (around two times faster), because of this custom implementation.

·         Serialization is a marker interface, which implies the user cannot marshal the data according to their requirements. In Serialization, a marshaling
operation is performed on a Java Virtual Machine (JVM) using the Java reflection API. This helps identify the Java objects member and behavior, but also
ends up creating a lot of garbage objects. Due to this, the Serialization process is slow in comparison to Parcelable.

I ran a test and here are my findings:

Intent intent = new Intent(ParcelableActivity.this, RegistrationSuccessActivity.class);
/// for Parcelable list
intent.putParcelableArrayListExtra(“data”, pacableArray);
/// retrieve in another activity
RegistrationPogo registrationPogo= getIntent().getParcelableExtra(“data”);
package com.threepillar.bestpractice.ui;
import Java.util.HashMap;
import Java.util.LinkedHashMap;
import Java.util.Map;
import Android.os.Parcel;
import Android.os.Parcelable;
import Android.widget.EditText;
public class RegistrationPogo implements Parcelable {
String firstName = “”, lastName = “”, emailAddress = “”, phoneNumber = “”,
city = “”, state = “”;
int zipCode;
HashMap<string, String> mapRegData = new HashMap<string, String>();
public HashMap<string, String> getMapRegData() {
return mapRegData;
public void setMapRegData(HashMap<string, String> mapRegData) {
this.mapRegData = mapRegData;
public String getFirstName() {
return firstName;
public void setFirstName(String firstName) {
this.firstName = firstName;
public String getLastName() {
return lastName;
public void setLastName(String lastName) {
this.lastName = lastName;
public String getEmailAddress() {
return emailAddress;
public void setEmailAddress(String emailAddress) {
this.emailAddress = emailAddress;
public String getPhoneNumber() {
return phoneNumber;
public void setPhoneNumber(String phoneNumber) {
this.phoneNumber = phoneNumber;
public String getCity() {
return city;
public void setCity(String city) {
this.city = city;
public String getState() {
return state;
public void setState(String state) {
this.state = state;
public int getZipCode() {
return zipCode;
public void setZipCode(int zipCode) {
this.zipCode = zipCode;
public int describeContents() {
// TODO Auto-generated method stub
return 0;
public RegistrationPogo() {
public void writeToParcel(Parcel dest, int flags) {
// TODO Auto-generated method stub
final int N = mapRegData.size();
// dest.writeInt(N);
if (N > 0) {
for (Map.Entry<string, String> entry : mapRegData.entrySet()) {
String dat = entry.getValue();
public static final Parcelable.Creator CREATOR = new Parcelable.Creator() {
public RegistrationPogo createFromParcel(Parcel in) {
return new RegistrationPogo(in);
public RegistrationPogo[] newArray(int size) {
return new RegistrationPogo[size];
private RegistrationPogo(Parcel in) {
firstName = in.readString();
lastName = in.readString();
emailAddress = in.readString();
phoneNumber = in.readString();
city = in.readString();
state = in.readString();
zipCode = in.readInt();
final int N = in.readInt();
for (int i = 0; i < N; i++) {
String key = in.readString();
String value = in.readString();
mapRegData.put(key, value);

Speed Testing Results

In this example, Android Parcelable came out to be faster than the Java Serialization technique. One of the main reasons was the fact that Parcelable is
fully customizable, allowing developers to convert required data into Parcelable. Serialization is a marker interface as it converts an object into a stream
using the Java reflection API. Due to this it ends up creating a number of garbage objects during the stream conversation process. So my final verdict
will be in favor of Android Parcelable over the Serialization approach. I have tested both performances on HTC Desire, Nexus 4 and Samsung Galaxy S3 devices.