Link ~> http://blog.jhades.org/javascript-for-java-developers/

This post will go over the Javascript language from the point of view of a Java developer, focusing on the differences between the two languages and the frequent pain points. We will go over the following:

Objects Only, No Classes
Functions are just Values
The 'this' Keyword
Classic vs Prototypal Inheritance
Constructors vs Constructor Functions
Closures vs Lambdas
Encapsulation and Modules
Block Scope and Hoisting
Why Javascript in the Java World ?

A lot of Java frontend development work is done using Java/XML based frameworks like JSF or GWT. The framework developers themselves need to know Javascript, but in principle the application developers don't. However the reality is that:

For doing custom component development in for example Primefaces (JSF), it's important to know Javascript and jQuery.
In GWT, integrating at least some third-party Javascript widgets is common and cost effective.
The end result is that Javascript is usually needed to do at least the last 5 to 10% of frontend work, even using Java frameworks. Also it's starting to get more and more used for polyglot enterprise development, alongside Angular for example.

The good news is that, besides a few gotchas that we will get into, Javascript is a very learneable language for a Java developer.

Objects Only - No Classes

One of the most surprising things about Javascript is that although it's an object oriented language, there are no classes (although the new Ecmascript 6 version will have them).

Take for example this program, that initializes an empty object and set's two properties:

?
1
2
3
4
5
// create an empty object - no class was needed !!
var superhero = {};

superhero.name = 'Superman';
superhero.strength = 100;
Javascript objects are just like a Java HashMap of related properties, where the keys are Strings only. The following would be the 'equivalent' Java code:

?
1
2
3
4
Map<String,Object> superhero = new HashMap<>();

superhero.put("name","Superman";
superhero.put("strength", 100);
This means that a Javascript object is just a multi-level 'hash map' of key/value pairs, with no class definition needed.

Functions Are Just Values

Functions in Javascript are just values of type Function, it's a simple as that! Take for example:

?
1
2
3
4
5
var flyFunction = function() {
console.log('Flying like a bird!');
};

superhero.fly = flyFunction;
This creates a function (a value of type Function) and assigns it to a variable flyFunction. A new property named fly is then created in the superhero object, that can be invoked like this:

?
1
2
// prints 'Flying like a bird!' to the console
superhero.fly();
Java does not have the equivalent of the Javascript Function type, but almost. Take for example the SuperHero class that takes a Power function:

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public interface Power {
void use();
}

public class SuperHero {

private Power flyPower;

public void setFly(Power flyPower) {
this.flyPower = flyPower;
}

public void fly() {
flyPower.use();
}
}
This is how to pass SuperHero a function in Java 7 and 8:

?
1
2
3
4
5
6
7
8
9
10
11
12
13
// Java 7 equivalent
Power flyFunction = new Power() {
@Override
public void use() {
System.out.println("Flying like a bird ...";
}
};

// Java 8 equivalent
superman.setFly(
()->System.out.println("Flying like a bird ...");

superman.fly();
So although a Function type does not exist in Java 8, this ends up not preventing a 'Javascript-like' functional programming style.

But if we pass functions around, what happens to the meaning of the
this keyword?

The 'this' Keyword Usage

What Javascript allows to do with this is quite surprising compared to the Java world. Let's start with an example:

?
1
2
3
4
5
6
7
8
9
10
var superman = {

heroName: 'Superman',

sayHello: function() {
console.log("Hello, I'm " + this.heroName );
}
};

superman.sayHello();
This program creates an object superman with two properties: a String
heroName and a Function named sayHello. Running this program outputs as expected Hello, I'm Superman.

What if we pass the function around?

By passing around sayHello, we can easily end up in a context where there is no heroName property:

?
1
2
3
var failThis = superman.sayHello;

failThis();
Running this snippet would give as output: Hello, I'm undefined.

Why does this not work anymore?

This is because the variable failThis belongs to the global scope, which contains no member variable named heroName. To solve this:

In Javascript the value of the this keyword is completely overridable to be anything that we want!

?
1
2
// overrides 'this' with superman
hello.call(superman);
The snippet above would print again Hello, I'm Superman. This means that the value of this depends on both the context on which the function is called, and on how the function is called.

Classic vs Prototypal Inheritance

In Javascript, there is no class inheritance, instead objects can inherit directly from other objects. The way this works is that each object has an implicit property that points to a 'parent' object.

That property is called __proto__, and the parent object is called the object's prototype, hence the name Prototypal Inheritance.

How does prototype work?

When looking up a property, Javascript will try to find the property in the object itself. If it does not find it then it tries in it's prototype, and so on. For example:

?
1
2
3
4
5
6
7
8
9
var avengersHero = {
editor: 'Marvel'
};

var ironMan = {};

ironMan.__proto__ = avengersHero;

console.log('Iron Man is copyrighted by ' + ironMan.editor);
This snippet will output Iron Man is copyrighted by Marvel.

As we can see, although the ironMan object is empty, it's prototype does contain the property editor, which get's found.

How does this compare with Java inheritance?

Let's now say that the rights for the Avengers where bought by DC Comics:

?
1
avengersHero.editor = 'DC Comics';
If we call ironMan.editor again, we now get Iron Man is copyrighted by DC Comics. All the existing object instances with the avengersHero prototype now see DC Comics without having to be recreated.

This mechanism is very simple and very powerful. Anything that can be done with class inheritance can be done with prototypal inheritance. But what about constructors?

Constructors vs Constructor Functions

In Javascript an attempt was made to make object creation similar to languages like Java. Let's take for example:

?
1
2
3
4
function SuperHero(name, strength) {
this.name = name;
this.strength = strength;
}
Notice the capitalized name, indicating that it's a constructor function. Let's see how it can be used:

?
1
2
3
var superman = new SuperHero('Superman', 100);

console.log('Hello, my name is ' + superman.name);
This code snippet outputs Hello, my name is Superman.

You might think that this looks just like Java, and that is exactly the point! What this new syntax really does is to it creates a new empty object, and then calls the constructor function by forcing this to be the newly created object.

Why is this syntax not recommended then?

Let's say that we want to specify that all super heroes have a
sayHello method. This could be done by putting the sayHello function in a common prototype object:

?
1
2
3
4
5
6
7
8
9
10
11
function SuperHero(name, strength) {
this.name = name;
this.strength = strength;
}

SuperHero.prototype.sayHello = function() {
console.log('Hello, my name is ' + this.name);
}

var superman = new SuperHero('Superman', 100);
superman.sayHello();
This would output Hello, my name is Superman.

But the syntax SuperHero.prototype.sayHello looks anything but Java like! The new operator mechanism sort of half looks like Java but at the same time is completely different.

Is there a recommended alternative to new?

The recommended way to go is to ignore the Javascript new operator altogether and use Object.create:

?
1
2
3
4
5
6
7
8
var superHeroPrototype = {
sayHello: function() {
console.log('Hello, my name is ' + this.name);
}
};

var superman = Object.create(superHeroPrototype);
superman.name = 'Superman';
Unlike the new operator, one thing that Javascript absolutely got right where Closures.

Closures vs Lambdas

Javascript Closures are not that different from Java anonymous inner classes used in a certain way. take for example the FlyingHero class:

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public interface FlyCommand {
public void fly();
}

public class FlyingHero {

private String name;

public FlyingHero(String name) {
this.name = name;
}

public void fly(FlyCommand flyCommand) {
flyCommand.fly();
}
}
We can can pass it a fly command like this in Java 8:

?
1
2
3
String destination = "Mars";
superMan.fly(() -> System.out.println("Flying to " +
destination ));
The output of this snippet is Flying to Mars. Notice that the FlyCommand lambda had to 'remember' the variable destination, because it needs it for executing the fly method later.

This notion of a function that remembers about variables outside it's block scope for later use is called a Closure in Javascript. For further details, have a look at this blog post Really Understanding Javascript Closures.

What is the main difference between Lambdas and Closures?

In Javascript a closure looks like this:

?
1
2
3
4
5
6
7
var destination = 'Mars';

var fly = function() {
console.log('Fly to ' + destination);
}

fly();
The Javascript closure, unlike the Java Lambda does not have the constraint that the destination variable must be immutable (or effectively immutable since Java .

This seemingly innocuous difference is actually a 'killer' feature of Javascript closures, because it allows them to be used for creating encapsulated modules.

Modules and Encapsulation

There are no classes in Javascript and no public/ private modifiers, but then again take a look at this:

?
1
2
3
4
5
6
7
8
9
10
function createHero(heroName) {

var name = heroName;

return {
fly: function(destination) {
console.log(name + ' flying to ' + destination);
}
};
}
Here a function createHero is being defined, which returns an object which has a function fly. The fly function 'remembers' name when needed.

Continue ~> http://blog.jhades.org/javascript-for-java-developers/