FACILITATING THE SPREAD OF KNOWLEDGE AND INNOVATION IN PROFESSIONAL SOFTWARE DEVELOPMENT Java 9 and Beyond eMag Issue 37 - January 2016
ARTICLE ARTICLE ARTICLE Programming with Java 9’s New HTTP/2 A Post-Apocalyptic modularity and and REPL sun.misc.Unsafe
Project Jigsaw Java 9 and Beyond // eMag Issue 37 - Jan 2016World 1 Programming with Java 9’s New HTTP/2 and modularity and REPL Project Jigsaw Java 9 will not just be about modularity; it is targeting a large number of additional pieces of functionality. In this article A Tutorial Using the Latest Release Candidate Ben Evans dives into HTTP/2 support and the JShell REPL – Project Jigsaw is the hallmark feature of Java (Read-Eval-Print-Loop) that brings shell-based interactive 9, the next major version release of Java, and is Java development, two new JEPs that may well have the big- destined to bring modular programming into the gest impact on developers’ working lives during the lifetime Java mainstream. After years of negotiating and of Java 9. myriad JSRs and JEPs, Jigsaw is starting to take its final form. This tutorial considers all aspects of programming and migration to Project Jigsaw.
Case for Defaulting to G1 Garbage Collector in Java 9 In this article, GC expert Monica Beckwith makes the case for JEP 248, the proposal to make G1 the default garbage collector in OpenJDK 9.
A Post-Apocalyptic sun.misc. Unsafe World The removal of sun.misc.Unsafe and other private APIs in Java 9 has in recent weeks divided the Java community per- haps as never before in its 20 year history. Even though a resolution has now been proposed and a migration path pre- sented, the big question remains: What will a post sun.misc. Unsafe world look like?
The OpenJDK Revised Java Memory Model The existing Java Memory Model covers a lot in terms of Java language semantic guarantees. In this article we will delve into a few of those semantics, and attempt to communicate the motivation for an update to the existing Java Memory Model
FOLLOW US CONTACT US GENERAL FEEDBACK [email protected]
ADVERTISING [email protected]
EDITORIAL [email protected] facebook.com @InfoQ google.com linkedin.com /InfoQ /+InfoQ company/infoq is the Java queue lead at InfoQ. Inducted as an VICTOR Oracle Java Champion in 2012, Victor works at GRAZI Nomura Securities on building core tools, and as a technical consultant and Java evangelist. He is also a frequent presenter at technical conferences. Victor hosts the “Java Concurrent Animated” open source project on SourceForge.
A LETTER FROM THE EDITOR
If there were ever any question that Java was the test Java code snippets without having to deal with de facto standard for server side enterprise develop- class structures and compilers. ment, Java 8 has certainly quelled that one. The world If Java didn’t invent the science of Garbage col- now anxiously awaits Java 9 and the innovations it lection, it has almost certainly contributed more than promises. Oracle has slated Java 9 for a March 2017 any other language to that technology. Garbage First release. (affectionately know as G1GC) is the latest offering in In this eMag, we take a look at what’s on the that space, and promises to support huge heaps with scheduled horizon for Java 9 and beyond. minimal stop-the-world pauses. In this piece, former Project Jigsaw is the hallmark feature of Java 9 Oracle GC performance lead Monica Beckwith weighs and is destined to bring modular programming into the benefits of making G1GC the default against pro- the Java mainstream. After years of negotiating and tests that it might not be ready for prime time. myriad JSRs and JEPs, Jigsaw is starting to take its fi- Then low latency expert Christoph Engelbert nal form. Nicolai Parlog gives us the definitive guide looks at another controversial issue, the deprecation to all aspects of programming and migration to Proj- of sun.misc.Unsafe, a widely-used little class that to ect Jigsaw. date has broken all of the rules of Java safety. Then Ben Evans takes a look at two long awaited Finally, the Java Memory Model has served Java Java features, HTTP/2 and REPL. HTTP/2 addresses an- well for all of these years but over time optimizations noying problems coming from the rather rusty HTTP and alternatives have been requested. Monica Beck- support in Java. REPL is a shell scripted version of Java with looks at some of the modifications to the Java that allows developers to quickly and interactively Memory Model being discussed for Java 10. There’s nothing about Java that AppDynamics doesn’t see. AppDynamics gives you the visibility to take command of your Java application’s performance, no matter how complicated or distributed your environment is.
Events Health Rule Violations Started 2
Internet Overall Application Performance 1 Information IIS Services AppDynamics Internal Diagnostics 1 Device Business Transaction Health
Java 1 critical, 0 warning, 36 normal Server Health
0 critical, 5 warning, 1 normal Java Transaction Scorecard Java Normal 83.1% 963 Slow 0.3% 4 Very Slow 1.3% 15 Java Stall 0.2% 2 Errors 15.1% 175
Shipments DB
Java
When your business runs on Java, count on AppDynamics to give you the complete visibility you need to be sure they are delivering the performance and business results you need — no matter how complex, distributed or asynchronous your environment, live ‘in production’ or during development.
See every line of code. Get a complete view of your environment with deep code diagnostics and auto-discovery. Understand performance trends with dynamic baselining. And drastically reduce time to root cause and remediation.
See why the world’s largest Java deployments rely on the AppDynamics Application Intelligence Platform. Sign up for a FREE trial today at www.appdynamics.com/java.
appdynamics.com Advertising Feature What’s exciting about Java 9 and Application Performance Monitoring by Aakrit Prasad Principal Product Manager of APM products at AppDynamics
Constant innovation in software is driving us toward a software revolution. That may be how the 21st century will be best remembered. Among the popular software languages out there, however, Java continues to have the largest industry footprint, running applications around the globe that produce a combined annual revenue measuring trillions of dollars. That’s why keeping up on the JDK is a high priority. Despite having a massive API to improve programming productivity, Java has also grown due to its high-performance yet scalable JVM runtime, which ranks among the fastest computing applications. As Java’s footprint expands, JDK innovations continue to impact billions of lines of code. As AppDynamics continues to grow, our focus towards supporting Java is only furthered by our customer use and industry adoption of the JVM. Discussion of Java 9 have been growing since the release of Java 8 in March 2014. The scope of various JDK enhancements originally targeted for Java 9 has narrowed as the proposed release date of September 2016 has approached. Over 30 key enhancements, those with the potential for broadest impact, will be shared, and discussion of some of these follows. Project Jigsaw Among the most popular Web proto- Segmented Code Cache cols, HTTP has been getting its own The JVM codecache is critical to ap- upgrade to HTTP/2 (with inspiration plication performance and can be set from Google’s SPDY/2), which boasts at startup time using the -XX:Initial- significant network performance CodeCacheSize=32m flag. When the gains. Java 9 will get its own HTTP codecache memory is exhausted, the client API that implements HTTP/2 JVM losses JIT and goes into interpret- and WebSocket to replace the legacy ed mode, significantly affecting appli- HttpURLConnection, which predates cation runtime performance. In Java HTTP/1.1 and has limitations such as 9, this section of memory is getting the “one thread per request/response” Project Jigsaw contains some of the divided into the three distinct heap behavior. Using HTTP/2 in Java 9, ap- JDK 9 enhancements with greatest segments in order to improve perfor- impact. Jigsaw’s primary goals are to plications will perform and scale bet- mance and enable future extensions: make the JDK more modular and to ter with memory usage on par with JVM internal (non-method) code, pro- enhance the build system. The needs or lower than HttpURLConnection, filed-code, and non-profiled code. to make Java more scalable for smaller Apache HttpClient, and Netty. computing devices, to make it secure, Other Notable mentions and to improve performance and de- jShell Other notable changes in JDK 9 will veloper productivity have driven Jig- include making the G1 collector the saw. With the advent of the Internet default, adding a Microbenchmark of Things (IoT), enabling Java to run testing suite that extends the current on smaller devices is instrumental for JMH, and the removal of some aged continued growth but as Java’s foot- and unsupported performance tools print expands, the vast permutation such as JVM TI hprof and jHat. of computing services it runs on have made it more prone to security target- In jShell, also referred to as Java REPL Summary ing and performance lags. With a more (read-eval-print-loop), JDK 9 users will Although programming languages modular JDK, developers can signifi- find a shell-like interface to interactive- tend to come and go, Java is here to cantly reduce the number of libraries ly evaluate declarations, statements, stay (least for the foreseeable decade) needed to build features, thereby re- and expressions in Java. Like when as one of the most popular and wide- ducing security risks and the size of they use Python or Ruby interpreters ly adopted languages with its highly an application while increasing perfor- or other JVM languages like Scala and performing, scalable runtime. JDK in- mance (e.g. improving code cache and Groovy, Java users will be able to run novations have a large impact on the class-loader footprint, etc.). Java code without needing to wrap in world’s computing infrastructure. By classes or methods, allowing for much staying current with what’s in the next HTTP/2 Client easier, faster learning and experimen- JDK, firms running JVM services can tation. Furthermore, as Java becomes intelligently plan and prioritize inno- a less syntactically verbose language vation initiatives that are complemen- with features like Lambda introduced tary to language improvements. All in JDK 8 (shared in our Java 8 blog last those excited yet impatient developers year), having a shell-like interface be- looking to get to work on the future comes more practical for ad hoc test- can access the latest JDK 9 builds here: ing. https://jdk9.java.net/download/
Reference: http://openjdk.java.net/projects/jdk9/ Read online on InfoQ Programming with modularity and Project Jigsaw. A Tutorial Using the Latest Early Access Build
Nicolai Parlog is a software developer and Java enthusiast. He constantly reads, thinks and writes about Java, and codes for a living as well as for fun. He’s a long tail contributor to several open source projects and blogs about software development on CodeFX. You can follow Nicolai on Twitter.
Software can be seen as a system of interacting parts and in Java it is common to package each of those parts in its own JAR. Conceptually a part consists of three properties: a name, a public API for the rest of the world to use, and dependencies on other parts. This graph-like model helps developers and tools dissect, analyse, and work with software systems.
But none of those properties exist inside the Java depend on each other. And on the other hand there runtime, which uses the classpath to access a bunch is the runtime reality of a single, almost entirely un- of JARs and simply rolls them all into one big ball of structured namespace. This mismatch is the driving mud. Any distinction between JARs is entirely lost force behind what is affectionately known as JAR and only a flat set of packages remains, with no ca- hell, and dependencies on internal APIs. It also caus- pability of further validation. So important questions es bad start-up performance and weakens security. like “are these all required JARs?”, “are these even the Project Jigsaw will enhance the compiler and correct JARs?”, “are there conflicts?”, or “are only pub- runtime to come closer to the structured model. Its lic APIs used?” cannot be answered by the running main goals are reliable configuration (by declaring JVM. dependencies) and strong encapsulation (by hiding So on one hand there is a well-structured mod- internals) and its agent for both is the concept of el of how a system is modularized and how its parts modules.
6 Java 9 and Beyond // eMag Issue 37 - Jan 2016 Introducing Modules This means that public is no longer really pub- Quoting from the highly recommended design over- lic. A public type in a non-exported package is as view “State of the Module System” by Oracle chief ar- hidden from the outside world as a non-public type chitect Mark Reinhold: in an exported package. So “public” is the new pri- A module is a named, self-describing collection of vate, being even more hidden than package-private code and data. Its code is organized as a set of packag- types are today, because the module system does es containing types, i.e., Java classes and interfaces; its not even permit access via reflection. As Jigsaw is data includes resources and other kinds of static infor- currently implemented, command line flags are the mation. only way around this. To control how its code refers to types in other So accessibility builds on top of readability and modules, a module declares which other modules it re- the export clauses, creating the basis for strong en- quires in order to be compiled and run. To control how capsulation, where a module author can clearly ex- code in other modules refers to types in its packages, a press which parts of the module’s API are public and module declares which of those packages it exports. supported. So in contrast to a JAR, a module has a name that is recognized by the JVM, declares which other Example: Creating Our First Module modules it depends on, and defines which packages Say we have an application that monitors microser- are part of its public API. vices running in our network. It periodically contacts them and uses their responses to update a database Name table as well as a nifty JavaFX UI. For the time being, Module names can be arbitrary but must not conflict. let’s assume that the application is developed as a To that end it is recommended to use the standard single project without any dependencies. inverse-domain-name pattern of packages. While Now let’s switch to Java 9 with Jigsaw! (The this is not obligatory it will often mean that the mod- early access builds are available on java.net - the ule name is a prefix of the packages it contains. code samples and commands presented in this arti- cle were created for build 96 from December 22nd.) Dependencies & Readability While jdeps, the Java dependency analyzer, already A module lists the other modules it depends on to exists in JDK 8, we need to use the JDK 9 version so compile and run. Again from the “State of the Mod- that it knows about modules. ule System”: The first thing to note is that we can simply When one module depends directly upon another choose to ignore modules. Unless the code is relying [...] then code in the first module will be able to refer to on internal APIs or some other JDK implementation types in the second module. We therefore say that the details (in which case things will break), the applica- first module reads the second or, equivalently, that the tion can be compiled and executed exactly as with second module is readable by the first. Java 8. Simply add the artifact (and its dependencies […] if it has any) to the classpath and call main. And voilà, The module system ensures that every depen- it runs! dence is fulfilled by precisely one other module, that no To move the code into a module we must cre- two modules read each other, that every module reads ate a module descriptor for it. This is a source code file at most one module defining a given package, and that called module-info.java in the source directory’s modules defining identically-named packages do not root: interfere with each other. 001 module com.infoq.monitor { This concept of readability is the basis of reli- 002 // add modules our application able configuration: When any condition is violated, requires the module system refuses to compile or launch 003 // add packages our application the code; an immense improvement over the brittle exports classpath model. 004 } Our application is now a module with the name Exports & Accessibility com.infoq.monitor. To determine which modules A module lists the packages it exports. A type in one it depends on, we can use jdeps: module is only accessible by code in another module if: 001 jdeps -module ServiceMonitor.jar • the type is public • the containing package is exported by the first This will list the packages our application uses module and, more importantly, from which modules they • the second module reads the first come: java.base, java.logging, java.sql,
Java 9 and Beyond // eMag Issue 37 - Jan 2016 7 javafx.base, javafx.controls, javafx. easy to create a runtime with just the desired mod- graphics. ules. With our dependencies covered we can now All Java code depends on Object and virtually think about which packages we might export. Since all code uses basic features like threading and col- we are talking about a stand-alone application, we lections. These types can be found in java.base, won’t export anything. which plays a special role; it is the only module that Together we get: the module system knows about, and since all code 001 module com.infoq.monitor { depends on it, all modules automatically read it. 002 requires java.base; // see more So in our example above, we would not need to about that below declare a dependency on java.base. 003 requires java.logging; Non-platform modules are called application 004 requires java.sql; modules and the module used to launch an applica- 005 requires javafx.base; tion (the one containing main) is the initial module. 006 requires javafx.controls; 007 requires javafx.graphics; Modular JARs 008 // no packages to export As we have seen above, Jigsaw still creates JARs, al- 009 } beit with the new semantics. If they contain a mod- Compiling is the same as without Jigsaw except ule-info.class they are called modular JARs, we have to include module-info.java in the list of about which “State of the Module System” says: source files: A modular JAR file is like an ordinary JAR file in all possible ways, except that it also includes a module-in- 001 javac -d classes/com.infoq.monitor fo.class file in its root directory. ${source files} Modular JARs can be put on the classpath as Now that all classes were compiled into class- well as on the module path (see below). This allows es/com.infoq.monitor, we can create a JAR from projects to release a single artifact and let its users them: decide between the legacy or the modular approach to application building. 001 jar -c 002 --file=mods/com.infoq.monitor.jar \ Module Path 003 --main-class=com.infoq.monitor. Platform modules are part of the currently used en- Monitor \ vironment and hence are easily available. To let the 004 ${compiled class files} compiler or VM know about application modules, we The new --main-class can be used to speci- have to specify a module path with -mp (as we have fy the class containing the application’s entry point. done above). The result is a so-called modular JAR, which we will The platform modules in the current environ- discuss further below. ment and the application modules from the module In stark contrast to the old model, there is a path together comprise the universe of observable whole new sequence to launch the application. We modules. Given that set and an initial module con- use the new -mp switch to specify where to look for tained therein the virtual machine can create a mod- modules, and -m to name the one we want to launch: ule graph. java -mp mods -m com.infoq.monitor To understand this a little better, let’s talk about Module Graph how the compiler and the virtual machine handle Starting from the initial application module, the modules. module system resolves all of its transitive depen- dencies . The result is the module graph where mod- ules are nodes and a dependency of one module on Java And The Modules another is a directed edge. Kinds Of Modules For our example, that looks like this: (Figure 1) The JDK itself was modularized and consists of about The platform modules are shown in blue, where 80 platform modules (have a look at them with java the brighter modules are the ones we depend on di- -listmods). The ones that will be standardized for rectly and the darker ones transitive dependencies. Java 9 SE are prefixed with java.“ ”, the JDK-specific The ubiquitous java.base is not shown; remember, ones with “jdk.”. all modules implicitly depend on it. Not all Java environments have to contain all platform modules. On the contrary, one goal of Jig- saw is the scalable platform, which means that it is
8 Java 9 and Beyond // eMag Issue 37 - Jan 2016 Figure 1
Example: Splitting Modules This tree is shown truncated here, but each With this understanding of how modules are han- “com” directory represents the package of the same dled by the compiler and virtual machine, lets start name and would contain more subdirectories and to think about how to divide our application into eventually the module’s code. modules. The statistics module depends on java.base Our architecture consists of the following parts: (but as we learned, we don’t have to list that) and • contacting the microservices and creating statis- uses Java’s built-in logging facilities. It’s public API tics allows to request aggregated and detailed statistics • updating the database and is contained in a single package. • presenting the JavaFX user interface 001 module com.infoq.monitor.stats { • wiring the pieces 002 requires java.logging; Let’s go ahead and create a module for each: 003 exports com.infoq.monitor.stats.get; • com.infoq.monitor.stats 004 } • com.infoq.monitor.db To reiterate the accessibility rules: non-public • com.infoq.monitor.ui types in com.infoq.monitor.stats.get and all • com.infoq.monitor types in other packages are completely hidden from The Jigsaw Quick-Start Guide and the JDK itself all other modules. Even the exported package is only propose to have a folder for each module below the visible to modules that read this one. project’s root source folder. In our case this would Our database module also logs and obviously have the following structure: (Figure 2) requires Java’s SQL features. Its API consists of a sim- ple writer.
Java 9 and Beyond // eMag Issue 37 - Jan 2016 9 Service Monitor It’s a little unwieldy that we have to explicitly re- └─ src quire javafx.base, but if we don’t, we couldn’t call ├─ com.infoq.monitor any code from javafx.beans.property, which we │ ├─ com ... must do to work with the model. So in a way com. │ └module-info.java infoq.monitor.ui is broken without javafx. ├─ com.infoq.monitor.db beans.property. For this case the Jigsaw prototype │ ├─ com ... provides the concept of implied readability, which we │ └module-info.java will cover shortly. ├─ com.infoq.monitor.stats Our modularization creates a very different │ ├─ com ... module graph: (Figure 3) │ └module-info.java Now let’s take a look at some of the commands └─ com.infoq.monitor.ui used to compile, package, and launch our freshly ├─ com ... modularized application. This is how we can compile └module-info.java and package modules that have no dependencies outside of the JDK itself: 001 javac -d classes/com.infoq.monitor. Figure 2 stats ${source files} 002 jar -c 003 --file=mods/com.infoq.monitor.stats. 001 module com.infoq.monitor.db { jar \ 002 requires java.logging; 004 ${compiled class files} 003 requires java.sql; Like before and exactly as with Java 8, we com- 004 exports com.infoq.monitor.db.write; pile the module’s source, write the resulting files into 005 } a subfolder of classes with the module’s name, and The user interface obviously requires the plat- create a JAR in mods. It’s a modular JAR because the form modules that contain the employed JavaFX class files include the compiled module descriptor features. Its API consists of the means to launch the module-info.class. JavaFX UI. This will return a model that uses JavaFX More interesting is how we process our only properties. The client can update the model, and the module with dependencies on other application UI will show the new state. modules: 001 javac \ 001 module com.infoq.monitor.ui { 002 -mp mods \ 002 requires javafx.base; 003 -d classes/com.infoq.monitor \ 003 requires javafx.controls; 004 ${list of source files} 004 requires javafx.graphics; jar -c 005 exports com.infoq.monitor.ui.launch; 005 --file=mods/com.infoq.monitor.jar \ 006 exports com.infoq.monitor.ui.show; 006 --main-class=com.infoq.monitor. 007 } Monitor \ Now that we covered the actual functionality, 007 ${compiled class files} we can turn our attention to the module that wires 008 java -mp mods -m com.infoq.monitor all of the parts together. This module requires each The compiler needs the application modules of our three modules, plus Java’s logging facilities. we created earlier, and we point it there by specify- Since the UI requires that module to work with Ja- ing the module path with -mp mods. Packaging and vaFX properties, we depend on it as well. Since the launching is as before but now mods contains not main module is not used by anybody else, it has no just a single module but four of them. API to export. The JVM will start by looking for module com. 001 module com.infoq.monitor { infoq.monitor because we specified that as our 002 requires com.infoq.monitor.stats; initial module. When it finds that, it will try to tran- 003 requires com.infoq.monitor.db; sitively resolve all of its dependencies inside the uni- 004 requires com.infoq.monitor.ui; verse of observable modules (in this case, our four 005 requires javafx.base; // to update application modules and all platform modules). the UI model If it can build a valid module graph, it will final- 006 requires java.logging; ly look up the main method specified with --main- 007 // no packages to export class=com.infoq.monitor.Monitor and launch 008 } our application. Otherwise it will fail with an excep-
10 Java 9 and Beyond // eMag Issue 37 - Jan 2016 tion informing us of the violated condition, e.g. a This is the most common case and covered by missing module or a cyclic dependency. readability as described above, where a module can only access another module’s API if it declares its de- Implied Readability pendency on it. So if a module depends on Guava, A module’s dependency on another module can take other modules are left in blissful ignorance of that two forms. fact and would not have access to Guava without de- First, there are dependencies that are con- claring their own explicit dependencies on it. sumed internally without the outside world having But there is another use case where the depen- any knowledge of them. Take for example Guava, dency is not entirely encapsulated, but lives on the where the code depending on a module does not boundary between modules. In that scenario one care at all whether it internally uses immutable lists module depends on another, and exposes types or not. from the depended-upon module in its own public
Java 9 and Beyond // eMag Issue 37 - Jan 2016 11 API. In the example of Guava a module’s exposed mands required to compile and launch the applica- methods might expect or return immutable lists. tion. So code that wants to call the dependent mod- ule might have to use types from the depended-up- Beyond Module Boundaries on module. But it can’t do that if it does not also To quote once again the design overview: read the second module. Hence for the dependent In general, if one module exports a package con- module to be usable, client modules would all have taining a type whose signature refers to a package in a to explicitly depend on that second module as well. second module then the declaration of the first module Identifying and manually resolving such hidden de- should include a requires public dependence upon pendencies would be a tedious and error-prone task. the second. This will ensure that other modules that de- This is where implied readability comes in: pend upon the first module will automatically be able [We] extend module declarations so that one to read the second module and, hence, access all the module can grant readability to additional modules, types in that module’s exported packages. upon which it depends, to any module that depends But how far should we take this? Look, for ex- upon it. Such implied readability is expressed by in- ample, at the java.sql module. It exposes the in- cluding the public modifier in arequires clause. terface Driver, which contains a public method get- In the example of a module’s public API using ParentLogger() returning a Logger. Because of immutable lists, the module would grant its readabil- that the module publicly requires java.logging. So ity to Guava to all other modules depending on it by any module using Java’s SQL features can also implic- requiring it publicly. In this way its API is immediately itly access the logging API. usable. With that in mind, let’s have a second look at our database module: Example: Implying Readability Let’s turn to our UI module, which exposes a model 001 module com.infoq.monitor.db { that uses types from the module javafx.base in its 002 requires java.logging; API. We can now change the module descriptor so 003 requires java.sql; that it publicly requires that module: 004 exports com.infoq.monitor.db.write; 005 }
001 module com.infoq.monitor.ui { Technically the declaration of requiring java. 002 // expose javafx.base to modules logging is not needed and might seem redundant. depending on this one So should we drop it? 003 requires public javafx.base; To answer this question we have to look at how 004 requires javafx.controls; exactly com.infoq.monitor.db uses java.logging. Our 005 requires javafx.graphics; module might only need to read it so we are able 006 exports com.infoq.monitor.ui.launch; to call Driver.getParentLogger(), do something with 007 exports com.infoq.monitor.ui.show; the logger (e.g. log a message) and be done with it. 008 } In this case our code’s interaction with java.logging Our main module can now implicitly read ja- happens in the immediate vicinity of its interaction vafx.base and no longer has to explicitly depend with Driver from java.sql. Above we called this the on it, since its dependency com.infoq.monitor.ui boundary between com.infoq.monitor.db and java. exports it: sql. Alternatively we might be using logging 001 module com.infoq.monitor { throughout com.infoq.monitor.db. Then, types from 002 requires com.infoq.monitor.stats; java.logging appear in many places independent of 003 requires com.infoq.monitor.db; Driver and can no longer be considered to be limited 004 requires com.infoq.monitor.ui; to the boundary of com.infoq.monitor.db and java. 005 // we don’t need javafx.base anymore sql. to update the UI model With Jigsaw being cutting edge, the communi- 006 requires java.logging; ty still has time to discuss such topics and agree on 007 // no packages to export recommended practices. My take is that if a mod- 008 } ule is used on more than just the boundary to an- While this changes why com.infoq.moni- other module it should be explicitly required. This tor reads com.infoq.monitor.stats it does not approach clarifies the system’s structure and also fu- change the fact that it does read it. Consequently ture-proofs the module declaration for refactorings. this changes neither our module graph nor the com- So as long as our database module uses logging in- dependently of the SQL module I would keep it.
12 Java 9 and Beyond // eMag Issue 37 - Jan 2016 Aggregator Modules The service consumer module has to read the Implied readability opens up the path to so-called service module and include a uses X; clause in its aggregator modules, which contain no code on their descriptor. At runtime it can then call ServiceLoad- own but aggregate a number of other APIs for easier er.load(Class
Java 9 and Beyond // eMag Issue 37 - Jan 2016 13 Figure 4 have to make sure that it still has access to that func- code would be similar to before, i.e. contacting the tionality. Its new module-info.java: services and creating statistics. Limiting our module graph to com.infoq. 001 module com.infoq.monitor.stats { monitor.stats and below (because everything 002 requires java.logging; else is unchanged) our new version looks as follows: 003 requires com.infoq.monitor.watch; (Figure 4) 004 // we have to declare which service Note how the arrows all point towards the new we are depending on module; a typical example for the dependency inver- 005 uses com.infoq.monitor.watch.Watcher; sion principle. 006 exports com.infoq.monitor.stats.get; Compilation, packaging and launching is like 007 } before (except that now we have more modules). Somewhere in its code we can now do this: Migration 001 List
14 Java 9 and Beyond // eMag Issue 37 - Jan 2016 The Jigsaw team has tackled this problem As has been stated above, the whole applica- head-on and provides a gradual migration path to tion, including all of its dependencies, can simply be modularization. For this they introduced two kinds put on the classpath. This is a crucial escape hatch in of modules that we have not yet discussed. case some problem prevents a migration. We can now see why that approach works: All Kinds Of Modules II artifacts on the classpath get rolled into the unnamed We already know about platform modules and ap- module, where all types can freely access each other. plication modules. They are fully aware of the mod- To use Java’s public API they have to access the plat- ule system, and their defining characteristic are form modules, which they can do since the unnamed their module descriptors. Because these give them a module reads all other observable modules. name, they are called named modules. A bottom-up migration starts with dependen- There are two other types of modules for arti- cy-free artifacts, which can immediately be modu- facts that are not aware of the module system. larized. Building on that, other projects can move to Before Jigsaw, all types loaded from the class- Jigsaw. path ended up in the same space where they could Clients can put modular JARs on the module freely access each other. This unstructured space path and reference them by name if their projects continues to exist: Each class loader has a unique un- were migrated. Even if not and their code still comes named module, to which it assigns all types it loaded from the classpath, it can access the migrated arti- from the classpath. facts because the unnamed module can read all Unnamed modules read all other modules and other modules. Or clients can decide to put modular export all packages. Because a modularized appli- JARs on the classpath. cation should not depend on the random content This approach works best for library projects of the classpath, named modules can not require with few, well-maintained dependencies. But as the unnamed modules and are hence not able to read number of dependencies grows, projects might not them. be willing to wait for all of them to be modularized. But an artifact without a module descriptor can This is especially true of large Java applications, also be placed on the module path. In this case, the which might prefer to opt for another approach. module system will create a fully fledged module for A top-down migration starts with creating mod- it, called an automatic module. ule descriptors for all artifacts of a project. They need An automatic module’s name is derived from names and must specify which other internal arti- the artifact’s file name, it can read all other modules facts they depend on and which packages they want and exports all its packages. Because the module to export. system can easily check at launch time whether any This process will naturally be confronted with specific automatic module is present on the mod- external dependencies. If Jigsaw-aware versions ule path, named modules can depend on them and exist for them and can be used, that’s great. If not, hence read them. automatic modules are the way to go: The project’s So in the common case of a single application artifacts require modules with the name that Jigsaw class loader, the application’s universe of observable derives from the artifact file names, and the artifacts modules can consist of: are placed on the module path. • named platform modules as they are contained It is sufficient to do this for direct dependencies in the run time so that the new application modules can access them. • one named application module for each artifact The dependencies likely bring transitive dependen- on the module path that has a module descriptor cies with them. But because the direct dependencies • one automatic module for each artifact on the were turned into automatic modules, which read all module path that does not have a module de- other modules including the unnamed one, their de- scriptor pendencies can be put on the classpath. • a unique unnamed module composed of all ar- For large projects this manual approach be- tifacts on the classpath, regardless of whether comes unusable and build tools must help. Gradle they have module descriptors or not (with several and Maven have already started to work on Jig- application class loaders there would be several saw-related features. unnamed modules) More details about migration can be found in the JavaOne talk Advanced Modular Development by Migration Strategies Alex Buckley and Alan Bateman, both members of These kinds of modules open up the path to a grad- the Jigsaw team at Oracle. ual migration to the module system. (Note that mod- ule relationships are not the only hurdle, though.)
Java 9 and Beyond // eMag Issue 37 - Jan 2016 15 Example: Migrating Dependencies Observe Let’s say our database module uses Guava and we All things Jigsaw should be discoverable from the have the artifact guava-19.0.jar in a directory project’s OpenJDK site. The main source for up-to- libs. We can not simply put it on the classpath be- date information on Project Jigsaw is the Jigsaw-Dev cause our application is already properly modular- mailing list. I will also continue to discuss this topic ized and we discussed above that named modules on my blog. can not read the unnamed module. So we need an automatic module. Prepare From a file namedguava-19.0.jar Java de- As has been hinted at, a migration to Jigsaw can be rives the module name guava. With this knowledge a little rough. To prepare our projects we should ex- we can update the database module’s descriptor: amine whether they rely on anything that will be un- available or removed in Java 9. 001 module com.infoq.monitor.db { 002 requires java.logging; Dependencies on internal APIs, a crucial obsta- 003 requires java.sql; cle, can be analyzed with jdeps, the Java Dependency 004 requires guava; Analysis Tool (introduction with some internal pack- 005 exports com.infoq.monitor.db.write; ages, official documentation forWindows and Unix), 006 } which is already available in JDK 8. There are also 007 To compile it, we need to add libs to at least three jdeps-plugins for Maven: by Apache, the compiler’s module path: Philippe Marschall and myself. The latter enables a 008 javac \ project to gradually remove its dependencies on in- 009 -mp libs \ ternal APIs while breaking the build on relapses. 010 -d classes/com.infoq.monitor.db \ If you are concerned about some specific API 011 ${list of source files} that will be unavailable in Java 9, you could check Packaging requires no changes. If we launch the mailing list of the corresponding OpenJDK proj- our application as we did before, the JVM will com- ect as these will be responsible for developing public plain that it couldn’t find the moduleguava . To fix versions of them. that we need to add libs to the module path: We should also identify the critical dependen- cies our projects rely on and check with those teams 001 java -mp mods:libs -m com.infoq. how they are preparing for Java 9. monitor (Note that on Windows the separator between paths Adopt is “;” not “:”.) Jigsaw early access builds are available and can be used to tentatively compile and run existing proj- Next Steps ects. Unfortunately build system support is still in- We have explored the Jigsaw prototype and seen the complete, but it’s being worked on. core features it has to offer. What else can we do be- Information and problems gathered this way sides waiting for Java 9? can be returned to the project by posting on the Jigsaw-Dev mailing list. To quote the (almost) final Go deeper words from one of the many involved JEPs: It is always possible to learn more and there are a It is impossible to determine the full impact of couple of advanced topics we did not discuss: these changes in the abstract. We must therefore rely The excellent “State of the Module System” upon extensive internal and—especially—external shows how modules can be used with reflection, testing. […] If some of these changes prove to be in- which includes adding read edges at run time and surmountable hurdles for developers, deployers, or the new concept of layers, as well as the interaction end users then we will investigate ways to mitigate with class loaders. their impact. The new tool jlink can be used to create run There is also the global Java User Group Adop- time images that only contain a specific set of plat- tOpenJDK, which is a great contact for early adopt- form modules; it is introduced in the Jigsaw Quick- ers. Start Guide, which is highly recommended. These topics are also covered by talks the Jig- saw team gave at JavaOne 2015 and Devoxx BE 2015. I summarized the former here.
16 Java 9 and Beyond // eMag Issue 37 - Jan 2016 Read online on InfoQ
Java 9’s New HTTP/2 and REPL
System.out.println("Hello, World"); for(int i = 0; i < count; i++){...} if(hot) {wearSomethingCool();} while(st.read() != null){...}
Ben Evans is the CEO of jClarity, a Java/JVM performance-analysis startup. In his spare time, he is one of the leaders of the London Java Community and holds a seat on the Java Community Process Executive Committee. His previous projects include performance testing the Google IPO, financial trading systems, writing award-winning websites for some of the biggest films of the 1990s, and others.
Despite all the hype, Java 9 will not just be about modularity. It is targeting many additional pieces of functionality that are being delivered as Java Enhancement Proposals (JEPs) implemented in OpenJDK (the reference implementation for Java SE).
Some of the new JEPs may well from 1999 and has significant blocking” and can lead to a num- have a great impact on devel- problems. ber of rendering problems. opers’ working lives during the In HTTP/2, responses can be lifetime of Java 9. These include Head-of-line blocking chunked and even interleaved, HTTP/2 support and the JShell HTTP/1.1 dictates that responses to allow responses and requests REPL (read-eval-print loop) that are received in the same order to be truly multiplexed. brings shell-based interactive as the requests were sent. This Java development and explora- means that, for example, when Restricted connections to a tion of APIs. viewing a large HTML page that single site contains several small images, The HTTP/1.1 standard states, “A HTTP/2 the images will have to “queue single-user client SHOULD NOT The HTTP/2 standard is a new up” behind the HTML and can’t maintain more than 2 connec- version of the HTTP protocol. The be sent until the browser finish- tions with any server or proxy.” existing version, HTTP/1.1, dates es completely downloading the Along with the head-of-line HTML. This is called “head-of-line
Java 9 and Beyond // eMag Issue 37 - Jan 2016 17 problems, this has seriously lim- 001 HttpResponse response = HttpRequest ited page performance. 002 .create(new URI(“http://www.infoq.com“)) HTTP/2 tackles this by as- 003 .body(noBody()) suming that connections are 004 .GET().send(); persistent and will only close af- 005 int responseCode = response.responseCode(); ter a user navigates away or in 006 String responseBody = response.body(asString()); the event of a technical failure. 007 With the use of multiplexing, this 008 System.out.println(responseBody); should help to reduce page bot- tlenecks. Code 1
Overhead of control headers Akamai. HTTP/2 is therefore a a plan to move to a HTTPS-Only Existing versions of HTTP use version optimized for the needs Standard. simple, text-based headers to of large, high-volume websites HTTP support in the core control communication. This and that places performance and JDK has not kept pace with the has the advantage of being very bandwidth consumption above real Web. In fact, even JDK 8 still simple to understand and allows simplicity of implementation only ships a client that supports debugging simply by connect- and easy debugging. HTTP/1.0 — and so almost all de- ing to a port and typing some The group chair summariz- velopers have switched to using text. However, the use of a text- es some of the key properties of a client library, such as Apache based protocol disproportion- HTTP/2 as follows: HttpComponents. ately inflates small responses. • the same HTTP APIs, All of this means that sup- Additionally, a large number of • cheaper requests, port for HTTP/2 is a core piece HTTP responses have little or • network friendly and server of Java functionality for the next no payload (e.g. HEAD requests friendly, decade. It also allows us to revisit that simply seek to confirm that • cache pushing, our old assumptions, rewrite the a resource has not changed). • being able to change your APIs, and provide a second bite Paying the full cost of text-based mind, and of the apple. HTTP/2 will be a headers (~700 bytes that can’t be • more encryption. major API for every developer for compressed in HTTP/1.1 despite years to come. being easy to squeeze) for a re- What does this mean for Java? The new API makes a clean sponse consisting of essentially Java has supported HTTP since break with the past by aban- only a last-modified datetime is version 1.0, but much of the code doning any attempt to maintain an incredibly wasteful part of the comes from a very different era. protocol independence. Instead, existing HTTP standard. For example, Java’s support is de- the API focuses solely on HTTP, The alternative is to use bi- signed around a relatively proto- but with the additional under- nary encoding for headers. This col-agnostic framework (the URL standing that HTTP/2 does not approach can greatly speed up class) as it was not clear in the fundamentally change seman- smaller requests and uses far less late 1990s that the Web would tics. Therefore, the API can be bandwidth. It is the approach be the dominant force that it has independent of HTTP version, that HTTP/2 has chosen to follow, become. whilst still providing support for in the spirit of the principle that The support was based on the new framing and connection standards should prefer text- best ideas at the time but the handling parts of the protocol. based protocols, but use binary world has experienced many In the new API, a simple for efficiency where compelling changes, not the least of which is HTTP request can be created and reasons to do so exist. the fact that when Java’s original handled like this (Code 1) HTTP support shipped, HTTPS The fluent/builder style for What to expect from HTTP/2 didn’t exist. So Java’s APIs treat the API should feel much more The standard comes from HTTPS as an afterthought with modern and comfortable to the the IETF HTTP Working Group, some irreducible complexity as developer than the existing leg- which comprised representa- a result. acy API. tives and engineers from Mozil- In the modern world, HTTPS The current codebase con- la, Google, Microsoft, Apple, and is becoming ubiquitous, with tains a version with the new others, and chaired by Mark Not- HTTP moving towards becoming API but currently supports only tingham, a senior engineer from a legacy technology. Even the US HTTP/1.1. This allows developers the content-delivery network government has now adopted to experiment with and validate
18 Java 9 and Beyond // eMag Issue 37 - Jan 2016 the new API while the HTTP/2 001 HttpRequest req = HttpRequest support is being completed. 002 .create(new URI(“http://www.infoq.com”)) The code is available from 003 .body(noBody()) the OpenJDK sandbox reposito- 004 .GET(); ry and should be landing on the 005 CompletableFuture
Java 9 and Beyond // eMag Issue 37 - Jan 2016 19 001 -> /help 002 Type a Java language expression, statement, or declaration. 003 Or type one of the following commands: 004 005 /l or /list [all] -- list the source you have typed 006 /seteditor
Code 3
001 -> System.out.print 001 -> 3 * (4 + 5) 002 print( printf( 002 | Expression value is: 27 println( 003 | assigned to temporary variable $1 of type int Traditional expression eval- 004 uation is also easy, although Ja- 005 -> System.out.println($1); 006 27 va’s statically typed nature makes this a little more exacting than Code 4 in dynamically typed languag- es. JShell automatically creates temporary variables to hold the 001 -> String s = “Dydh da” values of expressions and ensure 002 | Added variable s of type String with initial that they remain in scope for lat- value “Dydh da” er use (Code 4). 003 We can also view the source 004 -> /vars code of everything entered in 005 | int $1 = 27 006 | String s = “Dydh da” the session so far, with the /list Code 5 command: Code 5 001 -> /list 002 003 9 : 3 * (4 + 5) 004 10 : System.out. println($1); The command /vars shows all of the variables (both
20 Java 9 and Beyond // eMag Issue 37 - Jan 2016 001 -> Pet[] pets = new Pet[1] 002 | Added variable pets of type Pet[] with initial value [LPet;@2be94b0f 003 004 -> Cat[] cats = new Cat[1] 005 | Added variable cats of type Cat[] with initial value [LCat;@3ac42916 006 007 -> pets = cats 008 | Variable pets has been assigned the value [LCat;@3ac42916 009 010 -> pets[0] = new Pet() 011 | java.lang.ArrayStoreException thrown: REPL.$REPL13$Pet 012 | at (#20:1) Code 6 explicitly defined and temporar- These IDE builds do not, • JEP 165: Compiler Control; ies) and the values they currently for now, support either HTTP/2 • JEP 227: Unicode 7.0; hold (Code 5). or JShell, as these features have • JEP 245: Validate JVM Com- The REPL allows the simple yet to land on the OpenJDK mand-Line Flag Arguments; creation of classes and other us- mainline, but developers should • JEP 248: Make G1 the Default er-defined types as well as small expect them to appear as part Garbage Collector; bits of code. For example, classes of the standard JDK beta builds • TLS Updates (JEPs 219, 244, can be created in just one line, soon, with IDE plugins following and 249). like this (note that the starting closely behind. The APIs are still A complete list of all the and closing braces are required): under development, and the JEPs currently under consid- 001 -> class Pet {} project leads are actively seeking eration (and the Java versions 002 | Added class Pet end-user participation. they are intended for) can be 003 The JDK 9 Outreach pro- found here. 004 -> class Cat extends gramme encourages developers Pet {} to test their code and applica- 005 | Added class Cat tions on JDK 9 before it arrives. The concise, free-flowing HTTP/2 and JShell aren’t the nature of code in JShell means only new features being worked that we can use the REPL to on - other new JDK 9 functional- demonstrate Java language fea- ity under development includes: tures very simply. For example, • JEP 102: Process API Updates; let’s look at the well-known type problem that Java arrays have due to array covariance (Code 6). This makes JShell a great teaching or exploration tool, and is closest in experience to the Scala REPL. With the /class- path switch, additional jars can be loaded to allow interactive Managed garbage collection. exploration of APIs directly from Because JVM environments the REPL. hate hoarders. Getting involved appdynamics.com/java Major IDEs are beginning to pro- vide builds that support early JDK 9 — including NetBeans and Eclipse. IntelliJ 14.1 reportedly supports JDK 9, but it is unclear how far the support for the new modular JDK extends.
Java 9 and Beyond // eMag Issue 37 - Jan 2016 21 Read online on InfoQ Case for Defaulting to G1 Garbage Collector in Java 9
Monica Beckwith is a Java-performance consultant. Her past experiences include working with Oracle/Sun and AMD to optimize the JVM for server-class systems. Monica was voted a Rock Star speaker @JavaOne 2013 and was the performance lead for Garbage-First Garbage Collector (G1 GC). You can follow Monica on Twitter: @mon_beck
JEP 248 proposes to make Garbage-First (G1) the default garbage collector (GC) in Java, targeted for OpenJDK 9.
As of OpenJDK 8, the throughput GC (also known So, why G1 GC? as parallel GC) and the more recent parallel old GC You may be familiar with the software-optimiza- (“parallel old” means that both -XX:+UseParallel- tion tradeoff: you can optimize software for latency, GC and -XX:+UseParallelOldGC are enabled) have throughput, or footprint. The same is true for GC op- been the default GCs. Anyone wanting to use a dif- timizations, and is reflected in the various popular ferent GC algorithm would have to explicitly enable GCs. You could also focus on two of those three, but it on the command line. For example, if you wanted trying to optimize for all three is enormously difficult. to employ G1 GC, you would need to select it on the OpenJDK HotSpot GC algorithms are geared towards command line using -XX:+UseG1GC. optimizing one of the three — for example, Serial GC The proposal to set G1 GC as the default GC for is optimized to have minimal footprint, parallel GC is OpenJDK 9 has been a major source of community optimized for throughput, and (mostly) concurrent concern, which gave rise to a few amazing discus- mark and sweep (CMS) GC is optimized to minimize sions and eventually led to an update of the original GC-induced latencies for improved response times. proposal in order to incorporate the ability to revert So, why do we need G1? to using parallel GC as the default.
22 Java 9 and Beyond // eMag Issue 37 - Jan 2016 G1 GC comes in as a long-term replacement for collections, the collection set is comprised of CMS. CMS in its current state has a pathological issue all the young regions and a few candidate old that will lead it to concurrent-mode failures, even- regions. The concurrent marking cycle helps tually leading to a full-heap compacting collection. identify these candidate old regions, which You can tune CMS to postpone the currently sin- are effectively added to the mixed collection gle-threaded full-heap compacting collection, but set. The tuning switches available for the old ultimately it can’t be avoided. In the future, the fall- generation in G1 GC are more direct, many back collection could be improved to employ multi- more in number, and provide more control ple GC threads for faster execution but, again, a full than the limited-size tuning offered in paral- compacting collection can’t be avoided. lel GC or the size and “initiation of marking” Another important point is that maintenance of threshold settings offered in CMS. The future CMS has proven challenging even for the well-sea- that I envision here is an adaptive G1 GC that soned GC engineer; one of the goals for the active can predictively optimize the collection set HotSpot GC maintainers has been to keep CMS sta- and the marking threshold based on the stats ble. gathered during the marking and collection Also, CMS GC, parallel GC, and G1 GC all are im- cycles. plemented with different GC frameworks. The cost of • An evacuation failure in G1 GC is also, so to maintaining three different GCs, each using its own speak, “tunable”. Unlike CMS, G1 does not ac- distinct GC framework, is high. G1 GC’s regionalized cumulate fragmentation over time — doing heap framework, where the unit of collection is a re- so leads to expensive collection and concur- gion and various such regions can make up the gen- rent-mode failures. In G1, fragmentation is erations within the contiguous Java heap, is where minimal and may be tuned. Very large objects the future is heading — IBM has their Balanced GC, that that don’t follow the normal allocation Azul has C4, and there is the OpenJDK proposal path can introduce fragmentation. These very called Shenandoah. It wouldn’t be surprising to see a large objects (also known as “humongous similar regionalized heap-based implementation of objects”) are allocated directly out of the old a throughput GC, which could offer the throughput generation into regions known as “humon- and adaptive-sizing benefits of parallel GC. The num- gous regions”. (To learn more about humon- ber of GC frameworks used in HotSpot could drop, gous objects and humongous allocations, thereby reducing the cost of maintenance, which please read the “Tips” article.) But when these in turn enables more rapid development of new GC humongous objects die, they are collected features and capabilities. and the fragmentation dies with them. In the G1 GC became fully supported in OpenJDK 7 current state, it can at times still be a bit of a update 4, and since then has been getting better and heap-region and heap-occupancy tuning more robust with massive help from the OpenJDK nightmare, especially when you are trying to community. To learn more about G1, I highly recom- work with restricted resources — but, again, mend my “G1: One Garbage Collector to Rule Them making the G1 algorithm more adaptive All” and “Tips for Tuning the Garbage-First Garbage would prevent the end user from encounter- Collector” InfoQ articles, but let me summarize a few ing failures. key takeaways: • G1 GC is scalable! • G1 GC provides a regionalized heap frame- • The G1 GC algorithm is designed with scal- work. ability in mind. Compare this with parallel GC • This helps make the generations immensely — you have something that scales with your tunable since the unit of collection (a region) heap size and load without much of a compro- is now smaller than the generation itself. And mise in your application’s throughput. increasing/decreasing the generation size is as simple as adding/removing a region from Why now? the list of free regions. Note that even though Oracle is targeting OpenJDK 9 general availability the entire heap is contiguous, the regions in for September 2016. The hope is that the OpenJDK a particular generation don’t have to be con- community members that choose to work with ear- tiguous. ly-access builds and release candidates will test the • G1 GC is designed on the principle of collect- feasibility of G1 GC as the default GC and provide ing the most garbage first. timely feedback and even code changes. • G1 has distinct collection sets for young and The only end users that will be impacted are mixed collections. (For more information, those who do not set an explicit GC today. These us- please refer to the “Tips” article.) For mixed ers will use G1 GC instead of the parallel GC they use
Java 9 and Beyond // eMag Issue 37 - Jan 2016 23 now, and if they want to continue to use parallel GC, Why did the JEP become such a hot they merely have to set -XX:+UseParallelGC (the topic? current default that enables parallel GC threads for Many OpenJDK community members have re- young collection) on their JVM command line. marked on their experience with G1 in the field and (With the introduction of -XX:+UseParal- have voiced concern over whether G1 is ready for lelOldGC in JDK 5 update 6, you will find that if you prime time. Ever since G1 was fully supported, it has set -XX:+UseParallelGC on the JVM command been touted as a CMS replacement. But the commu- line, you will also enable -XX:+UseParallelOldGC, nity is concerned that with this JEP it now feels like employing parallel GC threads for full collections. G1 is in fact replacing parallel GC, not CMS. It is wide- Hence, if you are working with builds of JDK 6 or lat- ly believed that while there may be data comparing er, setting either of these command-line options will CMS to G1 (due to businesses migrating from CMS to offer the same GC behavior you had previously.) G1), there is insufficient data comparing parallel to G1 GC. Also, field data seems to indicate that most When would you choose G1 GC over businesses use the default GC, and so will definitely parallel GC? observe a change in behavior when G1 becomes the Parallel GC doesn’t do incremental collection so it default GC. sacrifices latency for throughput. For larger heaps Some users have claimed that G1 has expressed as the load increases, the GC pause times will often some important (albeit hard to reproduce) issues of increase as well, possibly compromising your laten- index corruption, and such issues need to be studied cy-related system-level agreements (SLAs). and rectified before G1 is made the default. G1 may help deliver your response-time SLAs Others ask whether we still need a single de- with a smaller heap footprint, since G1’s mixed col- fault GC that is not based on “ergonomics”. (For ex- lection pauses should be considerably shorter than ample, since Java 5, the launcher can identify your the full collections in parallel GC. system as a “server-class” system and so use the serv- er VM instead of the client VM. See this link) When would you choose G1 GC over CMS GC? Summary In its current state, a tuned G1 can and will meet the After much back and forth, Charlie Hunt, perfor- latency SLAs that a CMS GC can’t due to fragmenta- mance architect at Oracle, finally proposed the fol- tion and concurrent-mode failures. G1’s worst-case lowing steps in June 2015 (see this link): pause times with mixed collections are expected to • Make G1 the default collector in JDK 9, continue be better than the worst-case full-compaction paus- to evaluate G1, and enhance G1 in JDK 9. es that CMS will encounter. As mentioned earlier, • Mitigate risk by reverting back to parallel GC be- one can postpone but not prevent the fragmenta- fore JDK 9 goes becomes generally available in tion of a CMS heap. Some developers working with September 2016 if warranted by continuing to CMS have come up with workarounds to combat monitor observations and experiences with G1 in the fragmentation issue by allocating objects in sim- both JDK 9 pre-releases and the latest JDK 8 up- ilarly sized chunks. But those are workarounds that date releases. are built around CMS; the inherent nature of CMS is • Address enhancing ergonomics for selecting a that it is prone to fragmentation and will need a fully default GC as a separate JEP if future observations compacting collection. Some companies like Google suggest it’s needed. build their own private JDK from OpenJDK sources Staffan Friberg of the Java SE Performance team with specific source-code changes for their needs. at Oracle urged the community to help gather data One Google engineer has mentioned that the com- points for the following key metrics (see this link): pany has added a form of incremental compaction • Ensure that the G1 infrastructural complexity to its private CMS GC’s remark phase in an effort to doesn’t introduce much delay at the JVM initial- reduce fragmentation and have also made their CMS ization. GC more stable (see this link). • G1 is going head to head with the throughput Incremental compaction comes with its own GC. G1 also has pre and post write barriers. The costs. Google probably added incremental compac- throughput metric is the key to understanding tion after weighing the benefits to its specific use how much of an overload the barriers impose on case. the application. • G1 has remembered sets and collection sets that increase the footprint. Data gathered from the field should provide enough information to un- derstand the impact of this increased footprint.
24 Java 9 and Beyond // eMag Issue 37 - Jan 2016 Java Application
• Businesses that go with the default GC often also go with the out-of-box performance Performance provided by that GC so it is important to understand the out-of-box performance of G1. Here, the GC ergonomics and how well it Monitoring adapts play an important part. Friberg also identified business applica- tions that currently employ the default GC algo- rithm — the ones that will feel the impact of the change in the default GC. Similarly, the change- End-to-end transaction tracing over will also affect scripts that don’t specify a GC or interfaces that specify just the Java heap and generation sizes on the command line. Code level visiblity Acknowledgement I would like to extend my gratitude to Charlie Dynamic baselining and alerting Hunt for his review of this article. Data rentention
Scalability
Supports all common Java frameworks including: Spring Play Grails Resin Apache CXF Jetty Tomcat Glasssh JBoss WebLogic WebSphere Struts Apache TomEE Akka
For full list, go to: AppDynamics.com/Java Read online on InfoQ
A Post-Apocalyptic sun.misc.Unsafe World
Christoph Engelbert is technical evangelist at Hazelcast. He is a passionate Java developer with a deep commitment for open-source software. He mostly is interested in performance optimizations and understanding the internals of the JVM and the garbage collector. He loves to bring software to its limits by looking into profilers and finding problems inside the codebase.
Java as a language and the JVM as a platform just celebrated their 20th birthday. With its noble origins, on set-top boxes, mobiles, and Java-cards, as well as all kinds of server systems Java is emerging as the lingua franca of the Internet of Things. Java is everywhere!
Less obvious is that Java is also heavily immersed Java world if sun.misc.Unsafe (along with some in all sorts of low-latency applications such as smaller private APIs) were to just disappear without game servers and high-frequency trading applica- a sufficient API replacement. The final proposal (JEP tions. This was only possible thanks to a propitious 260) from Oracle solves the problem by offering a deficiency in the Java visibility rules for classes and nice migration path. But the question remains: how packages, offering access to a controversial little class will this Java world look once the Unsafe dust has called sun.misc.Unsafe. This class was and still is a settled? divider. Some love it, others hate it with a passion — the essential part is it helped the JVM and the Java Organization ecosystem to evolve to where it is today. The Unsafe A glance at the sun.misc.Unsafe feature set leads class basically compromised on some of Java’s hall- to the unsettling realization that it was used as a mark strict safety standards in favor of speed. dumping ground for all kinds of features. Passionate discussions like those at JCrete, our An attempt to categorize these features pro- “What to Do About sun.misc.Unsafe and Pals?” mis- duces the following five sets of use cases: sion paper, and blog posts such as this one on Drip- • atomic access to variables and array content, cus- Stat created awareness of what might happen in the tom memory fences,
26 Java 9 and Beyond // eMag Issue 37 - Jan 2016 • serialization support, instances of a class, in our case Records, and can up- • custom memory management and efficient date volatile fields. memory layout, 001 public class Record { • interoperability with native code or other JVMs, 002 private static final and AtomicLongFieldUpdater
Java 9 and Beyond // eMag Issue 37 - Jan 2016 27 Use the MethodHandles API, a direct entry being instantiated in an unsafe manner. Another in- point into the JVM internal linkage behavior, to cre- teresting proposal is frozen arrays, which might also ate VarHandle. We use a MethodHandles-Lookup, help serialization frameworks in the future. passing in the containing class, field name, and field It might look like the following snippet, which is type, or we “unreflect” an instance of java.lang. totally my concoction as there is no proposal yet but reflect.Field. is based on the currently available sun.reflect.Re- Why is this better than the AtomicXFieldUp- flectionFactory API. dater API? VarHandle is a general abstraction over 001 public String deserializeString() all types of variables, arrays, and even byte buffers throws Exception { — with just have one abstraction over all of these dif- 002 char[] chars = ferent types. That sounds super nice in theory, but it readCharsFromStream().freeze(); is still somewhat wanting in the current prototypes. 003 ReflectionFactory reflectionFactory = The explicit cast of the returned value is necessary 004 ReflectionFactory. since the compiler is not yet able to automatically fig- getReflectionFactory(); ure it out. In addition, there are some oddities as a re- 005 Constructor
28 Java 9 and Beyond // eMag Issue 37 - Jan 2016 to roughly 2 GB of data since a DirectByteBuffer Interoperability can only be created with an int (ByteBuffer::al- Interoperability is not limited to efficient transfer of locateDirect(int)). Additionally, all indexes on data between different JVMs (perhaps via shared the ByteBuffer API are only 32-bit. Was it Bill Gates memory, which could also be a type of a memory who once asked, “Who will ever need more than 32 region, and which would avoid slow socket commu- bits?” nication). It also covers communication and informa- Retrofitting the API to use long-type will break tion exchange with native code. compatibility, so VarHandle rides to the rescue. Project Panama hoisted the sails to supersede JNI in a more Java-like and efficient way. People fol- 001 public long memory() { 002 ByteBuffer byteBuffer = ByteBuffer. lowing JRuby might know Charles Nutter for his ef- allocateDirect(8); forts on the Java Native Runtime (JNR), and especially 003 VarHandle bufferView = the jnr-ffi implementation. The FFI stands for “foreign 004 MethodHandles. function interface” and is a typical term for people byteBufferViewVarHandle(long[]. working with other languages like Ruby, Python, etc. class, true); The FFI basically builds an abstraction layer to 005 bufferView.set(byteBuffer, 0, Long. call C (and, depending on the implementation, C++) MAX_VALUE); directly from the current language without the need 006 return bufferView.get(byteBuffer, to create glue code as in Java. 0); As an example, to get a pid via Java requires all 007 } of the following C code: Is the VarHandle API in this case really bet- ter? At the moment we are constrained by the same 001 extern c { limitations; we can only create a ByteBuffer with 002 JNIEXPORT int JNICALL about 2 GB, and the internal VarHandle implemen- 003 Java_ProcessIdentifier_ tation for the views over ByteBuffer is also based getProcessId(JNIEnv *, jobject); on ints. Although this latter issue might be “fixable”, 004 } at present there is no real solution to this problem. 005 The nice thing here though is that the API is again 006 JNIEXPORT int JNICALL 007 Java_ProcessIdentifier_ the same VarHandle API as in the first example. getProcessId(JNIEnv *env, jobject Some more options are under discussion. Paul thisObj) { Sandoz, the Oracle engineer who is project owner 008 return getpid(); of JEP 193: Variable Handles, talked about a concept 009 } of a memory region on Twitter and, although still 010 nebulous, the approach looks promising. A clean 011 public class ProcessIdentifier { API might look like something like the following 012 static { snippet. 013 System. loadLibrary(“processidentifier”); 001 public long memory() { 014 } 002 MemoryRegion region = MemoryRegion 015 003 .allocateNative(“myname”, 016 public native void talk(); MemoryRegion.UNALIGNED, Long.MAX_ 017 } VALUE); 004 Using JNR, we could simplify this to a pure Java 005 VarHandle regionView = interface that would be bound to the native call by 006 MethodHandles. the JNR implementation. memoryRegionViewVarHandle(long[]. 001 interface LibC { class, true); 002 void getpid(); regionView.set(region, 0, Long.MAX_ 007 003 } VALUE); 004 return regionView.get(region, 0); 008 005 public int call() { } 009 006 LibC c = LibraryLoader.create(LibC. This is only an idea, and hopefully Project Pan- class).load(“c”); ama, the native-code OpenJDK project, will present 007 return c.getpid(); a proposal for those abstractions in the near future. 008 } Project Panama is actually the right place for this, JNR internally spins the binding codes and in- since those memory regions will also need to work jects those into the JVM. Since Charles Nutter is one with native libraries that expect a memory address of the main developers of JNR and also works on (pointer) passed into its calls.
Java 9 and Beyond // eMag Issue 37 - Jan 2016 29 Project Panama, we might expect something quite What is really nice about value types is that the similar to come up. JVM can treat those types as primitive values that, for From looking at the OpenJDK mailing list, it example, offer the option to flatten the layout into feels like we will soon see another incarnation of an array: MethodHandles that binds to native code. A possi- ble binding might look like the following snippet: 001 int[] values = new int[2]; 002 int x = values[0]; 003 int y = values[1]; 001 public void call() { 002 MethodHandle handle = MethodHandles They might also be passed around in CPU reg- 003 .findNative(null, isters and most probably wouldn’t need to be allo- “getpid”, MethodType. cated on the heap. This actually would save a lot of methodType(int.class)); pointer dereferences and will offer the CPU a much 004 return (int) handle.invokeExact(); better option to prefetch data and do logical branch 005 } prediction. This may look strange if you haven’t seen A similar technique is already used to ana- MethodHandles before, but it is obviously more lyze data in a huge array. Cliff Click’s H2O architec- concise and expressive than the JNI version. The ture does exactly that, to offer extremely fast map-re- great thing here is that, just like the reflective Meth- duce operations over uniform, primitive data. od instances, MethodHandles can be (and generally In addition, value types can have constructors, should be) cached, to be called over and over again. methods, and generics. As Oracle Java language ar- You can also get a direct inlining of the native call chitect Brian Goetz so eloquently declares, it “codes into the jitted Java code. like a class, behaves like an int”. However, I still slightly prefer the JNR interface Another related feature is the anticipated spe- as it is cleaner. On the other hand, I’m pretty sure we cialized generics or, more broadly, type specializa- will get direct interface binding as a nice language tion. The idea is simple: extend the generics system abstraction over the MethodHandles API — if not to support not only objects and value types but from the specification, then from some benevolent also primitives. Using this approach the ubiquitous open-source committer. String class would be a candidate for a rewrite us- ing value types. What else? A few more things are floating around Project Valhal- Specialized generics la and Project Panama. Some of those are not directly To bring this to life (and to keep it backwards com- related to sun.misc.Unsafe but are still worth men- patible), the generics system would need to be ret- tioning. rofitted, and some new, special wildcards will bring salvation. Value types Probably the hottest topic in these discussions is val- 001 class Box
30 Java 9 and Beyond // eMag Issue 37 - Jan 2016 the description for the JVM internal type specializer Conclusion to accept any type, whether an object, a wrapper, a Overall I’m happy with the direction and accelerated value type, or a primitive. development of the JVM and Java as a language. A An amazing talk about type specialization lot of interesting and necessary solutions are under- by Brian Goetz himself is available from 2015’s JVM way and Java is converging on a modern state while Language Summit (JVMLS). the JVM is providing new efficiencies and improve- ments. Arrays 2.0 From my perspective, people are definitely ad- The proposal for Arrays 2.0 has been around for quite vised to invest in the genius piece of technology that some time, as is evident from John Rose’s talk at JVM- we call the JVM, and I expect that all JVM languages LS 2012. One of the most prominent features will be will benefit from the newly integrated features. the disappearance of the 32-bit index limitation of In general, I highly recommend the JVMLS talks the current arrays. Currently, an array in Java cannot from 2015 for more information on most of these exceed Integer.MAX_VALUE. The new arrays are ex- topics, and I suggest you read a summary of Brian pected to accept a 64-bit index. Goetz’s talk about Project Valhalla. Another nice feature is the ability to freeze ar- rays (as we saw in the serialization examples above), allowing you to create immutable arrays that can be passed around without having their contents mutat- ed. And since great things come in pairs, we can ex- pect Arrays 2.0 to support specialized generics!
ClassDynamic One more interesting proposal floating around is the so-called ClassDynamic. This proposal is proba- bly in an earlier state than any I’ve mentioned so far, so little information is currently available. But let’s try to anticipate what it will look like. A dynamic class brings the same generalization concept as specialized generics but on a broader scope. It provides some kind of template mechanism to typical coding patterns. Imagine the returned col- lection from Collections::synchronizedMap as a pattern in which every method call is simply a syn- chronized version of the original call: 001 R methodName(ARGS) { 002 synchronized (this) { 003 underlying. methodName(ARGS); 004 } 005 } Managed garbage collection. Using dynamic classes and Because JVM environments pattern templates supplied to the specializer will dramatically hate hoarders. simplify the implementation of appdynamics.com/java recurring patterns. There is not much available as I write this but I hope to see more in the near future, most probably as part of Project Valhalla.
Java 9 and Beyond // eMag Issue 37 - Jan 2016 31 Read online on InfoQ
The OpenJDK Revised Java Memory Model
by Monica Beckwith The traditional Java memory model (JMM) offers a lot of semantic guarantees in Java language.
The existing JMM, as defined in highlighting the communi- some relationships that are only JSR 133 (henceforth referred to ty-wide discussion related to partially ordered. For example, as JMM-JSR133), specifies consis- how we can improve them in a “happens-before” and “synchro- tency models for shared memory future version of the JMM, which nized-with” are partially ordered and provides definitions so that I will call “JMM9”. relationships. When one action developers can be consistent in “happens-before” another ac- representing the JMM-JSR133. Sequential consistency tion, the first action is not only The goal of the JMM-JSR133 and data races ordered before the second ac- specification was to refine the JMM-JSR133 talked about the tion, it is also visible to the sec- definitions of the semantics for execution of a program with ond action. Some special actions threads that interact through respect to actions. Such an ex- need to be ordered and these are memory to permit optimizations ecution combines actions with called “synchronization actions”. and provide a clear program- orders to describe the relation- Volatile reads and writes, mon- ming model. The JMM-JSR133 ship of those actions. I would like itor locks and unlocks, etc. are provided definitions and seman- to expand on a few of the orders all examples of synchronization tics not only to ensure that multi- and relationships and discuss actions. A synchronization action threaded programs would oper- what constitutes a sequentially induces the “synchronized-with” ate correctly but also efficiently consistent execution. relation with that action. A syn- with minimal impact on an exist- Let’s start with program chronized-with relationship is a ing codebase. order. A program order for each partial order, which means that With this in mind, I would thread is a total order that spec- not all pairs of synchronization like to walk through certain se- ifies the order in which the actions are included. The total mantic guarantees that were thread would perform all ac- order that spans all the synchro- either overspecified or under- tions. Sometimes, not all actions nization actions is called a “syn- specified in JMM-JSR133, while need to be ordered, so we have chronization order”, and every
32 Java 9 and Beyond // eMag Issue 37 - Jan 2016 “Out of thin air” (OoTA) execution has a synchronization problem execution when every read can order. see the write to the same vari- An execution that seems to Another major JMM-JSR133 se- able.) occur in a total order over all its mantic is the prohibition on “out A data race may happen as read and write actions is said to of thin air” (OoTA) values. The a result of speculation, and can be “sequentially consistent” (SC). happens-before model can some- eventually turn into self-fulfilling In a SC execution, the reads will times allow the “out of thin air” prophecy. OoTA guarantees are always see the value the last write creation and reading of variable about adhering to causality rules. wrote to that particular variable. values since it doesn’t require The current thinking is that cau- When a SC execution exhibits no causality. An important point to sality can break with speculative “data race”, the program is said to note is that cause by itself doesn’t writes. JMM9 aims to find the be data-race free (DRF). Data races employ the notion of data and cause of OoTA and to refine ways happen when a program has two control dependencies as we will to avoid OoTA. accesses that are not ordered by see in the following correctly syn- As you can probably already the happens-before relation, the chronized code example in which tell, JMM-JSR133 definitions were two accesses are accessing the the illegal writes are caused by tightened to prevent OoTA values same variable, and at least one of the writes themselves. from creeping in. JMM9 aims to those is a write access. SC for DRF (Note: x and y are initialized identify and correct the formal means that DRF programs be- to 0) definition to allow for some com- have as if they are SC. But strictly Thread a Thread b mon optimizations. supporting SC comes at a cost of r1 = x; r2 = y; performance: most systems will Volatile actions on non- reorder memory operations to if (r1 != 0) if (r2 != 0) volatile variables improve execution speed while y = 42; x = 42; A volatile in Java guarantees an “hiding” the latency of expensive This code is happens-before con- interaction between threads such operations. At the same time, sistent but not really sequentially that when one thread writes to a even the compilers could reor- consistent. For example, if r1 sees volatile variable, that write is not der code to optimize execution. the write of x = 42 and r2 sees the the only thing visible to other In an effort to guarantee strict write of y = 42, both x and y can threads: the other threads can sequential consistency, all such have a value of 42, which is the re- see all the writes visible to the reordering of memory operations sult of a data-race condition. thread that wrote to the volatile or code optimization can’t be r1 = x; variable. carried out and so performance Non-volatile variables don’t y = 42; suffers. JMM-JSR133 already in- have the benefit of the interac- corporates relaxed ordering re- r2 = y; tion guaranteed by the volatile strictions, and a program will not x = 42; keyword. The compiler can use see any reordering by the under- Here, both writes were commit- a cached value of the non-vola- lying compiler, cache-memory in- ted before the read of their vari- tile variable instead of the vola- teractions, and the JIT itself. ables and the reads would see tile guarantee that the volatile Performance is an import- the respective writes, and that variable will always be read from ant consideration for JMM9, and would lead to OoTA result. memory. The happens-before moreover any programming lan- In order to prohibit OoTA model can be used to tie synchro- guage’s memory model should values, some writes need to wait nized access to the non-volatile allow all developers to take ad- for their reads to avoid data races. variables. vantage of architectural memory The JMM-JSR133 OoTA prohibi- Declaring any field as “vol- models that are weakly ordered. tion formalized the disallowance atile” doesn’t mean that locking (Weak ordering refers to architec- of OoTA reads. This formal defini- is involved, so volatiles are less tures that can reorder reads and tion consisted of “executions and expensive than synchronizations writes and would need explicit causality requirements” of the that use locks. But it’s important memory barriers to curb such memory model. Basically, a well- to note that having multiple vol- reordering.) There are successful formed execution satisfies the atile fields inside your methods implementations and examples causality requirements if all of the could make them more expen- that relax strict ordering espe- program actions could be com- sive than locking those methods. cially on weakly ordered architec- mitted. (A well-formed execution tures. happens in an intra-thread that consistently obeys happens-be- fore and synchronization-order
Java 9 and Beyond // eMag Issue 37 - Jan 2016 33 Read and write atomicity and word tearing 64-bit processing has become the read the final field’s initialized mainstream. This highlights the value of “y”. The same can’t be JMM-JSR133 also guaranteed compromise that JMM-JSR133 guaranteed of a normal, non-final (with exceptions) read and write made with respect to 64-bit read field. atomicity for shared-memory and writes: although 64-bit val- In light of the above, there concurrent algorithms. The ex- ues can be made atomic on any are some simple things that can ceptions were for non-volatile architecture, there is still a need be fixed in JMM9. For example, a long and double values where to acquire locks on some archi- volatile field initialized in a con- a write to either was treated as tectures. That makes 64-bit reads structor is not guaranteed to be two separate writes. Thus a single and writes expensive on those ar- visible even if the instance itself 64-bit value could be written by chitectures. If a reasonable imple- is visible. Should the final-field two separate 32-bit writes, and a mentation of atomic 64-bit oper- guarantees be extended to all thread that is reading while one ations on 32-bit x86 architecture field initializations including vola- of those writes is still outstand- can’t be found then the atomicity tiles? And if the value of a normal, ing may see only half the correct will not be changed. non-final field of a completely value and lose atomicity. This is An underlying issue in lan- initialized object doesn’t change, an example of how the atomicity guage design is that the “vola- can we extend the final-field guarantee relies on underlying tile” keyword is overloaded with guarantees to this normal field? hardware and the memory sub- meanings. It is difficult for the system. The underlying assembly runtime to figure out if the user Bibliography instruction should be able handle put “volatile” to regain atomicity I have learned a lot from these the size of operands to guarantee (meaning that it can be stripped websites, which provide great atomicity; a read or write opera- out on 64-bit platforms) or for sample code sequences. My ar- tion that has to be split into more memory-ordering purposes. ticle should be considered an in- than one operation breaks ato- When talking about access troductory article — look at the micity (as is the case of non-vol- atomicity, the independence of following for a deeper grasp of atile long and double values). read and write operations is an the Java memory model. Similarly, if the implementation important consideration. A write • JSR 133: JavaTM Memory causes more than one memory to a particular field should not in- Model and Thread Specifica- subsystem transaction then that teract with a read from or write to tion Revision too breaks atomicity. (Volatile any other field. This JMM-JSR133 • The Java Memory Model long and double fields and refer- guarantee means that synchroni- • Java Concurrency (&C) blog ences are always guaranteed for zation should not be needed to • The jmm-dev Archives read and write atomicity.) provide sequential consistency. • The Java Language Specifica- The favoring of one bit-ness The JMM-JSR133 guarantee pro- tion, Ch. 17: Threads and Locks over the other isn’t an ideal solu- hibits a problem known as “word • Synchronization and the Java tion because if the exception for tearing”, which happens, basical- Memory Model 64-bit-ness is removed then 32- ly, when an update to an operand • All Accesses Are Atomic bit architectures suffer. If the 64- wants to operate at a lower gran- • Java Memory Model Pragmat- bit architectures are penalized ularity than the underlying ar- ics (transcript) then you have to introduce vola- chitecture makes available for its • Memory Barriers: A Hardware tiles for longs and doubles when- operands. An important point to View for Software Hackers ever atomicity is desired even remember is that the word-tear- though the underlying hardware ing problem is one of the reasons Special thanks may guarantee atomic opera- that 64-bit longs and doubles I would like to thank Jeremy Man- tions anyway — for example, vol- are not given an atomicity guar- son for helping me correct my atiles are not needed with double antee. Word tearing is forbidden various misunderstandings and fields since the underlying archi- in JMM-JSR133 and will stay that providing cleaner definitions tecture or ISA or floating-point way in JMM9 as well. for terms that were new to me. I unit would take care of the ato- would also like to thank Aleksey micity needs of the 64-bit-wide The final-field problem Shipilev for helping with reduc- field. JMM9 aims at identifying Final fields are different than oth- ing the conceptual complexities the atomicity guarantee provided er fields. For example, a thread that were present in the draft ver- by the hardware. reading a completely initialized sion of this article. Aleksey also JMM-JSR133 was written (meaning that the object’s con- guided me to his JMM pragmatics more than a decade ago; proces- structor has finished) object with transcript for deeper understand- sor bit-ness has since evolved and a final field “x” is guaranteed to ing, clarifications, and examples.
34 Java 9 and Beyond // eMag Issue 37 - Jan 2016 PREVIOUS ISSUES
iOS9 for Developers
This eMag provides a concise35 review of all that is essen- tial for developers to know for building apps for the lat- est release of Apple’s mobile OS. This eMag is essentially based on the video sessions from WWDC that Apple made available to developers and tries to enrich them with links to reference material that has become mean- while available online.
Graph Databases
This eMag focuses on the graph34 database landscape Patterns of DevOps and the real world use cases of graph databases. It in- Culture cludes articles and interviews covering topics like data modeling in graph databases and how companies use 36 graph databases in their application. It also includes an In this e-mag, we explore some of those patterns through testimonies from their practitioners and through analysis by article on full stack web development using a graph da- consultants in the field who have been exposed to multiple tabase. DevOps adoption initiatives. Cloud Migration
In this eMag, you’ll find practical33 advice from leading practitioners in cloud. Discover new ideas and consider- ations for planning out workload migrations.