Tuesday, September 15, 2015

JDK 9: Highlights from The State of the Module System

Mark Reinhold's The State of the Module System (SOMS) was published earlier this month and provides an information-packed readable "informal overview of enhancements to the Java SE Platform prototyped in Project Jigsaw and proposed as the starting point for JSR 376." In this post, I summarize and highlight some of concepts and terms I found interesting while reading the document.

  • The State of the Module System states that a subset of the features discussed in the document will be used regularly by Java developers. These features and concepts are "module declarations, modular JAR files, module graphs, module paths, and unnamed modules."
  • A module is a "fundamental new kind of Java program component" that is "a named, self-describing collection of code and data."
  • "A module declares which other modules it requires in order to be compiled and run."
  • "A module declares which ... packages it exports" to other modules.
  • A module declaration is "a new construct of the Java programming language" that provides "a module’s self-description."
    • Convention is to place "source code for a module declaration" in a "file named module-info.java at the root of the module’s source-file hierarchy."
    • This module-info.java file specification of requires and exports is analogous to how OSGi uses the JAR MANIFEST.MF file to specify Import-Package and Export-Package.
  • "Module names, like package names, must not conflict."
  • "A module’s declaration does not include a version string, nor constraints upon the version strings of the modules upon which it depends."
  • "A modular JAR file is like an ordinary JAR file in all possible ways, except that it also includes a module-info.class file in its root directory."
  • "Modular JAR files allow the maintainer of a library to ship a single artifact that will work both as a module, on Java 9 and later, and as a regular JAR file on the class path, on all releases."
  • "The base module defines and exports all of the platform’s core packages," "is named java.base," is "the only module known specifically to the module system," "is always present," is depended upon by all other modules, and depends on no other modules.
  • All "platform modules" begin with the "java." prefix and "are likely to include "java.sql for database connectivity, java.xml for XML processing, and java.logging for logging."
  • The prefix "jdk." is applied to the names of "modules that are not defined in the Java SE 9 Platform Specification," but are "specific to the JDK."
  • Implied Readability: The keyword public can be added after the requires keyword to state that a given module's readable module can be read by dependent modules that read it. In other words, if module B references a package provided by module C as requires public, then that package is readable by module A that can read module B.
  • "The loose coupling of program components via service interfaces and service providers" is facilitated in the Java module system by use of the keywords provides ... with ... to indicate when a module provides an implementation of a service and by the use of the keyword uses to indicate when a module uses a provided service.
  • Because a given class is associated with a single module, Class::getModule() will allow access to a class's associated module.
  • "Every class loader has a unique unnamed module" from which types are loaded that are not associated with packages exposed by a module. A given class loader's unnamed module can be retrieved with new method ClassLoader::getUnnamedModule.
    • An unnamed module can read all other modules and can be read by all other modules.
    • Allows existing classpath-based applications to run in Java SE 9 (backwards compatibility).
  • "JMOD" is the "provisional" name for a "new artifact format" that "goes beyond JAR files" for holding "native code, configuration files, and other kinds of data that do not fit naturally ... into JAR files." This is currently implemented as part of the JDK and potentially could be standardized in Java SE at a later point.

The items summarized above don't include the "Advanced Topics" covered in "The State of the Module System" such as qualified exports, increasing readability, and layers. The original document is also worth reading for its more in-depth explanations, brief code listings, and illustrative graphics.

Project Jigsaw and OSGi

Project Jigsaw, like OSGi, aims for greater modularity in Java-based applications. I look forward to seeing if the built-in modularity support can provide some of the same advantages that OSGi provides while at the same time eliminating or reducing some of the disadvantages associated with OSGi. In the article Mule Drop OSGi For Being Too Complex, Jessica Thornsby has summarized some developers' thoughts regarding the perceived disadvantage of OSGi that have led Spring and Mule, among others, to stop using OSGi. The Thornsby article quotes Dmitry Sklyut, Kirk Knoerschild, and Ian Skerrett, who suggest that better tooling, better documentation (including by the community), better exposure at conferences, and more familiarity through use would help OSGi adoption and help overcome the perceived steep learning curve and complexity.

I will be curious to see if having modularity built-in to the Java platform will almost automatically bring some of the things that OSGi advocates have argued would increase OSGi's adoption. I suspect that Project Jigsaw, by being built into the platform will have better tooling support, better exposure to general Java developers, and will be more widely and generally covered in the Java developer community (blogs, conferences, books, etc.). With these advantages, I also wonder if Java 9 and Jigsaw will cause current users of OSGi to move away from OSGi or if those users will find creative ways to use the two together or will do what they can (such as use of unnamed modules) to use OSGi instead of Jigsaw. Because OSGi works on versions of Java prior to Java 9 and Jigsaw will only work on Java 9 and later, there will probably be no hurry to move OSGi-based applications to Jigsaw until Java 9 adoption heats up. An interesting discussion on current and forthcoming Java modularity approaches is available in Modularity in Java 9: Stacking up with Project Jigsaw, Penrose, and OSGi.

Cited / Related Resources

Saturday, September 12, 2015

JAR Manifest Class-Path is Not for Java Application Launcher Only

I've known almost since I started learning about Java that the Class-Path header field in a Manifest file specifies the relative runtime classpath for executable JARs (JARs with application starting point specified by another manifest header called Main-Class). A colleague recently ran into an issue that surprised me because it proved that a JAR file's Manifest's Class-Path entry also influences the compile-time classpath when the containing JAR is included on the classpath while running javac. This post demonstrates this new-to-me nuance.

The section "Adding Classes to the JAR File's Classpath" of the Deployment Trail of The Java Tutorials states, "You specify classes to include in the Class-Path header field in the manifest file of an applet or application." This same section also states, "By using the Class-Path header in the manifest, you can avoid having to specify a long -classpath flag when invoking Java to run the your application." These two sentences essentially summarize how I've always thought of the Class-Path header in a manifest file: as the classpath for the containing JAR being executed via the Java application launcher (java executable).

It turns out that the Class-Path entry in a JAR's manifest affects the Java compiler (javac) just as it impacts the Java application launcher (java). To demonstrate this, I'm going to use a simple interface (PersonIF), a simple class (Person) that implements that interface, and a simple class Main that uses the class that implements the interface. The code listings are shown next for these.

public interface PersonIF
   void sayHello();
import static java.lang.System.out;

public class Person implements PersonIF
   public void sayHello()
public class Main
   public static void main(final String[] arguments)
      final Person person = new Person();

As can be seen from the code listings above, class Main depends upon (uses) class Person and class Person depends upon (implements) PersonIF. I will intentionally place the PersonIF.class file in its own JAR called PersonIF.jar and will store that JAR in a (different) subdirectory. The Person.class file will exist in its own Person.jar JAR file and that JAR file includes a MANIFEST.MF file with a Class-Path header referencing PersonIF.jar in the relative subdirectory.

I will now attempt to compile the Main.class from Main.java with only the current directory on the classpath. I formerly would have expected compilation to fail when javac would be unable to find PersonIF.jar in a separate subdirectory. However, it doesn't fail!

This seemed surprising to me. Why did this compile when I had not explicitly specified PersonIF.class (or a JAR containing it) as the value of classpath provided via the -cp flag? The answer can be seen by running javac with the -verbose flag.

The output of javac -verbose provides the "search path for source files" and the "search path for class files". The "search path for class files" was the significant one in this case because I had moved the PersonIF.java and Person.java source files to a completely unrelated directory not in those specified search paths. It's interesting to see that the search path for class files (as well as the search path for source files) includes archive/PersonIF.jar even though I did not specify this JAR (or even its directory) in the value of -cp. This demonstrates that the Oracle-provided Java compiler considers the classpath content specified in the Class-Path header of the MANIFEST.MF of any JAR on specified on the classpath.

The next screen snapshot demonstrates running the newly compiled Main.class class and having the dependency PersonIF.class picked up from archive/PersonIF.jar without it being specified in the value passed to the Java application launcher's java -cp flag. I expected the runtime behavior to be this way, though admittedly I had never tried it or even thought about doing it with a JAR whose MANIFEST.MF file did not have a Main-Class header (non-executable JAR). The Person.jar manifest file in this example did not specify a Main-Class header and only specified a Class-Path header, but was still able to use this classpath content at runtime when invoked with java.

The final demonstration for this post involves removing the Class-Path header and associated value from the JAR file and trying to compile with javac and the same command-line-specified classpath. In this case, the JAR containing Person.class is called Person2.jar and the following screen snapshot demonstrates that its MANIFEST.MF file does not have a Class-Path header.

The next screen snapshot demonstrates that compilation with javac fails now because, as expected, PersonIF.class is not explicitly specified on the classpath and is no longer made available by reference from the MANIFEST.MF Class-Path header of a JAR that is on the classpath.

We see from the previous screen snapshot that the search paths for source files and for class files no longer include archive/PersonIF.jar. Without that JAR available, javac is unable to find PersonIF.class and reports the error message: "class file for PersonIF not found."

General Observations

  • The Class-Path header in a MANIFEST.MF file has no dependency on the existence of a Main-Class header existing in the same JAR's MANIFEST.MF file.
    • A JAR with a Class-Path manifest header will make those classpath entries available to the Java classloader regardless of whether that JAR is executed with java -jar ... or is simply placed on the classpath of a larger Java application.
    • A JAR with a Class-Path manifest header will make those classpath entries available to the Java compiler (javac) if that JAR is included in the classpath specified for the Java compiler.
  • Because the use of Class-Path in a JAR's manifest file is not limited in scope to JARs whose Main-Class is being executed, class dependencies can be potentially inadvertently satisfied (perhaps even with incorrect versions) by these rather than resolving explicitly specified classpath entries. Caution is advised when constructing JARs with manifests that specify Class-Path or when using third-party JARs with Class-Path specified in their manifest files.
  • The importance of the JAR's manifest file is sometimes understated, but this topic is a reminder of the usefulness of being aware of what's in a particular JAR's manifest file.
  • This topic is a reminder of the insight that can be gleaned from running javac now and then with the -verbose flag to see what it's up to.
  • Whenever you place a JAR on the classpath of the javac compiler or the java application launcher, you are placing more than just the class definitions within that JAR on the classpath; you're also placing any classes and JARs referenced by that JAR's manifest's Class-Path on the classpath of the compiler or application launcher.


There are many places from which a Java classloader may load classes for building and running Java applications. As this post has demonstrated, the Class-Path header of a JAR's MANIFEST.MF file is another touch point for influencing which classes the classloader will load both at runtime and at compile time. The use of Class-Path does not affect only JARs that are "executable" (have a Main-Class header specified in their manifest file and run with java -jar ...), but can influence the loaded classes for compilation and for any Java application execution in which the JAR with the Class-Path header-containing manifest file lies on the classpath.

Friday, September 11, 2015

Passing Arrays to a PostgreSQL PL/pgSQL Function

It can be handy to pass a collection of strings to a PL/pgSQL stored function via a PostgreSQL array. This is generally a very easy thing to accomplish, but this post demonstrates a couple of nuances to be aware of when passing an array to a PL/pgSQL function from JDBC or psql.

The next code listing is for a contrived PL/pgSQL stored function that will be used in this post. This function accepts an array of text variables, loops over them based on array length, and reports these strings via the PL/pgSQL RAISE statement.

CREATE OR REPLACE FUNCTION printStrings(strings text[]) RETURNS void AS $printStrings$
   number_strings integer := array_length(strings, 1);
   string_index integer := 1;
   WHILE string_index <= number_strings LOOP
      RAISE NOTICE '%', strings[string_index];
      string_index = string_index + 1;
$printStrings$ LANGUAGE plpgsql;

The above PL/pgSQL code in file printStrings.sql can executed in psql with \ir as shown in the next screen snapshot.

The syntax for invoking a PL/pgSQL stored function with an array as an argument is described in the section "Array Value Input" in the PostgreSQL Arrays documentation. This documentation explains that "general format of an array constant" is '{ val1 delim val2 delim ... }' where delim is a delimited of comma (,) in most cases. The same documentation shows an example: '{{1,2,3},{4,5,6},{7,8,9}}'. This example provides three arrays of integral numbers with three integral numbers in each array.

The array literal syntax just shown is straightforward to use with numeric types such as the integers in the example shown. However, for strings, there is a need to escape the quotes around the strings because there are already quotes around the entire array ('{}'). This escaping is accomplished by surrounding each string in the array with two single quotes on each side. For example, to invoke the stored function just shown on the three strings "Inspired", "Actual", and "Events", the following syntax can be used in psql: SELECT printstrings('{''Inspired'', ''Actual'', ''Events''}'); as shown in the next screen snapshot.

Arrays can be passed to PL/pgSQL functions from Java code as well. This provides an easy approach for passing Java collections to PL/pgSQL functions. The following Java code snippet demonstrates how to call the stored function shown earlier with JDBC. Because this stored function returns void (it's more like a stored procedure), the JDBC code does not need to invoke any CallableStatement's overridden registerOutParameter() methods.

JDBC Code Invoking Stored Function with Java Array
final CallableStatement callable =
   connection.prepareCall("{ call printstrings ( ? ) }");
final String[] strings = {"Inspired", "Actual", "Events"};
final Array stringsArray = connection.createArrayOf("varchar", strings);
callable.setArray(1, stringsArray);

Java applications often work more with Java collections than with arrays, but fortunately Collection provides the toArray(T[]) for easily getting an array representation of a collection. For example, the next code listing is adapted from the previous code listing, but works against an ArrayList rather than an array.

JDBC Code Invoking Stored Function with Java Collection
final CallableStatement callable =
   connection.prepareCall("{ call printstrings ( ? ) }");
final ArrayList<String> strings = new ArrayList<>();
final Array stringsArray =
      strings.toArray(new String[strings.size()]));
callable.setArray(1, stringsArray);


The ability to pass an array as a parameter to a PostgreSQL PL/pgSQL stored function is a straightforward process. This post specifically demonstrated passing an array of strings (including proper escaping) to a PL/pgSQL stored function from psql and passing an array of Strings to a PL/pgSQL stored function from JDBC using java.sql.Array and Connection.createArrayOf(String, Object[]).

Saturday, September 5, 2015

The Latest Twist in the Java IDE Wars: Subscription-based IntelliJ IDEA

I've been watching with some interest the discussion surrounding this past week's announcement that JetBrains is moving to an Adobe-like and Microsoft Office-like software subscription licensing model. The feedback has been fast and furious and JetBrains has responded with a very brief follow-up post We are listening that is entirely reproduced in this quote: "We announced a new subscription licensing model and JetBrains Toolbox yesterday. We want you to rest assured that we are listening. Your comments, questions and concerns are not falling on deaf ears. We will act on this feedback."

There are several places to see the reaction, positive and negative, to this announcement. The feedback comments on both the original announcement post and on the follow-up post are good places to start. There are also Java subreddit threads JetBrains switches to subscription model for tools (101 comments currently) and Are you sticking with IntelliJ IDEA or you are moving on to another IDE? (180 comments currently). I was going to summarize some of the pros and cons of this announcement, but Daniel Yankowsky has done such a good job of this that I'll simply reference his post How JetBrains Lost Years of Customer Loyalty in Just a Few Hours.

After reading these posts, it is clear that the change announced by JetBrains would benefit some consumers but might cost other consumers more and, in some cases, quite a bit more. It all seems to depend on what each individual user actually uses and how he or she uses it. In many ways, this makes me think of my most recent Microsoft Office purchase. I purchased Microsoft Office 2013 for my new PC outright rather than via subscription. It would take 2-3 years of subscription payments to meet or exceed the one-time payment I made for Office, but I anticipate needing few new features in Office in the life of this computer. In fact, I have older versions of Microsoft Office running on older computers and am happy with them. It seems that subscriptions to any software product benefit those who need or strongly desire new functions and features and are more expensive for those who are happy with the current functionality set of a particular product. I personally like that Microsoft allows consumers to choose and either buy the software license outright or use a subscription. Having choice in the matter seems to be what's really best for the consumer.

JetBrains provides numerous tools for a wide variety of programming languages and frameworks, but there are also "substitute products" available for most of these. For example, in the Java world, IDEA competes with freely available open source competitors NetBeans and Eclipse. There is, of course, JetBrains's own freely available Community Edition of IDEA that can be seen as a substitute for the Java developer.

The fact that JetBrains can sell its IDEA IDE when there are good alternative Java IDEs available in NetBeans and Eclipse is evidence that many Java developers like what IntelliJ IDEA has to offer enough to pay for it. I am interested to see how the subscription model will affect this balance. JetBrains's relatively quick follow-up announcement indicates that they are considering at least some tweaks to the announced policy already.

Some of the arguments being made against the announcement seem to be out of principle rather than against the actual cost. The JetBrains Toolbox costs are shown currently to be $19.90/month (USD) for existing users to use all tools, just under $12 (USD) for existing uses of IntelliJ IDEA Ultimate Edition, and just under $8/month (USD) for existing users of WebStorm. Those who are not existing users can expect to pay a bit more per month.

One mistake I think was made in the announcement is typical of consumer-facing companies: presenting a change that has obvious benefits for the vendor as if the change is being made primarily for the benefit of the consumer. Although there seems to be benefits for many of the consumers of this announcement, these changes also do not benefit a large number of consumers. There's no question these changes have advantages for JetBrains and it does seem difficult to believe that the changes were driven more by consumers' interests than out of the company's interests. It is not unusual for companies to present changes that benefit themselves as being made primarily in the consumers' interest, but that doesn't mean we like it to hear it presented like that. I think this tone can lead to people reacting negatively to the announcement out of principle.

There are also some interesting articles on software subscription pricing models. Joshua Brustein wrote in Adobe's Controversial Subscription Model Proves Surprisingly Popular that "[Adobe] is making more money selling monthly subscriptions to its Creative Cloud software—the family of programs that includes Photoshop and Illustrator—than it is by selling the software outright." In Software Makers' Subscription Drive, Sam Grobart wrote that "in 2013 consumer software companies proved they could pull off the switch from one-time software purchases to an online subscriber model that costs customers more long term." That article discusses the advantages and disadvantages of consumer software subscriptions from users' and sellers' perspectives.

I'll be watching developments related to JetBrains's announcement in the short-term and long-term to see what effects result from the change in licensing. I'm particularly interested in how this affects IntelliJ IDEA in the Java IDE/text editor space where IntelliJ IDEA Ultimate will continue to compete with IntelliJ IDEA Community Edition, NetBeans, Eclipse, JDeveloper, Sublime, and more.

Monday, August 31, 2015

Book Review: JavaScript: The Good Parts

From the perspective of a book on a programming language that is frequently quoted with reverence by developers that regularly use that programming language, it could be argued that Java Script: The Good Parts is to JavaScript developers as Effective Java is to Java developers. The subtitle of Douglas Crockford's JavaScript: The Good Parts is "Unearthing the Excellence in JavaScript." I finally purchased and read JavaScript: The Good Parts (O'Reilly/Yahoo! Press, 2008) and this is my review of that book. This is more than a review, however, in that it also provides me a forum to highlight some of observations from that book that most interested me.

JavaScript: The Good Parts is a relatively short book with ten chapters and five appendices spanning fewer than 150 pages. It's impressive how much content can be squeezed into 150 pages and is a reminder that the best writing (in prose and in code) is often that which can say more in fewer words. I was able to read all of the chapters and the two appendices that interested me the most during a flight that took a little more than an hour (although my reading started as soon as I was seated on the airplane). There is one caveat to this: although some of JavaScript: The Good Parts is a very quick read for anyone with basic familiarity with JavaScript, other portions required me to re-read them or even tell myself, "I better come back to that later and read it again." This is another way in which this book reminds me of Effective Java.


The first page of the Preface is the core content of that section and it provides an overview of what a reader of JavaScript: The Good Parts should expect. The Preface describes JavaScript as "a surprisingly powerful language" which has some "unconventionality" that "presents some challenges," but is also a "small language" that is "easily mastered." One category of developer to which this book is targeted is "programmers who have been working with JavaScript at a novice level and are now ready for a more sophisticated relationship with the language." That sounds like me!

Crockford uses the Preface to describe what JavaScript: The Good Parts covers. He states, "My goal here is to help you learn to think in JavaScript." He also points out that JavaScript: The Good Parts "is not a book for beginners," "is not a reference book," "is not exhaustive about the language and its quirks," "is not a book for dummies," and "is dense."

Chapter 1: Good Parts

In the initial chapter of JavaScript: The Good Parts, Crockford points out that programming languages have "good parts and bad parts" and that "JavaScript is a language with more than its share of bad parts." He points out that these deficiencies are largely due to the short amount of time in which JavaScript was created and articulates, "JavaScript's popularity is almost completely independent of its qualities as a programming language." Crockford has found that a developer can write better programs in any language by only using the good parts of that language as much as possible. This seems to be particularly true with JavaScript. Crockford provides a high-level description of JavaScript's good parts:

"JavaScript has some extradordinarily good parts. In JavaScript, there is a beautiful, elegant, highly expressive language that is buried under a steaming pile of of good intentions and blunders."

In the section "Analyzing JavaScript," Crockford surveys the "very good ideas" that JavaScript is built upon along with the "few very bad" ideas that JavaScript is built upon. This first chapter is only 4 pages and the overview of these good and bad ideas is contained in a couple of pages. However, the remaining chapters of the book provide more details on the good parts and the first two appendices provide more details on the bad parts.

I agree with Crockford's assertion that a significant portion of the negativity and even hostility toward JavaScript is probably more appropriately aimed at the DOM. JavaScript has probably been accused of being non-standard and browser-specific millions of times when it is really the browser's DOM implementation that is non-standard and browser-specific.

I cannot finish my review of the first chapter of JavaScript: The Good Parts without quoting one more astute quote: "[Given JavaScript's] many errors and sharp edges, ... 'Why Should I Use JavaScript?' There are two answers. The first is that you don't have a choice. ... JavaScript is the only language found in all browsers. ... The other answer is that, despite its deficiencies, JavaScript is really good."

Chapter 2: Grammar

The second chapter of JavaScript: The Good Parts provides 15 pages of introduction to the "grammar of the good parts of JavaScript, presenting a quick overview of how the language is structured." For someone who has used JavaScript previously, much of this chapter may not be particularly insightful, though just seeing the parts of the language that Crockford feels are "good" is useful. The section on "Statements" points out early some "unconventional" aspects of JavaScript: code blocks delineated by curly braces do not limit scope to those blocks and variables should be defined at the beginning of a function rather than at first use.

Chapter 3: Objects

The 6 pages of Chapter 3 introduce JavaScript Objects. Significant aspects of JavaScript objects (key/value pair nature, prototype object association, pass-by-reference, objection inspection with typeof and hasOwnProperty, and reducing an object's "global footprint") are covered succinctly.

Chapter 4: Functions

Chapter 4 of JavaScript: The Good Parts begins with the statements, "The best thing about JavaScript is its implementation of functions. It got almost everything right. But, as you should expect with JavaScript, it didn't get everything right." This chapter is longer (20 pages) than the ones before it, reinforcing that Crockford believes functions are one of the really good parts of JavaScript. Despite its being lengthier than the preceding chapters, Chapter 4 seems to me to also be more dense (particularly than Chapters 2 and 3).

Chapter 4's coverage of JavaScript functions point out one of the differences in JavaScript I needed to come to terms with to feel more confident with the language: "Functions in JavaScript are objects." The section on function invocation briefly describes the four patterns of invocation in JavaScript (method invocation, function invocation, constructor invocation and apply invocation) and explains how this is initialized differently depending on the particular pattern of invocation used. JavaScript's different meaning of this depending on context has been one of the more difficult aspects of working with JavaScript after coming from a Java background, but this explanation is the clearest and most easy to remember that I have read.

The fourth chapter covers exception handling, method cascading, and type augmentation. The section on "Augmenting Types" presents multiple examples of adding "significant improvements to the expressiveness of the language" by "augmenting the basic types" via addition of methods to appropriate prototypes.

The sections on "Recursion," "Closure," and "Module" are where things got a bit dense for me and I needed to read several portions of these sections more than once to more fully appreciate the points being made. I believe I still have a ways to go to understand these concepts completely, but I also believe that understanding them well and implementing the module concept presented here is the key to happiness in large-scale JavaScript development.

The "Curry" section of Chapter 4 states that JavaScript lacks a curry method, but explains how to address that by associating a curry method with Function. The "Memoization" section demonstrates how to use memoization in JavaScript so that "functions can use objects to remember the results of previous operations, making it possible to avoid unnecessary work."

Chapter 5: Inheritance

JavaScript: The Good Parts's fifth chapter begins by briefly explaining the two "useful services" that inheritance provides in "classical languages (such as Java)": code reuse and type system. It is explained that JavaScript is dynamically typed and therefore gains a single advantage from inheritance: code reuse. Crockford states that "JavaScript provides a much richer set of code reuse patterns" than the "classical pattern."

The "Pseudoclassical" section of Chapter 5 begins with the assertion that "JavaScript is conflicted about its prototypal nature." There is in-depth discussion about the dangeris and drawbacks of using the constructor invocation pattern. The most "serious hazard" occurs when a developer forgets to use new when calling the constructor function. Crockford warns that in such cases, this is associated with the global object rather than the (likely) intended new object. The author states that convention is to use uppercase for the first letter of the "constructor function" objects" to indicate this risk, but he advises that the better course is to not use new or the constructor invocation pattern at all.

This discussion in the "Pseudoclassical" section of Chapter 5 provides more detail on issues Crockford raised with the "constructor invocation pattern" in Chapter 4. These two sections forced me to acknowledge that while I've liked using the constructor invocation pattern in JavaScript, it's only because "the pseudoclassical form can provide comfort to developers who are unfamiliar with JavaScript." Crockford warns that its use "hides the true nature of the language."

Chapter 5 introduces object specifiers and dives into coverage of JavaScript's prototypal implementation and differential inheritance. The "Functional" section of this fifth chapter illustrates how to use a functional approach to reuse and states that this functional approach "requires less effort than the pseudoclassical pattern and gives us better encapsulation and information hiding and access to super methods." The fifth chapter concludes with discussion and code example of composing objects "out of sets of parts."

Chapter 6: Arrays

The 6-page sixth chapter of JavaScript: The Good Parts introduces the concept of an array and mentions a couple of its benefits, but laments, "Unfortunately, JavaScript does not have anything like this kind of array." The author describes what JavaScript offers as "an object that has some array-like characteristics." He points out that this array-like object is "significantly slower than a real array, but it can be more convenient to use."

Chapter 6 discusses JavaScript's "unconventional" length property for JavaScript "arrays" and introduces syntax for accessing elements, push, and delete. Crockford points out that "JavaScript does not have a good mechanism for distinguishing between arrays and objects" and he provides two brief implementations of is_array functions (the second relies on toString() not being overridden).

The sixth chapter wraps up with discussion regarding adding methods to JavaScript's Array. Specific code examples include a function thar initializes the delements of a JavaScript array and a function that initializes the elements of a matrix (array of arrays).

Chapter 7: Regular Expressions

The nearly 23 pages of JavaScript: The Good Parts's seventh chapter focus on applying regular expressions in JavaScript. For those who have used other implementations of regular expressions (particularly Perl's or implementations based on Perl's), this will be fairly familiar.

Crockford points out several motivations for keeping regular expressions simple, but a JavaScript-specific motivation for simpler regular expressions that he cites has to do with lack of portability between different JavaScript language processors' regular expression support.

Chapter 7 introduces two forms of creating regular expressions in JavaScript: literals (/ syntax) and RegExp constructor. The chapter also introduces other JavaScript syntax for working with various regular expression concepts in JavaScript.

Chapter 8: Methods

The 15+ pages of Chapter 8 of JavaScript: The Good Parts feel like an API reference and reminds of me books such as Java in a Nutshell. These pages summarize the "small set of standard methods that are available on the standard types" in JavaScript. The chapter lists the method signature, brief method description, and examples of using that method for standard methods defined on Array, Function, Number, Object, RegExp, and String. Although these are nice summary descriptions and example usages, this chapter may be the least useful chapter of the book given that these APIs are documented online in sites such as the Mozilla Developer Network's JavaScript Reference.

Chapter 9: Style

JavaScript: The Good Parts's most (pleasantly) surprising chapter for me may be Chapter 9. When I was browsing the table of contents and saw "Style," I thought this chapter would be another bland spelling out of what to do and not do stylistically in code. I'm tired of these stylistic discussions. The chapter is fewer than 4 pages, so I did not expect much.

It turns out that the ninth chapter has some important observations in its just over three pages on style. I like that Crockford takes the reasons for style concerns with any programming language and emphasizes that they are particularly important in JavaScript.

My favorite part of Chapter 9 is when Crockford explains his style used in the book for JavaScript code. Some of it is the bland matter-of-taste stuff like number of spaces for indentation, but some of it is motivated by an understanding of JavaScript nuances and limitations. For example, Crockford states, "I always use the K&R style putting the { at the end of a line instead of the front, because it avoids a horrible design blunder in JavaScript's return statement." Similarly, he points out that he declares variables at the beginning of a function and prefers line comments over block comments because of other nuances of JavaScript. He (and my review) covers these more in the appendices.

This second-to-last chapter offers some poignant advice regarding coding style and large-scale JavaScript applications:

"Quality was not a motivating concern in the design, implementation, or standarization of JavaScript. That puts a greater burden on the users of the language to resist the language's weaknesses. JavaScript provides support for large programs, but it also provides forms and idioms that work against large programs.

Chapter 10: Beautiful Features

JavaScript's bad features are the focus of Appendix A ("Awful Parts" that "are not easily avoided") and Appendix B ("problematic features" that "are easily avoided"), but Crockford focuses Chapter 10 on what he considers JavaScript's "beautiful features." Because this is the theme of the book, this chapter only needs a bit over 2 pages to highlight Crockford's concept of "Simplified JavaScript": taking the "best of the Good Parts" of JavaScript, removing the features of the language with very little or even negative value, and adding a few new features (such as block scoping, perhaps the thing I miss most in JavaScript).

Appendix A: Awful Parts

Appendix A highlights the "problematic features of JavaScript that are not easily avoided" in just over 7 pages. Crockford warns, "You must be aware of these things and be prepared to cope."

The body of the appendix opens with an assertion that's difficult to argue with: "The worst of all of JavaScript's bad features is its dependence on global variables." I also like that Crockford points out that while many programming languages "have global variables," the problem with JavaScript is that it "requires them."

Appendix A also highlights why JavaScript's handling of reserved words, lack of block scope, 16-bit unicode support, typeof limitations, parseInt without explicit radix, confusion of + for adding or concatenating, "phony" arrays, and a few other features are problematic and how to avoid or reduce their use.

Perhaps the most interesting discussion for me in Appendix A is the explanation of why JavaScript may somtimes insert semicolons and, instead of fixing things, will make things worse (mask more significant code issues).

Appendix B: Bad Parts

The six pages of Appendix B "present some of the problematic features of JavaScript that are easily avoided." The chapter details why JavaScript features such as ==, with, continue, falling through switch, statements without blocks, bitwise operators, typed wrappers (and new Object and new Array), and void should be avoided.

Appendix C: JSLint

Appendix C provides 10 pages focused on JSLint, described as "a JavaScript syntax checker and verifier." About JSLint, Crockford states, "JSLint defines a professional subset of JavaScript ... related to the style recommendations from Chapter 9. JavaScript is a sloppy language, but inside it there is an elegant, better language. JSLint helps you to program in that better language and to avoid most of the slop."

Appendix C details how JSLint helps JavaScript developers identify global variables and functions, identify potentially misspelled members (used only once because misspelled but JavaScript itself won't report), identify missing or extraneous semicolons, identify potential issues of automatic semicolon insertion due to improper line breaking, and identify block statements missing opening and closing curly braces. Other items flagged by JSLint include fall-though switch statements, use of with, assignment operator used in a conditional expression, potential JavaScript type coercion with == and !=, eval, void, bitwise operators, potentially non-portable regular expressions, and constructor functions.

The chapter also demonstrates how to specify to JSLint the "subset of JavaScript that is acceptable." In other words, one can choose to not have certain conditions flagged by JSLint. I find it interesting that JSLint provides some HTML validation in addition to checking for well-formed JSON.

I have found that static code analysis tools for Java not only help improve existing Java code, but help me write better Java code in the future as I learn what is considered wrong or bad form, why it is wrong or frowned upon, and how to avoid it. The same is true for JSLint's effect on JavaScript; a person learning JavaScript can benefit from learning what JSLint flags to know the bad/ugly parts of JavaScript to avoid..

Appendix D: Syntax Diagrams

The fourth appendix consists solely of syntax diagrams that graphically indicate how various JavaScript constructs are syntactically constructed. The diagrams are of the portions of JavaScript highlighted in JavaScript: The Good Parts. Appendix D is a reference guide similar to Chapter 8 and, like Chapter 8, is probably the least valuable of the book's appendices because it is information that is readily available online.

Appendix E: JSON

The final ten pages of the book are in Appendix E and are dedicated to JavaScript Object Notation (JSON). The appendix describes JSON as "based on JavaScript's object literal notation, one of JavaScript's best parts." This introduction explains that JSON is a text-based format that is a subset of JavaScript but can also be used as a language-independent data transfer format. Most of the material in this appendix was obviously a lot newer to people in 2008 when this book was published than it is today because today many developers who don't even know JavaScript very well are aware of JSON.

Appendix F describes the syntax rules of JSON in approximately a single page because "JSON's design goals were to be minimal portable, textual, and a subset of JavaScript."

The section of Appendix F on "Using JSON Securely" looks at the risks of using JavaScript's eval to turn JSON into a useful JavaScript data structure and recommends use of JSON.parse instead. There is also interesting discussion on security implications of assigning an HTML text fragment sent by the server to an HTML element's innerHTML property. What makes this interesting is Crockford's pointing out that this security issue has nothing to do with Ajax, XMLHttpRequest, or JSON, but is rather due to the core JavaScript design flaw of featuring a global object. Crockford takes one more shot at this "feature": "This danger is a direct consequence of JavaScript's global object, which is far and away the worse part of JavaScript's many bad parts. ... These dangers have been in the browser since the inception of JavaScript, and will remain until JavaScript is replaced. Be careful."

The last 5 1/2 pages of Appendex F feature a code listing for a JSON parser written in JavaScript.

General Observations

  • JavaScript: The Good Parts deserves the praise and reverence heaped upon it; it is a great book and I cannot think of a JavaScript book that I've read that has done as much for my understanding of this unconventional language as JavaScript: The Good Parts.
  • Many technology books rave about the covered language, framework, or library and either don't acknowledge the deficiencies and downsides of the covered item or quickly explain them away as insignificant or inconsequential. JavaScript: The Good Parts is more effective because it doesn't do this. Instead, Crockford's writing makes it obvious that there are many aspects of JavaScript he likes and finds expressive, but that he also recognizes its downsides. His book is an attempt to teach how to mostly use only good parts of JavaScript and mostly avoid use of the bad parts of JavaScript.
  • Because Crockford takes time to explain JavaScript's unconventional features and distinguish between cases where the unconventional approach is "good" and cases where unconventional approach is "bad," readers of the book have a better opportunity to appreciate JavaScript's positives rather than mostly seeing its negatives.
  • JavaScript: The Good Parts reinforces the idea that trying to treat JavaScript like Java (or any other classically-object-oriented language) is a mistake. It explains why this approach often leads to frustration with JavaScript.
  • JavaScript: The Good Parts is a highly-readable and generally approachable book. The (English) language of the book is clear and well-written. The conciseness is impressive, especially considering that some of the book's most important points are made multiple times in different contexts and the entire book has fewer than 150 main pages.
    • Although JavaScript: The Good Parts is written in a very readable form, some portions of it are more difficult to read because the content is more difficult. This is particularly true in some of the sections in Chapter 4 on functions. Some of these sections required multiple readings for me, but they are also the sections that bring the most insight when understood.
    • One reason that JavaScript: The Good Parts can be as concise as it is has to do with it providing so little introduction. Those who have never coded before or have no JavaScript coding experience, will likely be better off reading a more introductory book or online resource first.
  • Several useful JavaScript code snippets are provided in JavaScript: The Good Parts to illustrate good and bad parts of JavaScript. Along the way, several pieces of code are provided that are generic and reusable and worth highlighting here:
    • Chapter 3 (page 22) provides 6 lines of code for associating a "create method" with the Object function that "creates a new object that uses an old object for its protype."
    • Chapter 4 (pages 32-33) provides 4 lines of code for making a named method available to all functions. A slightly revised version of this is presented one page later with the addition of a "defensive technique" to ensure that a newly defined method does not override one that another library is already using.
    • Chapter 4 (page 33) provides 3 lines of code for adding an integer to Number.prototype that "extracts just the integer part of a number."
    • Chapter 4 (page 33) provides 3 lines of code for adding trim method to String.prototype that "removes spaces from the ends of a string."
    • Chapter 4 (page 44) provides 8 lines of code for adding a curry method to Function.
    • Chapter 4 (page 45) provides 11 lines of code that implement a geeneralized funtion for generation of memoized functions.
    • Chapter 5 (page 54) provides 7 line of code that implement a superior method that "takes a method name and returns a function that invokes that method."
    • Chapter 6 (page 61) provides two brief implementations of is_array functions for determining if a given JavaScript item is an array.
    • Chapter 6 (page 63) provides an implementation of a dim method on arrays that initializes all elements of an array.
    • Chapter 6 (pages 63-64) provides an implementation of a matrix method on Array that initializes all elements of arrays nested within array.
    • Appendix F (pages 140-145) provides an implementation of a "simple, recursive decent [JSON] parser" to generate a JavaScript data structure from JSON text.
  • A book such as JavaScript: The Good Parts is necessarily opinionated (same applies to the excellent Effective Java). I like it in this case because it's not one-sided, rose-colored glasses opinions, but rather expresses opinions of both JavaScript's good and bad parts. Not all opinions are created equal. In this case, author Douglas Crockford brings great credibility to back his opinions. His involvement with JSLint and JSON alone speak volumes for his experience with and knowledge of JavaScript. Opinionated books written by inexperienced individuals are not likely to be very valuable, but an opinionated book by an experienced developer is often among the most valuable of technical books.


JavaScript: The Good Parts is one of those relatively rare technical books that is very hyped and lives up to that hype. It helps the reader to understand how to use the best parts of JavaScript and avoid or reduce exposure to the bad parts of JavaScript. In the process of doing this, it does help the reader to do exactly what the author is trying to accomplish: to think in JavaScript. JavaScript: The Good Parts condenses significant low-level details and important high-level language design discussion into fewer than 150 pages.

Friday, August 28, 2015

Book Review: JavaScript at Scale

JavaScript at Scale (Packt Publishing, July 2015) is written by Adam Boduch and has the subtitle "Build enduring JavaScript applications with scaling insights from the front-line of JavaScript development." JavaScript at Scale features ten chapters spanning approximately 240 substantive pages.


JavaScript at Scale's Preface includes a sentence or two describing each of its ten chapters. Readers of the book who want to work with the examples are encouraged to have Node.js, a code editor or IDE, and a "modern web browser" available while using this book.

The Preface states that the book is intended for "a senior JavaScript developer who is curious about architectural issues in the frontend." The Preface adds that "no prerequisite framework knowledge [is] required," but states that "strong JavaScript language skills are required." The Preface also points out more details on the nature of this book: "the concepts presented throughout the book are adaptations of components found in frameworks such as Backbone, Angular, or Ember."

These statements are important for developers considering purchasing and/or reading JavaScript at Scale as they provide an appropriate glimpse at what the author is aiming for with this book. The emphasis of JavaScript at Scale is definitely on higher-level design and architectural principles than on low-level implementation details (including use of specific frameworks and libraries in the category of low-level implementation details).

Chapter 1: Scale from a JavaScript Perspective

The initial chapter of JavaScript at Scale describes common scalability concerns and how they pertain to JavaScript. The chapter uses a hypothetical new generic JavaScript application as an example and talks about different scaling concerns that arise as more users use the application, as more features are added to the application, and as more developers are added to the development team.

Chapter 1 discusses architecture of components and communication between components for a browser-hosted application. The chapter discusses responsiveness, addressability, and configurability. There are several other discussion items in this chapter such as trade-offs that can be made in designing a JavaScript application's architecture, using frameworks and libraries, and taking advantage of communities.

Chapter 2: Influencers of Scale

The second chapter of JavaScript at Scale delves into a concept introduced in the first chapter: the influencers of scale. In looking specifically at scaling users, the chapter discusses business models for attracting customers, license fees, subscription fees, consumption fees, including advertisements in the product, using and being open source, communication between users, support mechanisms, allowing feedback and notifying users, and collecting user metrics.

Chapter 2 provides more discussion on subjects such as collecting metrics to determine which features to add to the application, dealing with too few to too many developers for the application development, and managing users.

JavaScript at Scale's second chapter concludes with presentation of scale influencer checklists. Several checklists are presented with several questions on each. These checklists tend to ask questions related to the topics discussed in the chapter and provide a way for development teams to start conversation on these potential influencers of scale.

Chapter 3: Component Composition

Chapter 3 of JavaScript at Scale is the first chapter that gets detailed enough to include code listings. The author `states, "Large-scale JavaScript code is still a relatively new thing." The chapter explains that JavaScript doesn't have module support and so popular approaches for dealing with JavaScript modules include RequireJS and Browserify (CommonJS). There is extensive discussion regarding routing logic as well as discussion on controllers and views, models and collections, templates, and extending generic components in creating application-specific components.

The third chapter also looks at how to map features to components and how to most appropriately deviate from desired generic component features when creating application-specific features. The chapter includes discussion regarding maintaining, debugging, and refactoring complex components. Other discussion covers organizing component code, implementing stateless functions, and extending versus configuring components.

Chapter 4: Component Composition and Responsibilities

The fourth chapter of JavaScript at Scale "focuses on the glue in between our JavaScript components." The chapter begins by looking at the two predominant communication mechanisms for communication between JavaScript components: message passing and event triggering. The chapter describes messaging considerations such as data size, naming conventions, and common data.

A particularly useful section of Chapter 4 describes implementing "traceable component communication" and describes three approaches for doing this. The chapter covers other considerations and approaches for communication overhead, areas of communication responsibility, loosely coupled communication, handling unexpected events, and component layers.

Chapter 5: Addressability and Navigation

JavaScript at Scale's fifth chapter opens by stating that URI processing "has shifted mostly to the frontend" in "large-scale JavaScript applications," but points out that the "benefits of frontend routing do come at a cost." The chapter then introduces "two approaches to routing in JavaScript": hash URIs and browser history API.

The fifth chapter spends some time looking at JavaScript routers, describing what they are, describing router responsibilities, describing router events, examining what should be in and not be in URIs, and describing manually and automatically associating URIs with resources. The router-heavy chapter continues with coverage of topics such as triggering routes, configuring routes, deactivating routes, troubleshooting routes, logging routes, and handling invalid resource states. Although most of this fifth chapter is discussion text like the earlier chapters of the book, there are a couple lengthy code listings in this chapter.

Chapter 6: User Preferences and Defaults

Chapter 6 of JavaScript at Scale opens with discussion of "three main types of preferences we're concerned with when designing large-scale JavaScript architectures": locales, behavior, and appearance. The chapter provides a brief overview of each of these three types of preferences before revisiting each of the three in significantly greater detail. The sixth chapter closes with a section on performance considerations related to preferences that includes a lengthy code listing.

Chapter 7: Load Time and Responsiveness

The seventh chapter of JavaScript at Scale points out that "Performance is the prominent indicator of quality in the eyes of a user." The chapter looks at JavaScript scale and performance in terms of load time and responsiveness. The chapter discusses use of different sizes of components to deal with network request overhead and developer overhead. The chapter also provides discussion on lazy loading modules and on advantages of using ECMAScript 6 modules over third-party module frameworks.

Chapter 7 also discusses scaling related to communication between components. There is discussion and a code listing explaining use of event brokers and indirection can be useful at first but then present a communication bottleneck with larger JavaScript applications. The chapter briefly describes a small number of JavaScript profiling approaches (such as using the browsers' console.profile() and console.profileEnd() and benchmark.js) that can be used to determine communication bottlenecks to be addressed.

Chapter 7's discussion on addressing issues with state includes an interesting discussion on use of purely functional code with no side effects to improve performance by reducing mutable state. There is also discussion on other topics such as improving performance related to DOM updates and increasing amounts of data to render.

Chapter 8: Portability and Testing

Chapter 8 of JavaScript at Scale begins with a discussion of advantages of loosening the coupling between front-end JavaScript and back-end JavaScript components. This discussion also outlines the advantages and costs associated with mocking data. The discussion looks at the traits desired in a mocking layer and looks at two approaches to mocking the backend. This mocking discussion is fairly extensive.

The eighth chapter also discusses unit testing and discusses how unit test tools built-in to popular JavaScript frameworks are related to framework-agnostic testing tools. The chapter then discusses advantages of "standalone unit testing tools" and emphasizes Jasmine. The chapter concludes with discussion on toolchains, integration testing, and end-to-end testing.

Chapter 9: Scaling Down

The ninth chapter of JavaScript at Scale discusses "scaling down from bloated design" and states, "The composition of our application as a whole determines how easy or how difficult it'll be to scale down by turning features off." The section on "JavaScript artifact size" states, "The biggest contributor to growing JavaScript artifact sizes are the new features we constantly add to our product." The section on "Network bandwidth" states, "The challenge is that any new feature is going to add new network bandwidth consumption." There is also discussion in this chapter on topics such as memory usage and garbage collection, CPU consumption, and backend scalability.

Chapter 9's discussion regarding scaling down also provides discussion on irrelevant features and overlapping features that often exist in older and larger JavaScript baselines. The chapter also discusses how customer demand and design failures relate to the need to scale down. The section on "unnecessary components" makes an interesting assertion: "The most common pattern flaw is unnecessary indirection." This section talks about issues that can arise when originally selected patterns no longer apply well and when the generic nature of frameworks' patterns do not fit well with the architecture.

"Inefficient data processing" is also described in this ninth chapter and the author describes how moving and transforming data between multiple components can lead to inefficiencies. The chapter finishes with discussions regarding "excessively creative markup" and "application composition." Chapter 9 is a discussion-rich chapter, but it also provides several code listings demonstrating how the conditions described in the chapter can occur that need to be scaled down.

Chapter 10: Coping with Failure

The final chapter of JavaScript at Scale provides the assertion, "As we scale our application, the approaches of how we deal with failures need to scale too." The chapter compares and contrasts failing fast and attempting to recover. The importance of quality constraints, meaningful feedback, fault tolerance, and disabling or even removing faulty components.

Chapter 10's coverage of fault recovery includes discussion regarding retrying failed operations, restarting components, requiring manual user intervention, and what to do when the application cannot be recovered. The chapter also looks at how addition of exception handling, state checking, intra-component notification, logging, and debugging can help deal with errors but also can lead to more scaling issues to consider. Like Chapter 9, Chapter 10 includes several code listings to illustrate its concepts.

The final paragraph of Chapter 10 also serves as the final summary paragraph for JavaScript at Scale. This paragraph articulates well in two sentences what the author hopes readers of this book get from the book: "To get the right answers, we first need to ask the right questions. I hope this book has equipped you with the requisite knowledge to formulate questions around scaling your JavaScript application."

General Observations

  • JavaScript at Scale emphasizes architectural and high-level design discussion related to scaling JavaScript applications rather than focusing on low-level implementation details (code, frameworks, libraries) that can be used to make JavaScript applications more scalable.
    • See my review of The Preface above for some of the author's comments that advertise this architectural emphasis in JavaScript at Scale.
    • See bullet below with details regarding author's blog post in which he further describes the architectural emphasis of JavaScript at Scale.
    • A prospective reader looking for a detailed account of exactly how to implement a one-size-fits-all scalable architecture will not find that elusive target here. A reader looking for general architectural principles to be considered when designing a JavaScript application so that it can scale in multiple directions and in response to multiple scalability "influencers" will be happier with this book.
    • See the last paragraph of my review of Chapter 10 above for more information on what the author advertised as the intention of this book. I believe that this book's strength is what he suggests: it can help JavaScript architects and developers come up with the questions they need to ask themselves to understand how to best implement and refactor a JavaScript application to be scalable.
  • The author of JavaScript at Scale has written a blog post that describes this book. The post articulates the focus of the book and includes this statement, "Architectural considerations get lost in all this choice [of JavaScript libraries and frameworks]." He adds that the information presented in JavaScript at Scale "is important information to have at our disposal when making architectural decisions, or when selecting a piece of technology to use in our application. With it, we can make informed choices about the scalability of our code, because code for one application is going to have different scaling characteristics than another application."
  • Although much of JavaScript at Scale is more discussion oriented than code-oriented, there are code listings in some of the chapters These listings feature black text on a white background even in the electronic edition (PDF) that I reviewed. There are no line numbers and no color syntax highlighting in the code listings. Most of the listings are small, but the longer ones can be more difficult to humanly parse without color coded syntax highlighting.
  • JavaScript at Scale is discussion-heavy and most of the writing is easy to follow. There are some typos (such as the use of "manor" when "manner" was intended), but these generally did not detract from the readability of the text.
  • The tone of JavaScript at Scale is generally like having a leisurely chat with a fellow architect about general JavaScript architectural questions and issues. At times, this was more verbose than I needed and I had to be careful not to skim too much because some really useful insights could be buried in the verbose prose. At other times, in areas in which I'm less familiar, the verbosity of text was helpful.


It is a common phrase in software development that there are no silver bullets and JavaScript at Scale doesn't try to sell that there is one when it comes to building scalable JavaScript applications. Instead, JavaScript at Scale identifies a myriad of issues for JavaScript architects and designers to consider in implementing and maintaining large-scale JavaScript applications. Although the readers of JavaScript at Scale are likely to be introduced to (or reminded of) some ideas to consider when making their applications more scalable, the author points out that there is really no way to summarize the approaches that work for all applications in all contexts. Instead, the author emphasizes the considerations that should be made in terms of several aspects of JavaScript application development and the possible approaches to deal with these different considerations as best fits each situation. Readers of JavaScript at Scale should be prepared to tailor what they're reading to their own applications' needs.

Friday, August 21, 2015

Book Review: Getting Started with Hazelcast - Second Edition

I recently purchased an electronic version of the Second Edition of Getting Started with Hazelcast as part of the recent Packt Publishing Skill Up Promotion. The book, written by Mat Johns, has the subtitle, "Get acquainted with the highly scalable data grid, Hazelcast, and learn how to bring its powerful in-memory features into your application." The book consists of eleven chapters and an appendix spanning approximately 120 pages.


The Preface of Getting Started with Hazelcast (Second Edition) provides brief descriptions of a sentence or two each summarizing the contents of the book's eleven chapters and its appendix. The Preface states that Getting Started with Hazelcast is intended for "Java developers, software architects, or DevOps looking to enable scalable and agile data within their applications." It recommends that readers have access to a JDK (at least JDK 6 but preferably JDK 8), a Java IDE, and Maven.

Chapter 1: What is Hazelcast?

The relatively short initial chapter of the Second Edition of Getting Started with Hazelcast introduces Hazelcast after first explaining the need for it with multiple simple graphics. The chapter describes Hazelcast as more than a cache and as an "in-memory data grid that supports a number of distributed collections, processors, and features."

Chapter 2: Getting off the Ground

The second chapter of Getting Started with Hazelcast explains and illustrates downloading Hazelcast from hazelcast.org/download/. The specific version downloaded and used for purposes of the Second Edition of Getting Started with Hazelcast is Hazelcast 3.5 (hazelcast-3.5.jar).

Chapter 2 demonstrates using ConsoleApp to use the command line to interact with simple Java applications using Hazelcast and to demonstrate Hazelcast's support for automatically supporting multiple clustered nodes. Code listings and associated explanatory text in this chapter introduce HazelcastInstance, working with an instance of distributed Map provided by HazelcastInstance.getMap(String), working with a distributed instance of Set provided by HazelcastInstance.getSet(String), working with a concurrent, distributed List instance provided by HazelcastInstance.getList(String), working with a concurrent, blocking, and distributed queue provided by HazelcastInstance.getQueue(String), and working with a distributed multimap instance (many values associated with a single key) provided by HazelcastInstance.getMultiMap(String).

Getting Started with Hazelcast's second chapter discusses "using predefined indexes" to search Hazelcast maps in a method similar to search capabilities provided by databases. This section provides an example of using SqlPredicate and lists the "limited subset of SQL" supported by SqlPredicate. The section also introduces other implementations of the Predicate interface (PredicateBuilder and PagingPredicate).

Another section of the second chapter covers using the hazelcast.xml file to configure Hazelcast for map eviction and covers the parameters named hazelcast.xml such as max-size, eviction-policy, and eviction-percentage.

Chapter 3: Going Concurrent

Chapter 3 of Getting Started with Hazelcast begins with more description on Hazelcast's IMap and IQueue, how they extend ConcurrentMap and BlockingQueue respectively, and the implications of those extensions. The chapter also introduces Hazelcast's distributed locking, its "cluster-wide unique identifier generator" (IdGenerator) and its JMS-inspired broadcast messaging system.

Chapter 4: Divide and Conquer

Getting Started with Hazelcast's fourth chapter begins with the assertion that Hazelcast's "distributed nature" of its "data persistence" enables applications to "achieve high levels of reliability, scalability, and performance." The chapter discusses partitions across clusters, partitions backing each other up, scaling up the cluster by adding more nodes, acquiring and using a ReplicatedMap to ensure data is available on every node, using partition groups, merge policies (PassThroughMergePolicy, PutIfAbsentMapMergePolicy, HigherHitsMapMergePolicy, and LatestUpdateMapMergePolicy), and Hazelcast 3.5 cluster quorums.

Chapter 5: Listening Out

The fifth chapter of Getting Started with Hazelcast discusses using Hazelcast's distributed events and listeners. The chapter introduces "collection listeners" (EntryListener, ItemListener, MessageListener, QuorumListener) and "cluster listeners" (DistributedObjectListener, MembershipListener, LifecycleListener, and MigrationListener). After the listing and briefy introductions to each of these listeners, the chapter delves more deeply into how they are configured (XML and in Java code) and can be used.

Chapter 6: Spreading the Load

Chapter 6 of Getting Started with Hazelcast discusses how Hazelcast provides the "ability to share the computational power in the form of a distributed executor" and how this is useful for "applications that require a lot of computational and data processing power." The chapter includes examples of applying IExecutorService, PartitionAware, HazelcastInstanceAware, and EntryProcessor.

Chapter 7: Gathering Results

Getting Started with Hazelcast's seventh chapter is its "big data" chapter. This chapter opens with an explanation of why "big data has proven to be a bit of a trendy buzzword of late." Brief history and background of MapReduce is provided. I like the simple explanation and graphic used in this introductory discussion regarding MapReduce.

Chapter 7 moves from general MapReduce theory to discussion of the Hazelcast's MapReduce implementation. It demonstrates via examples use of Reducer, JobCompleteableFuture, and working with Hazelcast aggregations with Java SE 6 and much more concise JDK 8 syntax.

Chapter 8: Typical Deployments

The eighth chapter of Getting Started with Hazelcast discusses determining the proper deployment strategy with Hazelcast for different types of applications. The chapter talks about "separat[ing] our application from the data cluster" and introduces Hazelcast's DataSerializable interface. The chapter concludes with coverage of "various architectural setups" that are described briefly, illustrated with simple graphics, and discussed in terms of trade-offs (advantages and disadvantages of each approach).

Chapter 9: From the Outside Looking In

Chapter 9 of Getting Started with Hazelcast covers two approaches for interacting with Hazelcast for non-Java/non-JVM clients. The chapter introduces the Hazelcast Memcache Client and provides simple demonstrations of using it with Python and PHP. The ninth chapter also introduces Hazelcast's support for REST APIs.

Chapter 10: Going Global

The tenth chapter of Getting Started with Hazelcast looks at using Hazelcast in conjunction with cloud computing environments. The main focus of the chapter is on two alternate "mechanisms of cluster discovery" to IP multicast: manually controlled unicast configuration and discovery via Amazon AWS management APIs. These configurations are shown by example with changes to the hazelcast.xml XML file. The chapter also discusses how to "configure Hazelcast to push entries from our local cluster to a remote cluster by defining a Wide Area Network (WAN) replication policy."

Chapter 11: Playing Well with Others

The final chapter of Getting Started with Hazelcast discusses how "Hazelcast provides ... support to use and extend a few popularly used libraries" and how Hazelcast "provides implementations of standardized interfaces." The chapter demonstrates using Spring with Hazelcast (hazelcast-spring-3.5.jar) for dependency injection, using Hibernate with Hazelcast (hazelcasthibernate3-3.5.jar/hazelcasthibernate4-3.5.jar) for caching of "legacy applications," using Hazelcast as an implementation of the standard JCache API, using Hazelcast's Cluster Management Center (mancenter-3.5.war), and enabling Hazelcast JMX support.

Appendix: Configuration Summary

The appendix provides a single location reference of the various Hazelcast configuration examples presented in the book's chapters.

General Observations

  • The author of Second Edition of Getting Started with Hazelcast, Mat Johns, is one of two currently highlighted Hazelcast Heroes. His "Hazelcast Cred" states, "Literally wrote the book on Hazelcast, entitled 'Getting Started with Hazelcast'."
  • The title "Getting Started with Hazelcast" is appropriate for this book. It delivers on providing a good starting point for installing, configuring, and beginning to use Hazelcast.
    • A reader of this book will be well equipped in terms of concepts and vernacular to reference Mastering Hazelcast, the highly approachable Hazelcast documentation, and blogs and forums on Hazelcast with the background and context provided by this book.
    • Other than the Hazelcast Manual and Mastering Hazelcast (both of which are provided by Hazelcast), the only book I have found devoted to Hazelcast is Getting Started with Hazelcast.
    • I appreciate that Getting Started with Hazelcast covers using Hazelcast in different architectural setups and provides a narrative the shows how differente Hazelcast features or deployments can be used to address different needs. The book not only shows the semantics or mechanics of using Hazelcast, but it also discusses why one would choose to use Hazelcast in different ways in different situations.
  • It's typically a good sign regarding a technical book's reception when there is more than one edition of that book. A quick browse of book reviews of the first edition of Getting Started with Hazelcast shows that this book has been generally well received.
    • The first edition of Getting Started with Hazelcast provides instructions on downloading and uses Hazelcast 2.6 for its examples while the second edition references Hazelcast 3.5.
    • The first edition of Getting Started with Hazelcast was published in August 2013 and this second edition was published in July 2015.
    • The second edition is roughly 20 pages lengthier than the first edition.
    • The second edition of Getting Started with Hazelcast adds three new chapters on trendy topics related to Hazelcast: 7 ("Gathering Results" / Big Data), 10 ("Going Global" / Cloud), and 11 ("Playing Well with Others" / Spring/Hibernate/JCache/JMX).
  • Most of the graphics in Getting Started with Hazelcast are simple graphics with black font on white background, though there are a few graphics with color and a few color screen snapshots in the electronic version of the book.
  • Code listings are black text on white background with no syntax color highlighting and no line numbers.
    • This was a more noticeable disadvantage when I was moving between the Hazelcast Manual, Mastering Hazelcast, and Getting Started with Hazelcast at the same time and the former two electronic publications have color-coded syntax.
  • There were a few minor grammar errors and typos, but for the most part Getting Started with Hazelcast is written in a format that's easy to read and comprehend.
  • I was happy to see coverage of JCache (JSR 107) in the second edition of Getting Started with Hazelcastr and to see brief mention of enabling Hazelcast's JMX support for monitoring.
  • I would have liked to see a bit more discussion in Getting Started with Hazelcast regarding the differences between Hazelcast Enterprise and Hazelcast.


Overall, I can recommend the second edition of Getting Started with Hazelcast to prospective readers. My only reservation regarding recommendation of this book has nothing to do with any fault of the book, but rather is a result of the excellent Hazelcast documentation that is already available. The Hazelcast Documentation and Mastering Hazelcast are both excellent resources with the former more introductory and the latter more intermediate. It is worth noting that downloading Mastering Hazelcast does require providing one's name and an e-mail address. I personally found that Getting Started with Hazelcast provided a nice overview and background about Hazelcast and why it's important that enabled me to quickly use these additional resources as well.