Dustin's Pages

Tuesday, December 31, 2013

At the end of each calendar year, I like to summarize some of the most significant developments in the software development industry that happened during the year that is ending. The choice of these is entirely subjective and obviously colored by my own experience, background, perceptions, and preferences. Not worrying about the opinionated content of such a post, I now present the developments in software development that I consider most significant in 2013.

Gradle appeared to me to enter the mainstream consciousness of software developers in a big way in 2013. I have been watching Gradle's development and playing with it a bit for some time now, but I have noticed that numerous open source projects now mention it prominently, it's referenced in many recently published Java books that aren't even about Gradle specifically, and Google selected Gradle to be delivered with its Android Studio product announced at Google I/O 2013. It took a while for Maven to breakthrough and compete with Ant and I think 2013 is seeing the beginning of Gradle's breakthrough to challenge Maven and Ant for predominance in Java-based build systems. Three books devoted to Gradle (the short Gradle: Beyond the Basics, the more comprehensive Gradle in Action, and the German Gradle: Modernes Build-Management - Grundlagen und Praxiseinsatz) have listed 2013 publication dates.

Gradle's success does not surprise me. It's Groovy foundation alone offers numerous advantages: Groovy scripts are easier to write procedural build-style code than is XML, Groovy has numerous syntactic shortcuts, Groovy is easily learned and applied by Java developers, Groovy has full JVM access, and Groovy includes built-in Ant support. On top of its inherent advantages from being built on Groovy, Gradle builds many useful and attractive features of its own on top of that Groovy foundation. Gradle adheres to several Ant and Maven conventions and supports Ivy and Maven repositories, making it straightforward to move from Maven or Ant+Ivy to Gradle.

Ruby on Rails helped bring Ruby into mainstream international prominence and, to a lesser degree, Grails helped do the same thing for Groovy. Gradle has the potential to pick up where Grails left off and push Groovy even further into the spotlight.

9. Trend Toward Single Language Development

For several years now, there has been a definite trend toward polyglot programming (polyglot persistence was even on last year's version of this post). Although this trend is likely to continue because some languages are better for scripting than others, some languages are better suited for web development than others, some languages are better suited for desktop development than others, some languages are better suited for realtime and embedded device development than others, some languages are better suited for scientific computing than others, and so on. However, I have seen indications of the pendulum swinging back at least a bit recently.

One of Ceylon's most promising possibilities is the ability to write code in Ceylon that works on both Java Virtual Machines and JavaScript virtual machines and so could be used front-to-back in a Ceylon-based application. Indeed, the Ceylon page advertises, "[Ceylon] runs on both Java and JavaScript virtual machines, bridging the gap between client and server." Languages commonly associated with the Java Virtual Machine such as Scala and Kotlin also are offering the ability to compile to JavaScript.

I'm not arguing that this trend means that there will only be one main programming language in the future. However, I do believe it is generally human nature to want to use the same language or approach as much as possible because it's what we're familiar with and using the same language helps us to leverage our experience more broadly in the same application. The trend seems to be for each of the major languages (C/C++, Java, JavaScript, Python, .NET languages, etc.) to continue building up their own "stack" to support end-to-end functionality within that language and its ecosystem of frameworks, libraries, and tools. It's no coincidence that once a new language starts to see significant adoption, it quickly begins to see development of a variety of frameworks, libraries, and toolkits that extend the reach of that language.

I also don't want to imply that this is the end of polyglot programming. I don't see any programming language that is the best fit in all cases and there is no doubt that the most valuable developers will be those familiar with more than one programming language.

On a lighter (or more dire, depending on your perspective) note related to The Internet of Things, Aaron Pressman writes, "The whole crazy 'Internet of Things' movement to put everything under network control seems tailor made for Hal" (2001: A Space Odyssey).

7. Mobile Development

If someone not familiar with our industry was to start reading our software development social media sites and forums, that person would likely come to the conclusion that the vast majority of software development today is development of mobile applications. I have long argued that blog posts and articles often skew toward more leading-edge topics than established topics for a variety of reasons (perception/reality that established topics are already well-covered, resume building, fun to play with and write about new things, etc.). That being stated, there is no question that mobile development is popular in reality and not just in perception. There is no question that a big part of HTML5's popularity and rapid adoption is the opportunity to write applications in one set of languages (HTML/JavaScript/CSS) that will run on multiple mobile devices. Numerous projects and tools are being released to allow for writing applications in one language and compiling them to native formats for various mobile devices.

The term "responsive web design" (or responsive mobile design) refers to websites that change and adapt their appearance for optimum viewing on all screen sizes, tablets, smartphones, ipods, kindles along with desktop and laptop computer screens. Occasionally, in the digital arts industry, it is called "fluid design", "adaptive website design" or "RWD". Unresponsive websites do not change to fit different screen sizes, which means they can be difficult to navigate and look at on smaller devices.

As a person who is using a smartphone for an increasing percentage of my daily online activities, but still uses the laptop frequently and the desktop occasionally, I am appreciating firsthand the web site authors whose web sites and pages work well on all of these devices. It's often satisfactory to have two different web sites (one for mobile devices and one for everything else) from a consumer point of view, but this obviously means essentially duplicate code for the site developers. Even from a consumer point of view, there are times when I find the mobile version of a site lacking in features and in those cases it'd be preferable to have the regular site on all devices as long as that regular site appeared nicely on all devices.

JavaScript, despite its flaws, has dominated the web browser for years. Although JavaScript on the server has been available for some time (such as with Rhino and more recently Nashorn in Java), Node.js seems to be doing for JavaScript on the server what Ruby on Rails did for Ruby: the framework is popularizing the language (or in this case, popularizing the language specifically on the server).

HTML5 saw initial hype, disappointed for a while, and seems to be back on its rapid rise in popularity. I don't call out JavaScript individually in this post, but group it with HTML and CSS as part of HTML5 (and its also grouped with Node.js in this post). Given that HTML5, for purposes of this blog post, represents all of these things, it easily makes my top three significant software development developments in 2013. As mentioned previously with regard to mobile development, HTML5 is a popular approach for generating applications once that can theoretically run on any mobile device.

HTML5 features are seeing increasing standardization in terms of implementations in major browser. JavaScript/HTML libraries such as Angular.js and Ember.js are building on the momentum that jQuery has brought to HTML5 development in recent years.

HTML5's success is even evident in languages not considered part of HTML5 themselves. For example, one of the most heavily advertisednew features of Java EE 7 is its HTML5 support. Recent versions of NetBeans IDE (considered primarily a Java IDE despite its multiple language support) have also seemed to emphasize HTML5 among their most important new features in 2013.

2. Security

As more information is online and we depend increasingly on availability of our data online, security continues to be an important issue for software developers. The trend of highly visibility security incidents continued in 2013. These incidents affected Ruby on Rails, Java, and other languages. The increasing frequency of security patches led Oracle to change how it labels the versions of Java SE.

Sadly, from a software development perspective, 2013 may be most remembered for the high profile technical glitches that occurred. Words like "debacle," "disaster," and "meltdown" have been associated with these issues and, rightly or wrongly, have reflected poorly on our industry. The most high profile dysfunction has been the embarrassing United States healthcare site healthcare.org. However, the issues that affect reputations and customer confidence have not been limited to government. Wal-Mart and Target, two major retailers in the United States, have had notable web site issues in the latter part of 2013 as well. Cloud-impacting technical dysfunction has occurred in 2013 in several notable cases including Amazon Web Services (AWS) and Google (including the search engine).

There seems to be plenty of blame to go around, but it seems difficult to get a good read on exactly what has caused these high profile technical failures. With healthcare.org, for example, I've seen people blame all types of different culprits including not allotting enough time to the effort, not being agile enough, being too agile, failing for despite agile approaches, failing to estimate user load correctly, getting government involved, etc. Although the real reasons are probably multiple and varied in nature and probably interest software developers more than others, the perception of our industry has gotten dinged up in 2013.

Honorable Mention

Although the developments in software development listed below did not make my top ten, they are significant enough to me to make this "Honorable Mention" category (in no particular or implied order).

JSON has been very popular with developers for some time now, but there have been many cases where standard libraries and tools that supported XML did not support JSON, meaning that developers had to write custom writing/reading code for JSON when using those libraries and tools. I'm beginning to see a lot more JSON support with tools and libraries now. Programming languages are also providing nice JSON parsing/writing capabilities. For example, Groovy has had JSON support for some time and Java EE 7 (JAX-RS 2.0) includes JSON support via the Java API for JSON.

The advantage of web applications over desktop applications has always been significant easier deployment of web applications than of desktop applications. The cost, however, has been a less fluid experience and sometimes less performing application than could be provided on the desktop. The concept of single-page applications is to make web (and by extension mobile applications that use traditional web technologies) feel and behave more like a "single-page" desktop application. Newer JavaScript libraries such as Meteor are being designed for the "thicker client" style of single-page applications.

It seems like one cannot read any software development social media sites without running across mention of AngularJS. Although its Google roots are undoubtedly part of its success, AngularJS enjoys success from cleanly addressing significant needs in HTML/JavaScript development (shifting appropriate dynamic functionality from pure JavaScript to HTML with clever binding). In his post 10 Reasons Why You Should Use AngularJS, Dmitri Lau states that "Angular is the only framework that doesn’t make MVC seem like putting lipstick on a pig." Jesus Rodriguez, in his post Why Does Angular.js Rock?, writes that AngularJS "excels in the creation of single-page-applications or even for adding some 'magic' to our classic web applications." K. Scott Allen writes in his post Why Use AngularJS?, "I like Angular because I have fun writing code on top of the framework, and the framework doesn't get in the way."

The famo.us web page currently requires one to "sign up for the beta" before being able to "experience famo.us." It's subtitle is "a JavaScript engine and framework that solve HTML5 performance." Another famo.us page states, "famo.us is a front end framework that solves performance for HTML5 apps" and "works for phones, tablets, computers and television."

There is a shift in the Web application platform, and specifically, people are starting to write a new kind of application, what we call a thick client, where most of the code is actually running inside the Web browser itself rather than in a data center. This is an architectural change from running the software in the data center and sending HTML on the wire to a model where we have data on the wire and the actual rendering, the displaying of the user interface, is happening on the client. ... That's why it feels more interactive. It's not page-based like the old Web. It's much more engaging."

Sun Microsystems was not the only company that saw desirable advantages and benefits from a single language that could be used at all layers of an application. Microsoft has implemented various efforts (Silverlight) for years to do the same thing. In 2013, Visual Studio 2013 was released with significant enhancements. These enhancements included improved support for languages not specific to Microsoft's .NET framework. Many of these better supported languages are on my list in this post: JavaScript, HTML, CSS, and Python.

Groovy 2.2's release was announced toward the end of 2013. This release improved Groovy's invokedynamic support by adding OSGi manifests to the Groovy's invokedynamic-based JARs.

In The Groovy Conundrum, Andrew Binstock writes that "with the performance issues behind it, Groovy is a language primed for widespread use," but warns that Groovy is a language that is "easy to learn, but hard to master."

As is mentioned more than once in this post, Groovy has had a lot of additional exposure in 2013 thanks to Gradle's rapidly rising popularity. I believe that Gradle will continue to introduce Groovy to developers not familiar with Groovy or will motivate developers who have not looked at Groovy for some time to look at it again.

November 2013 saw "the first production release of the Ceylon language specification, compiler, and IDE." This announcement, available online at Ceylon 1.0.0 is now available, also states, "Ceylon 1.0 is a modern, modular, statically typed programming language for the Java and JavaScript virtual machines." Ceylon offers an Elipse-based IDE and has a formal specification. One of the factors favoring a successful future for Ceylon is its Red Hat sponsorship.

It's still early to tell because Spring Boot is currently only at version 0.5, but Spring Boot has potential to be be widely adopted and used in the future. It looks like Spring Boot is inspired by and takes advantage of some of the best ideas in Ruby on Rails and Groovy and applies them to easy generation of Spring Framework-based applications.

Python

As stated earlier, Big Data is big and Python is getting a share of that Big Data action. The Continuum Analytics post Python for Big Data states, "Python is a powerful, flexible, open-source language that is easy to learn, easy to use, and has powerful libraries for data manipulation and analysis. ... Python has a unique combination of being both a capable general-purpose programming language as well as being easy to use for analytical and quantitative computing." Tal Yarkoni echoes this statement and observes that his "scientific computing toolbox been steadily homogenizing" on Python.

The article Python 3.4.0 goes to beta with slew of new modules talks about some of the new features coming with Python 3.4.0 (beta) such as a standard enumeration construct. The article also points out that one of the biggest frustrations with Python remains: the two versions of the language (2.x and 3.x) and no easy route from 2.x to 3.x. From a Java development perspective, I find this interesting because there was a time when arguments like Bruce Eckel's ("People who don't want to deal with these changes don't upgrade, and those people tend not to upgrade anyway") seemed logical and sensible. However, it's not quite as easy as it sounds, particularly when one starts to realize the impact of this on the entire set of products, libraries, and frameworks written for a language that can be heavily impacted and perhaps not usable for some time if ever with the new language.

The Facebook projectHHVM (HipHop Virtual Machine for PHP) was initially released in 2010, but seemed to see a lot more attention in 2013. The original HPHPc compiler compiled PHP into C++ and was another manifestation of the drive to use a single language for authoring an application even if its compiled form was different. The availability of the open source HipHop Virtual Machine (HHVM) for PHP should help address performance issues with PHP; that is seemingly Facebook's primary reason for developing it.

Interest in cloud computing remained strong and continued to grow rapidly in 2013. Many of the other items discussed in this post (Big Data, security, technical dysfunctions, etc.) have strong relationships to cloud computing. For more on the biggest cloud stories on 2013, see The 10 Biggest Cloud Stories Of 2013.

Internet Explorer 11

I have not used Internet Explorer except when forced to for a number of years. For a long time, I used Firefox almost exclusively and in recent years I've used Google Chrome almost exclusively on PCs and Firefox on Linux. When I have been forced by a particular web site to use Internet Explorer, I have done reluctantly and am reminded of the much slower performance of the browser than I'm used to in terms of startup and even navigation. I have noticed over this Christmas break, however, when I had to install Internet Explorer 11 manually because the automatic process kept failing, that it's a lot faster than even Internet Explorer 10 was. I still won't make it my primary browser, but it's nice that it performs much better when I do need to use it (such as to play Atari Arcade games without advertisements).

Windows 8 seems to be experiencing similar disappointment after Windows 7 that Windows Vista experienced after Windows XP. In fact, The 10 Biggest Software Stories Of 2013 states, "So it looks like Windows 7 will become the new Windows XP -- better get those downgrade rights ready."

The truth is that SQL never really went away and is heavily entrenched in software systems, but what is really interesting 2013 is the new thought and effort put into SQL development. word of Google's F1 SQL database ("a hybrid database that combines high availability, the scalability of NoSQL systems like Bigtable, and the consistency and usability of traditional SQL databases") is an example of this. Seth Proctor asks Do All Roads Lead Back to SQL? and writes of "NewSQL." In Software Development Trends for 2014, Werner Schuster states that "Many NoSQL DBs come with SQL or SQL-like languages" and asks, "Are SQL skills back in fashion?"

Conclusion

2013 may be remembered in popular culture as the year of selfies, but the developments in the software development world were far more substantive. In particular, it is interesting to see how developers in general are beginning to (or are remembering to) appreciate the ability to write an application front-to-back in a single language and to write responsive designs so that an application need be written only once for multiple platforms. The advantages of these approaches are not new to JVM (Java/Java EE) or CLR (.NET) developers, but seem to now be better appreciated by the more general developer community.

Previous Years' Significant Software Development Developments

The following are my posts similar to this one on items that I thought were of special import to software development in those respective years. I could definitely go back and add to some of these with things I've learned about since then for each of these years.

Monday, December 30, 2013

As I demonstrated in the post A First Look at Building Java with Gradle, Gradle is particularly concise and easy to apply to the basics of building a Java application when one uses the Java plugin and places files and directories where this plugin expects them (convention-based project layout). However, it is not always possible to have a structure (especially in legacy systems) meeting Gradle's expected conventions. In this post, I look at overriding some of the Gradle Java Plugin's conventions to allow a simple Gradle build to work with different directory structures.

The code listing that follows contains the Gradle code for a build build.gradle. I included comments in the build code to help explain what each type of customization is doing.

The Gradle build file shown above first applies the Java plugin. It then overrides the Gradle conventional locations for Java source files (highest level directory where subdirectories represent packages and files have .jar extensions), changing this directory from the default of src/main/java to simply java. Similarly, the default src/main/resources location for production resources is changed to simply resources.

The build file shown above then changes where the *.class files (with appropriate subdirectories representing their package structure) are placed by specifying that sourceSets.main.output.classesDir is now dist/classes (build/classes/main is conventional default). Similarly, the jar task's destinationDir is overridden to point to dist/jar (build/libs is convention) and this is where the JAR file generated by the jar task is written.

The final customization shown in the simple Gradle build script shown above is the specification of "repositories" and "dependencies" to make Guava Release 16 JAR available to my application (which happens to depend on Guava Release 16). Gradle provides sophisticated support for use of Maven or Ivy repositories including special syntax for Maven Central, but this particular example gets the Guava Release 16 JAR from my local file system (C:\guava16). The dependency itself is expressed with "guava:guava:16.0-rc1" because the JAR in that specified repository directory is called "guava-16.0-rc1.jar."

To make my testing of these customizations easier, I explicitly specified defaultTasks as clean and jar so that all I needed to do was type gradle on the command line as long as I was in the same directory as the build.gradle file shown above and as long as there was a "java" subdirectory at that level with the .java source files in their appropriate package-based directories.

Gradle's builds are most concise and easiest to write and read when Gradle's conventions are followed. However, it is not terribly difficult to override these conventions and specify customized configuration to match legacy systems.

The utility of being able to see the JSON in a tree-like manner in the Navigator and to code fold portions of the JSON is more obvious with more complex JSON. The next code listing and associated screen snapshots of that code in NetBeans 7.4 is based on JSON Example.

Even though proper indenting can go along way toward making JSON more readable, the visual cues provided by the Navigator Window in NetBeans 7.4 make it even easier to see the relationships of nested data in a JSON file. The code folding also allows one to minimize desired levels of nested name/value pairs to be able to focus on whatever portion is needed at a given time. JSON is increasingly popular because of advantages inherent in this simple name/value format, but NetBeans 7.4 provides tooling that makes JSON even easier to use.

Gradle: Beyond the Basics, as its name implies, assumes that the reader is already aware of "Gradle basics." The book provides no introduction to Gradle and assumes at least minimal knowledge of some related languages and tools as well (Groovy, Ant, Maven).

Gradle: Beyond the Basics is a very short book of four chapters and 67 pages of substantive content (not counting 8 pages of cover, Table of Contents, and Preface or the 3 pages of Afterword, advertisements, biography, and colophon). The subjects covered in the book are covered well with a lucid and easily understood writing style. The combination of the short length of the book and of the easy reading style make this book a quick read.

I particularly liked Chapter 2 of the book Gradle: Beyond the Basics and the way it demonstrated writing a plugin by first starting with added functionality in the main build and then refactoring that code into a plugin. I also especially appreciated the Liquibase-based examples used in this chapter.

Although I have not read the first book (Building and Testing with Gradle), the Amazon.com reviews of that book and its advertised length (116 pages) make me think these two books would have worked better as a single book. I'm guessing that the reasons they were written as two separate books are those expressed on the Gradle Books page (different aims) and to enable quicker publication of the first one.

Although I found Gradle: Beyond the Basics to be interesting and a useful read, I find it difficult to recommend purchase of it at a list price over $20 (USD) because of the amount of information covered and because some of the topics that are covered are also covered well in the Gradle User Guide (PDF). That stated, the book does have some low-level details that I have not seen in the User Guide and even subjects covered in the User Guide are covered with different perspective and approach in the book. The Amazon.comMarketplace currently has other options for purchasing the book for under $10 (plus shipping and handling) and this might be more appealing for purchasing this short book. The ebook/Kindle version of Gradle: Beyond the Basics might also be a cost effective choice.

Thursday, December 26, 2013

In my post A First Look at Building Java with Gradle, I briefly mentioned using Gradle's "gradle tasks" command to see the available tasks for a particular Gradle build. In this post, I expand on that brief mention a bit more and look at some related Gradle command-line conveniences.

Gradle makes it easy to determine available Gradle tasks for a given project. The next screen snapshot demonstrates using gradle tasks (or gradle :tasks) in the same directory as the simple Gradle build file (build.gradle) I used in my previously mentioned Gradle post. The screen snapshots follow the code listing of build.gradle which is reproduced here for convenience.

Basic Java Application build.gradle

apply plugin: 'java'

Adding --all to gradle tasks (gradle tasks --all) will show even more details (including tasks' dependencies) as shown in the next screen snapshot.

Something I used to do often when working with an Ant build file new to me was to add a target "showProperties" that used a series of Ant echo tasks to display the properties used by that build file. Gradle provides essentially this capability out-of-the-box. The next screen snapshot demonstrates use of gradle -q properties to display the properties associated with the Gradle project and tasks in the build.gradle file in the same directory.

Another useful command-line Gradle option is --profile. This can be used in conjunction with running a Gradle command. For example, gradle tasks --profile generates the same standard output as shown above, but also writes build performance statistics to a file with the naming convention profile-YYYY-MM-DD-HH-mm-ss.html in the build/reports/profile subdirectory of the directory from which the build was executed. An example of that generated file is shown next.

The final Gradle command-line option I cover in this post is the "dry run" option -m (or --dry-run). This option allows one to see the Gradle tasks which are run and the order in which they are run without actually executing those tasks. Because the one-line Gradle build.gradle file used in this post applies the Java plugin, the automatically added Gradle Tasks include compileJava, classes, jar, and javadoc. The following screen snapshot demonstrates running gradle -m jar to see the dry run output that shows the dependent tasks that must be run before "jar" and the order they must be run (compileJava->processResources->classes->jar). Note "SKIPPED" notation indicating that the Gradle tasks are not actually executed.

The Preface of Java EE 7 First Look outlines the objective of the book: "This book does not aim to show how to implement the different aspects of each Java EE 7 specification or list the best practices. Rather, ... this book will help you discover the innovations introduced by Java EE 7 and gives you ideas to build solid applications.

The Preface lists four things software products necessary "to implement the various examples present in this book": NetBeans IDE 7.3.1+, JDK 7, GlassFish 4 b89+, and MySQL 5.5+. Although all of these are used in the book, only a fraction of the examples directly use NetBeans, GlassFish, and MySQL in approaches specific or exclusive to those tools. Many of the examples could be run without those specific tools with few and minor adjustments.

According to the Preface, the book is targeted primarily at three types of individuals: Java EE beginners, experienced Java EE developers wanting to learn the new Java EE 7 features, and architects wanting to learn how to put the covered technologies together to build "robust and secure enterprise applications." For reasons that I state at the end of this post, my opinion is that this book is best suited for the second group (experienced Java EE developers wanting to learn the new Java EE 7 features).

The chapter provides a summary of how important concurrency has become in modern software development and why Java EE containers formally did not support concurrency. It then looks at the most important interfaces supporting concurrency in Java EE applications.

The second chapter's coverage of Java API for JSON Processing begins with a brief introduction to JSON, which it describes as "a lightweight data-interchange text format" that is "based on a subset of JavaScript, but is completely language independent." I liked the section in this chapter that compared XML to JSON and provided a fairer representation of their respective advantages and disadvantages than one often sees in modern software development literature.

Chapter 4 moves from coverage of new JPA 2.1 features to new JTA 1.2 features. This section follows the pattern established in this and earlier chapters of first explaining the overall technology and showing a code listing example of the concept before moving onto new features. New JTA 1.2 features covered in this chapter are two new annotations (javax.transaction.Transactional and javax.transaction.TransactionScoped) and a single new exception (javax.transaction.TransactionalException). The new JTA 1.2 features are covered with significantly less detail than provided for the new JPA features.

Chapter 5: The Business Layer

The fifth chapter of Java EE 7 First Look covers EJB 3.2 and "putting all Java EE 7 specifications together." The chapter describes the "business layer of an application" between the database and presentation layers and how EJB is part of that business layer. The chapter talks about features of EJB that are made optional in Java EE 7 and are now covered in a separate EJB 3.2 Optional Features for Evaluation document. The author states that EJB 3.2 only adds minor enhancements to EJB and then briefly outlines enhancements to stateful sessions beans and provides code examples and descriptions of each.

Improvements in EJB 3.2 for EJB Lite (introduced in EJB 3.1 [Java EE 6]) are covered next. Text and code examples are used to describe these EJB Lite enhancements as well.

Chapter 5 moves to a brief introduction to Java Message Service (JMS) and Message-Driven Beans (MDB). Brief coverage of how EJB 3.2 has been adjusted to conform to JMS 2.0 follows. The author points out that EJBContainer, first introduced with EJB 3.1, now implements the AutoCloseable interface, meaning that it can participate in the try-with-resources mechanism introduced with Java SE 7.

The remainder of Chapter 5 is on "putting it altogether." This section includes several UML diagrams and design artifacts and, without any code, discusses requirements of the sample project.

Java API for RESTful Web Services 2.0 is the final major topic of Chapter 6. This section begins by considering web services and when to use them generally, but then explicitly states that the book focuses only on REST-based web services. I've been excited about JAX-RS 2.0 (see my review of related book ) and was glad to see several new features of JAX-RS 2.0 covered in this section: Client API, asynchronous processing, and filters and entity interceptors.

Context Dependency Injection (CDI) is covered next. Like the annotations and most other concepts in this book, it is introduced generally first before coverage of new features begins. Quite a few code examples demonstrate how to use CDI in a variety of different situations. The coverage of new CDI 1.1 features includes @Vetoed, use of CDI.current() to "access the current CDI container programatically," and use of AlterableContext "to allow explicit destruction of bean instances in applications."

Chapter 8: Validators and Interceptors

The Java EE 7 specifications focused on in Chapter 8 are Bean Validation 1.1 (JSR 349) and Interceptors 1.2 (JSR 318). The chapter's coverage of Bean Validation begins with a table of built-in constraints, followed by examples and discussion of applying constraints. The section includes with coverage of implementing custom constraints. After devoting quite a few pages to illustration of and examples of using Validation, the section begins coverage of new Java EE 7 features of Validation including open sourcing of Bean Validation implementation, CDI/dependency injection integration and the ability to validate parameters of methods and constructors and return types on methods.

The ninth and final chapter of Java EE 7 First Look is on security. The chapter introduces Java Authentication SPI for Containers (JASPIC) [JSR 196]. The author describes the JASPIC specification as "a set of standard interfaces for the development of modules for authentication, which allow secure access to web resources (Servlets, JSP, and so on), among others." There are numerous pages of code listings, illustrative text, and screen snapshots devoted to covering implementing JASPIC with GlassFish. The chapter then moves onto new features introduced with "Maintenance Release B of JASPIC Specification." New features covered include increased level of standardization of how authentication is handled across different servers and how the application context provider is identified and support for forward and include mechanisms.

General Observations

Nearly every introduced Java EE 7 new feature covered in this book was covered only after an overall description of the specification including its history and general usage before the new features were available.

The brief review of a specification's history and illustration of using that specification provides a nice review before jumping into what's new in Java EE 7 about that specification.

Although this review of existing specifications provides is helpful for those who have used Java EE to some degree before, I doubt these reviews would be sufficient background for someone entirely new to Java EE.

A true Java EE beginner would probably be better off learning Java EE in a fashion that integrates all versions of Java EE rather than focusing primarily on the latest version of Java EE (such as via the Java EE 7 Tutorial).

Java EE 7 First Look is generally well-written and I only found a few typos, most of which were extremely minor. The most obvious were a couple cases where Java class or interface names had their first letter in lowercase even though that class or interface actually follows the Java convention of beginning with a capital letter.

Java EE 7 First Look seems particularly well suited for someone who has used Java EE before, but has little or no exposure to Java EE 7.

Java EE 7 First Look is about 165 pages of prose when one doesn't count the index and advertisements for related Packt Publishing books. The nine chapters don't have a lot of extra fluff and remain focused on covering Java EE 7 features, how they improve existing Java EE support, and how they can be used together.

Conclusion

Java EE 7 First Look provides convenient access to the features of Java EE 7 that will help Java EE developers be more productive and accomplish more for their clients. Although most of these features are described in detail in blogs, articles, and in the Java EE 7 Tutorial, Java EE 7 First Look collects all of them in one place and keeps its focus on the new features with only brief references to historical information and previous Java EE versions. Java EE 7 First Look provides an overall view of the collective benefit of Java EE 7 new features with some attention paid to implementing these features individually and with one another.

Anyone interested in the e-book version of Java EE 7 First Look might want to take advantage of the Packt Publishing Ebook Bonanza that runs through 3 January 2014, offering the electronic version of this book for $5 (USD).