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.

From WORA to WANTA

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?

Webtide

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.

Overall

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_framework
spring_boot2

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

Lattice

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

References:

A taste of what's new in Java 9

by Arkadiusz Sokolowski
Presentation was partially based on this article

Java has been here for a long time - since 1995, which is exactly 20 years. Usually Java SE is released every 2 years, but there is a huge gap between Java SE 6 (2006) and Java SE 7 (2011) due to the confusion around the deal with which Oracle bought Sun. However with Java SE 9 the tradition is restored. Java SE 09 should be available in September 2016, while an FC version should be available for testing at the end of 2015.

New versioning scheme

One of the new things Java 9 will bring is a new versioning scheme. Up to now minor releases containing anything else but security fixes were multiples of 20, while security releases themselves were odd numbers incremented by 5 (or 6 if needed to preserve the odd number).

The new scheme would be MAJOR.MINOR.SECURITY, e.g.
  • 1.8.0 will be 8.0.0
  • 1.8.0_05 will be 8.0.1
  • 1.8.0_11 will be 8.0.2
  • 1.8.0_20 will be 8.1.2
  • 1.8.0_25 will be 8.1.3

JEP222 - jshell

jshell is a utility, much like the JavaScript console in web browsers, that would allow you to quickly evaluate some Java code. There is a nice Heroku jshell demo you could deploy and play around with. It takes about 15 min to set the entire app up - you just create a Heroku account, download the heroku toolbelt and follow the steps on the GitHub page.

Disclaimer : Heroku does not play well with company firewalls :(

And yes - there is autocomplete. Nice!

JEP230 - JDK Benchmark Suite

This suite will be used to compare JDK 9 with JDK 8 and see if there is any regression to the standard libraries. It provides stable micro benchmarks based on JMH.

JEP110 - HTTP/2 client

My (lately) favourite topic - Java 9 will have built-in support for HTTP/2.

HttpRequest req = HttpRequest
   .create(new URI("http://www.ocado.com"))
   .body(noBody())
   .GET();
CompletableFuture asyncResp = req.sendAsync();
Thread.sleep(10);
if (!asyncResp.isDone()) {
   asyncResp.cancel(true);
   System.err.println("timeout");
   return;
}
HttpResponse response = asyncResp.get();

JEP159 - JVM logging

Introduce a common logging system which would allow advanced hacking methods such as logging for threads, processes, using of decorates and much more.

JEP213 - Project Coin

Some lightweight language adjustments, such as
  • allow @SaveVargs on private instance methods
  • allow effectively final variables in try-with-resources
  • more type inference with generics
  • underscore will no longer be a valid variable name (somebody actually did this?)
  • support of private methods in interfaces (non abstract methods of an interface would be able to share code)
Also ...
  • JEP228 - add more diagnostic commands - the hotspot would report a wider set of data when being diagnosed 
  • JEP143 - Improve Contended Locking
  • JEP193 - Variable Handles - (still in proposal state) Have you ever used sun.misc.Unsafe? Haven't even heard of it? If so - then you are a lucky man and can see what it is here.
  • JEP199 - the smart Java compiler - used to build the JDK itself, it would now be made available to the general public, one of its interesting features is compiling classes in parallel
  • JEP216 - Process Import Statements Correctly - really bugfix for some corner cases in importing
  • JEP219 - Datagram Transport Layer Security (DTLS)
  • JEP224 - HTML5 javadoc - as of JDK 8 the JavaDoc tool generates pages in HTML 4.01
  • JEP227 - Support for UTF 7.0
  • JEP254 - Compact strings - the internal representation of strings is altered, yet again
  • JEP243 - Java-Level JVM Compiler Interface - making the compiler pluggable
  • JEP236 - Parser API for Nashhorn - will be able to hook into Nashhorn
  • JEP237 - Linux/AArch64 Port - more like integrating the support for ARM(v8) as the latter was already done
  • JEP247 - Compile fol Older Platform Versions - enhance the javac so it can compile Java programs to be run on selected older version of the platform
  • JEP248 - Make G1 the Default Garbage Collector
  • JEP250 - Store Interned Strings in CDS Archives

The star of the show - project Jigsaw (JEP200, JEP201)

Project Jigsaw is the golden bullet that is supposed to remove the need for complex modularization frameworks, such as OSGi. It's aim is to reduce the JAR hell, allow for unexpressed or transitive dependencies, provide the facilities for manual dependency management, hide some internal/private packages, provide system instead of manual security and as a whole reduce the size of the JRE.


Jigsaw is really the crown jewel of Java 9. Unfortunately this post has already become too large and this topic alone could take a separate blog post.

For more information on project Jigsaw you can check these resources :

26 November 2015

JCP process

by Patrick Curran
Presentation was based on this article

Patrick's presentation had a quite entertaining introduction, convincing the audience of the need of standardization. I already knew about the standards for shipping containers - something that allowed a shipment of any sort to quickly change it's transport - from a ship, to a plane, to a train - with relative ease and allowing the shipping industry to transport large quantities of goods for a relatively low price. But I was kind of surprised that standards exist also in unlikely places - from chocolate bars (otherwise how would vending machines work?) to music, color, etc.

"The million dollar question is : are we are artisans or engineers?"

He continued his argument by giving the example that if bridges are built like software we would never drive over them: "Oops, the bridge just crashed".

What is a standard 

Aside from the obvious definition of what a standard is - an established norm to be utilized when solving a problem - the presentation covered the two major types of standards:

  • De facto standards - when a product becomes so popular and widely established that it becomes a standard without any specific body (besides the company that created it) establishing it as such
  • De jure standards - more formal, require an organization to stand behind them

"It is generally agreed that standards need to be open."

Of course a big reason for that is vendor lock. If you develop an open source project without it implementing an open standard this might trap your clients, as they would have no other choice than to work with you as long as they use it. While some companies actively attempt to achieve vendor locks, their partners are less likely to adopt a product that is closed.

JSR process


The above is driven by a committee of several leads, experts and members (part of the Java community, mostly large users of the platform). The typical process is that a new concept has is as follows :



There is a simplified JSR process by accepting a new concept - associate contributor
"Adopt a JSR". It is an initiative lead by the Java User Groups to improve Java standards that already bears its fruits.

Java 2 Days - 2015 - Recap

What's new and all is old


This year's edition of the Java 2 Days had a lot of repeated topics from previous editions of the conference, but also a some cool new stuff.

Web services seem to still be a hype and there were a lot of topics about them. The same goes for micro services although, I have to say, I saw a huge improvement in the technologies that facilitate their development.

Reactive development, functional development and JavaScript were also very popular, as technologies that solve problems in a better way than the ones that already exist. Reactive development attempts to solve the painful problem that legacy applications have long had - being unresponsive in cases such as when the load is high, being unable to cope with the changing ecosystem, being stale to dynamic events. Functional development is a rather good match for reactive applications, being able to provide an easy way to achieve most of its goals.

JavaScript is the old new messiah - some time ago we all witnessed how desktop applications were replaced by web applications. But in the attempt to achieve RIA some implementations have chosen different technologies than JavaScript, such as Flash or Java applets. Others used Java-based technologies such as JSF. JavaScript was avoided in early days due to browser compatibility issues and some security concerns. But as time passed by the ecosystem surrounding JavaScript grew exponentially, problems with it got solved, and now we see a second shift to building / rebuilding applications using, sometimes exclusively - such as the case of the new web application behind mobile.de, JavaScript.

The fresh new Java 9 was something that also caught my interest. It is due next year, but an early release is expected this December. HTTP2 is also knocking on the door - although it is perhaps too early to rush into conclusions - it is set to make web services obsolete and bring balance to the force.

Here are some more details on all of the topics that caught my eye :

Java

  • JCP process - by Patrick Curran - Patrick is Chair of the Java Community Process and his passionate presentation was the opening of the Java 2 Days conference. He talked a lot about what makes Java what it is, the power of open source and just how important it is to have a large community support a popular platform.
  • A taste of what's new in Java 9 - by Arkadiusz Sokolowski - a nice intro to what we should expect in the new version of Java. And I just got my Java 8 certificate ... 

Web Services and Micro Services

  • Is there anything new in the field of Web Services  - by Reza Rahman - Reza is a long time Java EE evangelist, he talked about some misconceptions of what microservices are and when it is good to use them and then showed where Java EE fits in this picture
  • Web Socket in no time - by Andrew Lombardi - mostly a repetition of his presentation from two years ago
  • Cloud native with Springby Kenny Bastani - very practical demo of how the guys at Spring see the deployment of a Web Services in the cloud
  • The untimely demise of Web Services or HTTP2 (my own caption) - by Mihail Stoynov - a member of the Bulgarian Java Users Group (BG JUG), Mihail talked about how they utilize HTTP2 in the user group's web site and what challenges still exist in utilizing it

JavaScript, Reactive development, Functional development

  • Everything a Java Developer should know about the JavaScript landscape - by Geertjan Weilenga - I didn't really know what to expect from this lecture, but it turned out to be a very in-depth overview of all the frameworks and tools that one might want to use if he wants to start using JavaScript in one of his projects
  • 3 things you need you know to think reactive - by Manuel Bernhardt - Manuel does very interesting things for a living, such as trying to sabotage a working system just to see how it handles it. He talked a lot about the things he has seen and how we can really build a solid, reactive application.
  • Functional development with Clojure - by John Stevenson - Closure is often compared with Scala and most of the time I've been convinced that Scala wins the battle, but John actually showed that, as usual, it really depends on what you want to do, giving a great example of good usage of Closure