08 April 2016

06 January 2016

The battle between Oracle and Google could heavily influence the fate of Android


Oracle and Google have this South Korea / North Korea relationship of fierce rivalry, that makes us question what is good and what is right. Oracle made this huge claim that Google have infringed their rights by using Java technologies (APIs to be more specific) in their hugely successful Android platform. Initially the claim was dismissed by the District Court, but then the US Appeals Court overturned this decision and sent the matter back to the District Court for further proceedings.

Google now rely on their initial claim that the usage of the infringed code could be considered "fair use", but in the same time Oracle have waived their fists, claiming newly released devices continue to infringe their rights and Google aims at destroying the Java market.

New developments

A new chapter in this, now 6 years old, battle is Google deciding to incorporate OpenJDK in Andoid. This step would most probably not have any impact on the ongoing legal battle, but it does bring up a few questions. Although the obvious speculation could be that this is a step towards settling the feud outside the court, Google have described this step as one that would help involve the community even more in developing the Android platform, something that they have aimed from the days it was initially created.

The Android teams have supported and improved on their own the Apache Harmony-based runtime after it was dropped by Apache in 2011. Without a doubt removing it in favor of the OpenJDK would release a lot of pressure from their development teams.

Is there a catch?

There might be. Andreas Gal, the former CTO of Mozilla, argued that this decision is
"a huge change [that] will have far-reaching implications for Android and the Android ecosystem"
His major concern is that of licensing and particularly would Oracle try to leverage it's control over the OpenJDK, affecting decision about the future of the Android platform. Although Google could easily decide to fork the OpenJDK themselves if they find the way it is evolving contrary to their plans of developing Android, thas would again lead them to square one - having to maintain a port of the Java runtime themselves, without the help of the community.

Another part of his argument is the huge change that is required in order to actually make this technological shift a fact. The Apache Harmony and OpenJDK runtimes have been developed in parallel for a number of years and have thus taken different paths. One could easily expect issues during this migration (consider the amount of application built over the Apache Harmony Andoid) and even worse - performance optimization hacks that could suddenly stop working or require development.

27 November 2015

Everything a Java Developer should know about the JavaScript landscape

by Geertjan Weilenga
Presentation was based on this article

The industry is ever changing and the latest changes introduced 3 new concepts :

  1. The concept of multiple devices requiring responsive UI design
  2. Browsers are everywhere (and by everywhere I mean everywhere, my watch has one)
  3. Single page applications (SPA)
This caused a few changes to the way we use existing frameworks :
  1. HTML is now an application framework and not just a text markup language
  2. CSS is now all about media
  3. An entire universe of frameworks and tools
  4. JavaScript is taking it's place as the assembly language of the web
Here are the 10 tips that Geertjan gave :

Resist the hype

If it weren't in first place I'd put it there, but it seems that me and him are on the same page. One good pattern is to consider supplementing an existing application instead of changing it, e.g. adding mobile functionality. Another question one might want to ask himself is "do my users actually need this", before embarking on a holy crusade aimed at changing the technology or/and architecture of the application.

Think of HTML as an application framework

Shake up the old prejudice and embrace HTML as a full fledged application framework. Avoid using supplements (such as Adobe Flash), new features need to be based on HTML, CSS and JavaScript. See if there aren't components in the HTML framework you are not aware of (e.g.datalist, shadow root or shadow DOM)

"HTML has become a lot more interesting"

CSS i also different than what it used to be

CSS is now capable of creating media queries and thus creating UIs that are rendered in a different way depending on the size of the display of the devices used. See example here.

Response.js is a framework that fully takes into account responsiveness allowing you to define breakpoints and then executing specific actions when these breakpoints are hit.

Evaluate framework vs. library

If Angular is not for me than perhaps I need to build my own framework? There are a lot of libraries which could be used, in combination, so that specific goals are met, some of them include:
  • Prototype
  • jQuery
  • underscore.js
  • dojo tookit
  • MooTools
  • Grunt (Ant/Maven for JavaScript)
  • Gulp (a better version of Grunt)
  • Brunch (a better version of Gulp)
  • Backbone
  • Ember
  • Knockout (focuses on only one thing - two-way data binding)
  • Meteor
  • AngularJS (focuses on all-in-one-solution)
  • React (the new AngularJS)
Component libraries such as :
  • PrimeFaces
  • yUI
  • KendoUI
  • Bootstrap UI
  • Yeoman - good for scaffolding
  • Node JS - a full fledged JS backend server

Incorporate modularity

EcmaScript 6.0 comes with built in modularity, but in older versions this could be achieved with require.js or Browserfy.

Evaluate the abstractions

Do not worry about volatility

Hard advice for an enterprise developer, but the truth is most of these frameworks will die off in 2-3 years, which is a typical lifespan for a JS framework. This is why most people do not code millions of lines of code on JavaScript. It is typical to rewrite your UI frontend every 1.5 years.


Write Once Run Everywhere to Write Once, Never Touch Again

Evaluate corporate frameworks

  • DoubleClick by Google
  • SpectIngular by ING (based on Angular)
  • Salesforce Lightning Platform by Salesforce
  • MobileFirst Platform Foundation by IBM
  • Oracle JET by Oracle 
Most of them combine a lot of other frameworks inside them and act as aggregators.

JavaScript is the assembly language of the web

Assembly is created for a particular platform, JavaScript is created for browsers. As such we want to treat it like any other assembly language :
  • Never try to read it
  • Instead transpire to it from other more friendly languages
  • DukeScript - has a view layer in HTML, everything else is in Java, uses maven archetypes

Where do we go after Http 1.1 – Http2

by Mihail Stoyanov
Presentation was based on this article

What's the problem with HTTP 1?

We are so used to the web today that we rarely take into account what happens behind the scenes when we open a web page. Take for account the portal of the CNN news agency. The home page contains over 100 pictures and resources besides the page itself. 
  • Using HTTP 1- for each resource a new TCP connection is established, in order to request it. That is 100 TCP connections and over 2 MB of data that needs to be downloaded for a single page. Quite wasteful!
  • Using HTTP 1.1 - we have keep alive there and could send multiple requests for a single TCP connection, but since it is working in a serial manner if that one TCP connection it is slow all the resources would be downloaded slowly
  • In both cases headers are repeated for each request

Here enters HTTP2

HTTP2 begun it's path to becoming a standard as SPDY in 2009. Google then announced it would start working on a way to speed up the web. At that time HTTP has reigned for over 12 years, being standardized in 1997.

HTTP2 defines streams on top of the TCP/IP stack, a form of TCP over TCP. Since they are separate packages if the responses for one of them are slow, the others would still continue to be fetched.

Each stream would have a structure inside it called a frame, the frame types being HEADERS, DATA, SETTINGS and PUSH_PROMISE. A typical conversation between a server and a client could start like that :
  • client would send HEADERS
  • server would respond
  • client will then send DATA
  • etc.
Because of this sequence headers can be reused reducing network traffic.

Who uses this?


Dealing with HTTP2

  • Browsers don't really play well with HTTP2 wel yet
  • Headers could give away HTTP2, Chrome has chrome://net-internals/#http2
  • Burp Suite
  • ZAP
  • cURL
  • Wireshark - handles SSL with private key only, browsers support only strong crypto with HTTP2, see perfect forward secrecy

Deploying HTTP2 apps

There is a list of all known implementations of the HTTP2 standard in GitHub.
  •  Tomcat
  • Undertow - limited usage
  •  Jetty
  •  Nginx after version 1.9.5
  •  Apache after version 2.4.17
The presentation was cut off here, but the slides in the beginning of this article contain some interesting hints on how one could play along with the jprime.io web site to test HTTP2.


Sooner or later HTTP2 is going to phase out all previous implementations of the HTTP protocol. At this point it is still the ground of pioneers, but the adaptation will grow and with it - the necessary tooling and framework support. Java 9 is just one of the upcoming platforms that would include a full fledged HTTP 2 client supported and there are other that already have (as mentioned in the article).

So look out world. HTTP2 is coming.

Building a Distributed Data Processing Pipeline Using Spring Cloud Data Flow

by Kenny Bastani
Presentation was based on this article

Cloud native

Basically, when you take away all the unnecessary, complicated terms, cloud native means that an applications is build using the microservices architecture and is deployed in a cloud environment. Typically the code of the application is put in a vessel such as a container, so that new instances of the application could easily be deployed (heard of "pets vs cattle" servers?)

Spring Boot

What Spring Boot is is effectively a microframework for microservices. It packs all the necessary harnessing for a microservice, including the actual runtime, and allows the developer to focus on the business logic. Here is a quick introduction to Spring Boot.


Spring Cloud

Spring Cloud, on the other hand, is yet another degree of abstraction away from the core Spring functionality. It could provide the services you've created with utilities such as :
  • centralized configuration
  • service registration and discovery
  • routing
  • service-to-service calls
  • load balancing
  • circuit breakers, global locks, leadership election and cluster state
  • distributed messaging


Spring plays nice with Lattice, an open source project that runs containers on a cluster. Since Spring "wraps" the functionality that Lattice provides (such as load-balancing, health management, etc.) all these come at no expense to us.

Is there anything new in the field of Web Services

by Reza Rahman
Presentation was based on this article

The term "micro services" has been used a lot in the software industry but there hasn't been a very clear definition of what it really means.

In its essence this phenomenon is simply breaking down large and complex applications into smaller, independent (in terms of deployment) parts.

And because it has reached the point of becoming a full fledged technology hype there are both a lot of success stories, where microservices are adopted with great success, and a lot of failures where misconceptions about how they are supposed to work have lead to unnecessary increase of complexity of the system, unbearable management and disappointing results.

What successful microservices usually focus on :

  • creating components that work in a service oriented architecture (SOA)
  • using lightweight and popular protocols like REST for communication
  • utilizing some messaging (e.g. JMS) technology in cases where there is a lot of chatter between the components
What creators of microservices should avoid :
  • EJBs are hardly the best technology to build microservices with
  • focus on building ridiculously small services
  • CI, DevOps and granular testing are often hard to achieve
The need to build microservices in the first place is often rooted in large, monolithic applications, where the team has grown so much and the codebase - so complex, that maintenance has become a nightmare. Even worse - in the modern world a successful application needs to be very elastic - it needs to scale easily so it could fit it's users needs and also provide some advanced availability failover mechanisms. Typically this is very hard to achieve with a monolithic applications. Microservices to the rescue!

Hype vs reality

Microservices come with a cost.
  • They require a much more elaborate form of administration, deployment and monitoring
  • They increase the complexity of testing, debugging and diagnostics
  • They also add new challenges such as the one with code sharing and defining module boundaries
  • They operate under some false assumptions (see Fallacies of distributed computing)
(map of the Netflix microservices, source )

Where is Java EE in this picture

Here is a good example of converting a monolithic application to a set of microservices using Java EE