Play for Java

Nicolas Leroux, Sietse de Kaper

• Publisher: Manning Publications
• Year: 2014
• ISBN:
  9781617290909
• Topic: Computer Science
• Subtopic: Web Programming
• Index: Computer Science

Play for Java shows you how to build Java-based web applications using the Play 2 framework. The book starts by introducing Play through a comprehensive overview example. Then, you'll look at each facet of a typical Play application, both by exploring simple code snippets and by adding to a larger running example. Along the way, you'll contrast Play and JEE patterns and learn how a stateless web application can fit seamlessly in an enterprise environment.

Part 1. Introduction and first steps

In Part 1, we introduce Play and show the basics of creating a Play application.

Chapter 1 introduces Play, its core concepts, and its key features. We install Play and create our first application.

Chapter 2 breaks down the structure of a Play application, explaining what each file and folder is for.

Chapter 3 shows how to create a more fleshed-out application, giving you a taste of the key MVC components in a Play application.

Chapter 1. An introduction to Play

This chapter covers

• What the Play framework is
• What high-productivity web frameworks are about
• Why Play supports both Java and Scala
• Reactive programming
• Play 2 enterprise features
• What a minimal Play application looks like

Play isn’t really a Java web framework. Java’s involved, but that isn’t the whole story.

The first version of Play may have been written in the Java language, but it also ignored the conventions of the Java platform, providing a fresh alternative to excessive enterprise architectures. Play was not based on Java Enterprise Edition APIs and made for Java developers; Play is for web developers.

Play wasn’t written for web developers, it was written by web developers, and they brought high-productivity web development from modern frameworks like Ruby on Rails and Django to the JVM. Play is for productive web developers.

Play 2 is written in Scala, but that doesn’t mean you have to write your web applications in Scala or even know anything about Scala. This is because Play 2 comes with a complete Java API, giving you the option to pick the language that suits you best. If you’ve used Play 1.x before, you’ll notice that the API has become more type-safe.

Play isn’t about Scala and type safety, either. An important aspect of Play is the usability and attention to detail that results in a better developer experience (DX). When you add this to higher developer productivity and more elegant APIs and architectures, you get a new emergent property: Play is fun.

1.1. What Play is

Play is fun. Play makes you more productive. Play is also a web framework whose HTTP interface is simple, convenient, flexible, and powerful. Most importantly, Play improves on the most popular non-Java web development languages and frameworks—PHP and Ruby on Rails—by introducing the advantages of the Java Virtual Machine (JVM).

1.1.1. Key features

A variety of features and qualities make Play productive and fun to use:

• Simplicity
• Declarative application URL scheme configuration
• Type-safe mapping from HTTP to an idiomatic Scala or Java API
• Type-safe template syntax
• Architecture that embraces HTML5 client technologies
• Live code changes when you reload the page in your web browser
• Full-stack web-framework features, including persistence, security, and internationalization
• Support for event-driven, resilient, and scalable applications

We’ll get back to why Play makes you more productive, but first let’s look a little more closely at what it means for Play to be a full-stack framework. A full-stack framework gives you everything you need to build a typical web application, as illustrated in figure 1.1.

Figure 1.1. Play framework stack

Being “full stack” is not only a question of functionality, which may already exist as a collection of open source libraries. After all, what’s the point of a framework if these libraries already exist and already provide everything you need to build an application? The difference is that a full-stack framework also provides a documented pattern for using separate libraries together in a certain way, and therefore provides confidence that a developer can make the separate components work together. Without this, you never know whether you’re going to end up instead with two incompatible libraries or a badly designed architecture.

When it comes to building a web application, what this all means is that the common tasks are directly supported in a simple way, which saves you time.

1.1.2. Java and Scala

Play supports Java, and is in fact the best way to build a Java web application. Java’s success as a programming language, particularly in enterprise software development, means that Play 1.x has been able to quickly build a large user community. If you’re planning to use Play with Java, you particularly get to benefit from this community’s size.

But recent years have seen the introduction of numerous JVM languages that provide a modern alternative to Java, usually aiming to be more type-safe, resulting in more concise code and support for functional programming idioms, with the ultimate goal of allowing developers to be more expressive and productive when writing code. Scala is currently the most evolved of the new statically typed JVM languages, and it’s the second language that Play supports. Scala is meant (and proven) to be a scalable language, hence the name. Play 2 takes full advantage of the scalability that Scala offers, which means your Java applications will get these benefits, too.

Scalability is one of the major features of Play: it allows you to easily create highly scalable web applications. Scalability can mean a lot of different things, and throughout the book you’ll see examples of how Play enables you to scale both horizontally and vertically. Most of this is thanks to Play’s stateless nature, but also its foundation of Scala (and Akka), which enabled the developers of the framework to provide concurrent and nonblocking request processing. It also enabled developers to support applications in an event-driven way without sacrificing scalability. Nowadays, applications need to react to events and display live feeds rather than batch process during the night. Play was conceived with this perspective in mind. We’ll talk more about this subject in the reactive programming section in this chapter.

Our sister book: Play for Scala

If you’re also interested in using Play to build web applications in Scala, then you should look at Play for Scala, which was written at the same time as this book. The differences between Scala and Java go beyond the syntax, and the Scala book is much more than a copy of this book with code samples in Scala. Play for Scala is focused on the idiomatic use of the Scala language with Play 2.

1.1.3. Play is not Java EE

Before Play, Java web frameworks were based on the Java Servlet API, the part of the Java Enterprise Edition (Java EE) stack that provides the HTTP interface. Java EE and its architectural patterns seemed like a really good idea, and brought some much-needed structure to enterprise software development. But this turned out to be a really bad idea, because structure came at the cost of additional complexity and low developer satisfaction. Play is different, for several reasons, which we’ll detail later in this chapter. The biggest difference between Java EE and Play is simplicity. Play focuses on providing simplicity to developers so that they can focus on their business problems and not on the framework itself. In contrast, Java EE used to be quite complex.

Java’s design and evolution is focused on the Java platform, which also seemed like a good idea to develop...