Domain-driven design (DDD) is an approach to software development for complex needs by connecting the implementationto an evolving model.[1] The premise of domain-driven design is the following:

  • placing the project's primary focus on the core domain and domain logic;
  • basing complex designs on a model of the domain;
  • initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.

The term was coined by Eric Evans in his book of the same title.[2]

Concepts[edit source]

Concepts of the model include:

The setting in which a word or statement appears that determines its meaning;
A sphere of knowledge (ontology), influence, or activity. The subject area to which the user applies a program is the domain of the software;
A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain;
Ubiquitous Language
A language structured around the domain model and used by all team members to connect all the activities of the team with the software.

Strategic domain-driven design[edit source]

Patterns in strategic domain-driven design and the relationships between them

Ideally, it would be preferable to have a single, unified model. While this is a noble goal, in reality it typically fragments into multiple models. It is useful to recognize this fact of life and work with it.

Strategic Design is a set of principles for maintaining model integrity, distillation of the Domain Model and working with multiple models.

Bounded context[edit source]

Multiple models are in play on any large project. Yet when code based on distinct models is combined, software becomes buggy, unreliable, and difficult to understand. Communication among team members becomes confusing. It is often unclear in what context a model should not be applied.

Therefore: Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don’t be distracted or confused by issues outside.

Continuous integration[edit source]

When a number of people are working in the same bounded context, there is a strong tendency for the model to fragment. The bigger the team, the bigger the problem, but as few as three or four people can encounter serious problems. Yet breaking down the system into ever-smaller contexts eventually loses a valuable level of integration and coherency.

Therefore: Institute a process of merging all code and other implementation artifacts frequently, with automated tests to flag fragmentation quickly. Relentlessly exercise the ubiquitous language to hammer out a shared view of the model as the concepts evolve in different people’s heads.

Context map[edit source]

An individual bounded context leaves some problems in the absence of a global view. The context of other models may still be vague and in flux.

People on other teams won’t be very aware of the context bounds and will unknowingly make changes that blur the edges or complicate the interconnections. When connections must be made between different contexts, they tend to bleed into each other.

Therefore: Identify each model in play on the project and define its bounded context. This includes the implicit models of non-object-oriented subsystems. Name each bounded context, and make the names part of the ubiquitous language. Describe the points of contact between the models, outlining explicit translation for any communication and highlighting any sharing. Map the existing terrain.

Building blocks[edit source]

In the book Domain-Driven Design,[2] a number of high-level concepts and practices are articulated, such as ubiquitous language meaning that the domain model should form a common language given by domain experts for describing system requirements, that works equally well for the business users or sponsors and for the software developers. The book is very focused on describing the domain layer as one of the common layers in an object-oriented system with a multilayered architecture. In DDD, there are artifacts to express, create, and retrieve domain models:

An object that is not defined by its attributes, but rather by a thread of continuity and its identity.
Example: Most airlines distinguish each seat uniquely on every flight. Each seat is an entity in this context. However, Southwest Airlines, EasyJet and Ryanair do not distinguish between every seat; all seats are the same. In this context, a seat is actually a value object.
Value Object
An object that contains attributes but has no conceptual identity. They should be treated as immutable.
Example: When people exchange business cards, they generally do not distinguish between each unique card; they only are concerned about the information printed on the card. In this context, business cards are value objects.
A collection of objects that are bound together by a root entity, otherwise known as an aggregate root. The aggregate root guarantees the consistency of changes being made within the aggregate by forbidding external objects from holding references to its members.
Example: When you drive a car, you do not have to worry about moving the wheels forward, making the engine combust with spark and fuel, etc.; you are simply driving the car. In this context, the car is an aggregate of several other objects and serves as the aggregate root to all of the other systems.
Domain Event
A domain object that defines an event (something that happens). A domain event is an event that domain experts care about.
When an operation does not conceptually belong to any object. Following the natural contours of the problem, you can implement these operations in services. See also Service (systems architecture).
Methods for retrieving domain objects should delegate to a specialized Repository object such that alternative storage implementations may be easily interchanged.
Methods for creating domain objects should delegate to a specialized Factory object such that alternative implementations may be easily interchanged.

Disadvantages[edit source]

In order to help maintain the model as a pure and helpful language construct, the team must typically implement a great deal of isolation and encapsulation within the domain model. Consequently, a system based on domain-driven design can come at a relatively high cost. While domain-driven design provides many technical benefits, such as maintainability, Microsoft recommends that it be applied only to complex domains where the model and the linguistic processes provide clear benefits in the communication of complex information, and in the formulation of a common understanding of the domain.[3]

Relationship to other ideas[edit source]

Object-oriented analysis and design
Although, in theory, the general idea of DDD need not be restricted to object-oriented approaches, in practice DDD seeks to exploit the powerful advantages that object-oriented techniques make possible. These include entities/aggregate roots as receivers of commands/method invocations and the encapsulation of state within foremost aggregate roots and on a higher architectural level, bounded contexts. The reader should be aware that object orientation is not exclusive to OO-only languages, but can be a part of functional programming, also. Applying commands/method invocations to an entity or aggregate root can be seen as an application of a function to a data structure where the result of the function application is an identical data structure with different data and/or version (especially version if optimistic concurrency is used). In dynamic languages such as Ruby or Smalltalk, object instances can be queried on whether they support a method (by name and/or signature), which is similar to how a statically typed language might choose to use an inversion of control container (or a service bus, or a service locator) to support runtime lookup of the objects – services – that support a given protocol/method/command (see CQRS further down).
Model-driven engineering (MDE)
Model-driven architecture (MDA)
While DDD is compatible with MDA, the intent of the two concepts is somewhat different. MDA is concerned more with the means of translating a model into code for different technology platforms than with the practice of defining better domain models.
POJOs and POCOs are technical implementation concepts, specific to Java and the .NET framework respectively. However, the emergence of the terms POJO and POCO reflect a growing view that, within the context of either of those technical platforms, domain objects should be defined purely to implement the business behaviour of the corresponding domain concept, rather than be defined by the requirements of a more specific technology framework.
The naked objects pattern
Based on the premise that if you have a good enough domain model, the user interface can simply be a reflection of this domain model; and that if you require the user interface to be a direct reflection of the domain model then this will force the design of a better domain model.[4]
Domain-specific modeling (DSM)
DSM is DDD applied through the use of Domain-specific languages.
Domain-specific language (DSL)
DDD does not specifically require the use of a DSL, though it could be used to help define a DSL and support methods like domain-specific multimodeling.
Aspect-oriented programming (AOP)
AOP makes it easy to factor out technical concerns (such as security, transaction management, logging) from a domain model, and as such makes it easier to design and implement domain models that focus purely on the business logic.
Command Query Responsibility Segregation (CQRS)
CQRS is an architectural pattern for separation of reads from writes, where the former is a Query and the latter is a Command. Commands mutate state and are hence approximately equivalent to method invocation on aggregate roots/entities. Queries query state but do not mutate it. CQRS is a derivative architectural pattern from the design pattern called Command and Query Separation (CQS) which was coined by Meyer. While CQRS does not require DDD, domain-driven design makes the distinction between commands and queries, explicit, around the concept of an aggregate root. The idea is that a given aggregate root has a method that corresponds to a command and a command handler invokes the method on the aggregate root. The aggregate root is responsible for performing the logic of the operation and yielding either a number of events or a failure (exception or execution result enumeration/number) response OR (if Event Sourcing (ES) is not used) just mutating its state for a persister implementation such as an ORM to write to a data store, while the command handler is responsible for pulling in infrastructure concerns related to the saving of the aggregate root's state or events and creating the needed contexts (e.g. transactions).
Event Sourcing (ES)
An architectural pattern which warrants that your entities (as per Eric Evans’ definition) do not track their internal state by means of direct serialization or O/R mapping, but by means of reading and committing events to an event store. Where ES is combined with CQRS and DDD, aggregate roots are responsible for thoroughly validating and applying commands (often by means having their instance methods invoked from a Command Handler), and then publishing a single or a set of events which is also the foundation upon which the aggregate roots base their logic for dealing with method invocations. Hence, the input is a command and the output is one or many events which are transactionally (single commit) saved to an event store, and then often published on a message broker for the benefit of those interested (often the views are interested; they are then queried using Query-messages). When modeling your aggregate roots to output events, you can isolate the internal state event further than would be possible when projecting read-data from your entities, as is done in standard n-tier data-passing architectures. One significant benefit from this is that tooling such as axiomatic theorem provers (e.g. Microsoft Contracts or CHESS) are easier to apply, as the aggregate root comprehensively hides its internal state. Events are often persisted based on the version of the aggregate root instance, which yields a domain model that synchronizes in distributed systems around the concept of optimistic concurrency.

Tools[edit source]

Practicing DDD does not depend upon the use of any particular software tool or framework. Nonetheless, there is a growing number of open-source tools and frameworks that provide support to the specific patterns advocated in Evans' book or the general approach of DDD. Among these are:

  • Actifsource is a plug-in for Eclipse which enables software development combining DDD with model-driven engineering and code generation.
  • Apache Isis is a Java framework for developing domain-driven and RESTful applications using the Naked Objects pattern.
  • ECO (Domain Driven Design): Framework with database, class, code and state machine generation from UML diagrams by CapableObjects.
  • OpenMDX: Open source, Java based, MDA Framework supporting Java SEJava EE, and .NET. OpenMDX differs from typical MDA frameworks in that "use models to directly drive the runtime behavior of operational systems".
  • OpenXava: Generates an AJAX application from JPA entities. You only need to write the domain classes to obtain a ready to use application.
  • Restful Objects is a standard for a Restful API onto a domain object model (where the domain objects may represent entities, view models, or services). Two open source frameworks (one for Java, one for .NET) can create a Restful Objects API from a domain model automatically, using reflection.
  • CubicWeb is an open source semantic web framework entirely driven by a data model. High-level directives allow to refine the data model iteratively, release after release. Defining the data model is enough to get a functioning web application. Further work is required to define how the data is displayed when the default views are not sufficient.
  • ENode: is a C# framework which support to develop DDD+CQRS+Event Sourcing architecture style applications.

See also[edit source]

source -

'Computer Science > Software Engineering' 카테고리의 다른 글

Domain-driven design  (0) 2018.03.17
Multitier architecture  (0) 2012.11.22
DRY(Don't repeat yourself)  (0) 2012.11.22
애자일(Agile) 소프트웨어 개발  (0) 2012.04.12
상관 모델링(CRUD MATRIX)  (0) 2012.04.09
프로그래밍 순서 및 순서도(Flowchart)  (0) 2012.03.12
Posted by linuxism

JDK 9 Features

Development/Java 2018.02.25 08:24

Java Platform, Standard Edition

What’s New in Oracle JDK 9

Release 9


September 2017

Overview of What’s New in JDK 9

Java Platform, Standard Edition 9 is a major feature release. The following summarizes features and enhancements in Java SE 9 and in JDK 9, Oracle's implementation of Java SE 9.

A JDK Enhancement Proposal (JEP) is a proposal to design and implement a nontrivial change to the JDK. See JEP 1: JDK Enhancement-Proposal & Roadmap Process. A Java Specification Request (JSR) describes proposed and final specifications for the Java platform. See JSR Overview.

Key Changes in JDK 9

These changes affect more than one technology area.

Java Platform Module SystemIntroduces a new kind of Java programing component, the module, which is a named, self-describing collection of code and data. This module system:
  • Introduces a new optional phase, link time, which is in-between compile time and run time, during which a set of modules can be assembled and optimized into a custom runtime image; see the jlink tool in Java Platform, Standard Edition Tools Reference.
  • Adds options to the tools javacjlink, and java where you can specify module paths, which locate definitions of modules.
  • Introduces the modular JAR file, which is a JAR file with a module-info.class file in its root directory.
  • Introduces the JMOD format, which is a packaging format similar to JAR except it can include native code and configuration files; see the jmod tool.

The JDK itself has been divided into a set of modules. This change:

  • Enables you to combine the JDK's modules into a variety of configurations, including:

    • Configurations corresponding to the JRE and the JDK.
    • Configurations roughly equivalent in content to each of the Compact Profiles defined in Java SE 8.
    • Custom configurations that contain only a specified set of modules and their required modules.
  • Restructures the JDK and JRE runtime images to accommodate modules and improve performance, security, and maintainability.

  • Defines a new URI scheme for naming modules, classes, and resources stored in a runtime image without revealing the internal structure or format of the image.

  • Removes the endorsed-standards override mechanism and the extension mechanism.

  • Removes rt.jar and tools.jar from the Java runtime image.

  • Makes most of the JDK's internal APIs inaccessible by default but leaves a few critical, widely used internal APIs accessible until supported replacements exist for all or most of their functionality.

    Run the command jdeps -jdkinternals to determine if your code uses internal JDK APIs.

For more information, see the following:

JEP 223: New Version-String Scheme

Provides a simplified version-string format that helps to clearly distinguish major, minor, security, and patch update releases.

The new version-string format is as follows:

  • $MAJOR is the version number that is incremented for a major release, for example JDK 9, which contains significant new features as specified by the Java SE platform specification. A major release contains new features and changes to existing features, which are planned and announced well in advance.

  • $MINOR is the version number that is incremented for each minor update, such as bug fixes, revisions to standard APIs, or implementation of features outside the scope of the relevant platform specifications.

  • $SECURITY is the version number that is incremented for a security-update release, which contains critical fixes, including those necessary to improve security.

  • $PATCH is the version number that is incremented for a release containing security and high-priority customer fixes that have been tested together.

See New Version String Format in Java Platform, Standard Edition Installation Guide.

What’s New for the JDK 9 Installer

JDK 9 includes installer enhancements for Microsoft Windows and macOS platforms.

Installer Enhancements for Microsoft Windows


Enable or Disable Web Deployment with Installer's UI

Provides the option to enable or disable web deployment in the Welcome page of the installer. To enable web deployment, in the Welcome page, select Custom Setup , click Install, and select the Enable Java content in the Browser check box.

Installer Enhancements for macOS


CPU Version Availability

Provides notification on next CPU availability after uninstalling the current CPU version.

User Experience

Enhanced user experience while updating the JRE.

What’s New for Tools in JDK 9

These are the tools enhancements in JDK 9.

JEP 222: jshell: The Java Shell (Read-Eval-Print Loop)

Adds Read-Eval-Print Loop (REPL) functionality to the Java platform.

The jshell tool provides an interactive command-line interface for evaluating declarations, statements, and expressions of the Java programming language. It facilitates prototyping and exploration of coding options with immediate results and feedback. The immediate feedback combined with the ability to start with expressions is useful for education—whether learning the Java language or just learning a new API or language feature.

See jshell in Java Platform, Standard Edition Tools Reference, and Introduction to JShell in Java Platform, Standard Edition Java Shell User’s Guide.

The JShell API enables applications to leverage REPL functionality. See the jdk.jshell package.

JEP 228: Add More Diagnostic Commands

Defines additional diagnostic commands to improve the ability to diagnose issues with Hotspot and the JDK.

See jcmd in Java Platform, Standard Edition Tools Reference.

JEP 231: Remove Launch-Time JRE Version Selection

Removes the ability to request a version of the JRE that is not the JRE being launched at launch time.

Modern applications are typically deployed through Java Web Start (with a JNLP file), native OS packaging systems, or active installers. These technologies have their own methods to manage the JREs needed by finding or downloading and updating the required JRE as needed. This makes launch-time JRE version selection obsolete.

JEP 238: Multi-Release JAR Files

Extends the JAR file format to enable multiple, Java release-specific versions of class files to coexist in a single archive.

A multirelease JAR (MRJAR) contains additional, versioned directories for classes and resources specific to particular Java platform releases. Specify versioned directories with the jar tool's --release option.

JEP 240: Remove the JVM TI hprof Agent

Removes the hprof agent from the JDK. The hprof agent was written as demonstration code for the JVM Tool Interface and not intended to be a production tool.

The useful features of the hprof agent have been superseded by better alternatives.


While the hprof agent has been removed, it is still possible to create heap dumps in the hprof format using jmap or other diagnostic tools. See Diagnostic Tools in Java Platform, Standard Edition Troubleshooting Guide.

JEP 241: Remove the jhat Tool

Removes the jhat tool from the JDK.

The jhat tool was an experimental and unsupported tool added in JDK 6. It is out of date; superior heap visualizers and analyzers have been available for many years.

JEP 245: Validate JVM Command-Line Flag Arguments

Validates arguments to all numerical JVM command-line flags to avoid failures and instead displays an appropriate error message if they are found to be invalid.

Range and optional constraint checks have been implemented for arguments that require a user-specified numerical value.

See java and Validate Java Virtual Machine Flag Arguments in Java Platform, Standard Edition Tools Reference.

JEP 247: Compile for Older Platform Versions

Enhances javac so that it can compile Java programs to run on selected earlier versions of the platform.

When using the -source or -target options, the compiled program might accidentally use APIs that are not supported on the given target platform. The --release option will prevent accidental use of APIs.

See javac in Java Platform, Standard Edition Tools Reference.

JEP 282: jlink: The Java Linker

Assembles and optimizes a set of modules and their dependencies into a custom runtime image as defined in JEP 220.

The jlink tool defines a plug-in mechanism for transformation and optimization during the assembly process, and for the generation of alternative image formats. It can create a custom runtime optimized for a single program. JEP 261 defines link time as an optional phase between the phases of compile time and run time. Link time requires a linking tool that assembles and optimizes a set of modules and their transitive dependencies to create a runtime image or executable.

See jlink in Java Platform, Standard Edition Tools Reference.

What’s New for Security in JDK 9

These are the security enhancements in JDK 9.

JEP 219: Datagram Transport Layer Security (DTLS)

Enables Java Secure Socket Extension (JSSE) API and the SunJSSE security provider to support DTLS Version 1.0 and DTLS Version 1.2 protocols.

See Datagram Transport Layer Security (DTLS) in Java Platform, Standard Edition Security Developer's Guide.

JEP 244: TLS Application-Layer Protocol Negotiation Extension

Enables the client and server in a Transport Layer Security (TLS) connection to negotiate the application protocol to be used. With Application-Layer Protocol Negotiation (ALPN), the client sends the list of supported application protocols as part of the TLS ClientHello message. The server chooses a protocol and returns the selected protocol as part of the TLS ServerHello message. The application protocol negotiation can be accomplished within the TLS handshake, without adding network round-trips.

See TLS Handshake and Application Layer Protocol Negotiation in Java Platform, Standard Edition Security Developer's Guide.

JEP 249: OCSP Stapling for TLS

Enables the server in a TLS connection to check for a revoked X.509 certificate revocation. The server does this during TLS handshaking by contacting an Online Certificate Status Protocol (OCSP) responder for the certificate in question. It then attaches or "staples" the revocation information to the certificate that it returns to the client so that the client can take appropriate action.

Enables the client to request OCSP stapling from a TLS server. The client checks stapled responses from servers that support the feature.

See OCSP Stapling in Java Platform, Standard Edition Security Developer's Guide.

JEP 246: Leverage CPU Instructions for GHASH and RSA

Improves performance ranging from 34x to 150x for AES/GCM/NoPadding using GHASH HotSpot intrinsics. GHASH intrinsics are accelerated by the PCLMULQDQ instruction on Intel x64 CPU and the xmul/xmulhi instructions on SPARC.

Improves performance up to 50% for BigInteger squareToLen and BigInteger mulAdd methods using RSA HotSpot intrinsics. RSA intrinsics apply to the java.math.BigInteger class on Intel x64.

A new security property is introduced to configure providers that offer significant performance gains for specific algorithms.

See Configuring the Preferred Provider for Specific Algorithms in Java Platform, Standard Edition Security Developer's Guide.

JEP 273: DRBG-Based SecureRandom Implementations

Provides the functionality of Deterministic Random Bit Generator (DRBG) mechanisms as specified in NIST SP 800-90Ar1 in the SecureRandom API.

The DRBG mechanisms use modern algorithms as strong as SHA-512 and AES-256. Each of these mechanisms can be configured with different security strengths and features to match user requirements.

See Generating Random Numbers in Java Platform, Standard Edition Security Developer's Guide.

JEP 288: Disable SHA-1 Certificates

Improves the security configuration of the JDK by providing a more flexible mechanism to disable X.509 certificate chains with SHA-1-based signatures.

Disables SHA-1 in TLS Server certificate chains anchored by roots included by default in the JDK; local or enterprise certificate authorities (CAs) are not affected.

The jdk.certpath.disabledAlgorithms security property is enhanced with several new constraints that allow greater control over the types of certificates that can be disabled.

See JEP 288.

JEP 229: Create PKCS12 Keystores by Default

Modifies the default keystore type from JKS to PKCS12. PKCS#12 is an extensible, standard, and widely supported format for storing cryptographic keys. PKCS12 keystores improve confidentiality by storing private keys, trusted public key certificates, and secret keys. This feature also opens opportunities for interoperability with other systems such as Mozilla, Microsoft's Internet Explorer, and OpenSSL that support PKCS12.

The SunJSSE provider supplies a complete implementation of the PKCS12 format for reading and writing PKCS12 files.

See Key Management in Java Platform, Standard Edition Security Developer's Guide.

The keytool key and certificate management utility can create PKCS12 keystores.

See Creating a Keystore in Java Platform, Standard Edition Security Developer's Guide and keytoolin Java Platform, Standard Edition Tools Reference.

JEP 287: SHA-3 Hash Algorithms

Supports SHA-3 cryptographic hash functions as specified in NIST FIPS 202.

The following additional standard algorithms are supported by the SHA3-224, SHA3-256, SHA3-384, and SHA3-512.

The following providers support SHA-3 algorithm enhancements:

  • SUN provider: SHA3-224, SHA3-256, SHA3-384, and SHA3-512

  • OracleUcrypto provider: SHA-3 digests supported by Solaris 12.0

What’s New for Deployment in JDK 9

These are the deployment enhancements in JDK 9.

Deprecate the Java Plug-in

Deprecates the Java Plug-in and associated applet technologies in Oracle's JDK 9 builds. While still available in JDK 9, these technologies will be considered for removal from the Oracle JDK and JRE in a future release.

Applets and JavaFX applications embedded in a web page require the Java Plug-in to run. Consider rewriting these types of applications as Java Web Start or self-contained applications.

See Migrating Java Applets to Java Web Start and JNLP and Self-Contained Application Packaging in Java Platform, Standard Edition Deployment Guide.

Enhanced Java Control Panel

Improves the grouping and presentation of options within the Java Control Panel. Information is easier to locate, a search field is available, and modal dialog boxes are no longer used. Note that the location of some options has changed from previous versions of the Java Control Panel.

See Java Control Panel in Java Platform, Standard Edition Deployment Guide.

JEP 275: Modular Java Application Packaging

Integrates features from Project Jigsaw into the Java Packager, including module awareness and custom runtime creation.

Leverages the jlink tool to create smaller packages.

Creates applications that use the JDK 9 runtime only. Cannot be used to package applications with an earlier release of the JRE.

See Customization of the JRE and Packaging for Modular Applications in Java Platform, Standard Edition Deployment Guide.

JEP 289: Deprecate the Applet API

Deprecates the Applet API, which is becoming less useful as web browser vendors remove support for Java browser plug-ins. While still available in JDK 9, the Applet class will be considered for removal in a future release. Consider rewriting applets as Java Web Start or self-contained applications.

See Migrating Java Applets to Java Web Start and JNLP and Self-Contained Application Packaging in Java Platform, Standard Edition Deployment Guide.

What’s New for the Java Language in JDK 9

A few very small language changes are included in Java SE 9.

JEP 213: Milling Project Coin

Identifies a few small changes:

  • Allow @SafeVargs on private instance methods.

  • Allow effectively final variables to be used as resources in the try-with-resources statement.

  • Allow the diamond with anonymous classes if the argument type of the inferred type is denotable.

  • Complete the removal, begun in Java SE 8, of the underscore from the set of legal identifier names.

  • Add support for private interface methods.

See Java Language Changes for Java SE 9 in Java Platform, Standard Edition Java Language Updates.

What’s New for Javadoc in JDK 9

Javadoc enhancements include the following: a simplified Doclet API, Javadoc search, support for generating HTML5 output, and support for documentation comments in module systems.

JEP 221: Simplified Doclet API

Replaces the old Doclet API with a new simplified API that leverages other standard, existing APIs. The standard doclet has been rewritten to use the new Doclet API.


The existing API and old standard doclet are available, but have not been updated to support new language features, such as modules.
JEP 224: HTML5 Javadoc

Supports generating HTML5 output. To get fully compliant HTML5 output, ensure that any HTML content provided in documentation comments are compliant with HTML5.

JEP 225: Javadoc Search

Provides a search box to the generated API documentation. Use this search box to find program elements, tagged words, and phrases within the documentation.

JEP 261: Module System

Supports documentation comments in module declarations. Includes new command-line options to configure the set of modules to be documented and generates a new summary page for any modules being documented.

What’s New for the JVM in JDK 9

These are the JVM enhancements in JDK 9.

JEP 165: Compiler Control

Provides a way to control JVM compilation through compiler directive options. The level of control is runtime-manageable and method-specific. Compiler Control supersedes, and is backward compatible, with CompileCommand.

See Compiler Control in Java Platform, Standard Edition Java Virtual Machine Guide.

JEP 197: Segmented Code Cache

Divides the code cache into distinct segments, each of which contains compiled code of a particular type, to improve performance and enable future extensions.

See java in Java Platform, Standard Edition Tools Reference.

JEP 276: Dynamic Linking of Language-Defined Object Models

Dynamically links high-level object operations at run time, such as read a property, write a property, and invoke a function, to the appropriate target method handles. It links these operations to target method handles based on the actual types of the values passed. These object operations are expressed as invokedynamic sites.

While java.lang.invoke provides a low-level API for dynamic linking of invokedynamic call sites, it doesn't provide a way to express higher level operations on objects nor methods that implement them.

With the package jdk.dynalink, you can implement programming languages whose expressions contain dynamic types (types that cannot be determined statically) and whose operations on these dynamic types are expressed as invokedynamic call sites (because the language's object model or type system doesn't closely match that of the JVM).

What’s New for JVM Tuning in JDK 9

These are the JVM tuning enhancements in JDK 9.

Improve G1 Usability, Determinism, and Performance

Enhances the Garbage-First (G1) garbage collector to automatically determine several important memory-reclamation settings. Previously these settings had to be set manually to obtain optimal results. In addition, fixes issues with the usability, determinism, and performance of the G1 garbage collector.

JEP 158: Unified JVM Logging

Introduces a common logging system for all components of the JVM.

See the -Xloggc java option in Java Platform, Standard Edition Tools Reference.

JEP 214: Remove GC Combinations Deprecated in JDK 8

Removes garbage collector (GC) combinations that were deprecated in JDK 8.

This means that the following GC combinations no longer exist:

  • DefNew + CMS

  • ParNew + SerialOld

  • Incremental CMS

The "foreground" mode for Concurrent Mark Sweep (CMS) has also been removed. The following command-line flags have been removed:

  • -Xincgc
  • -XX:+CMSIncrementalMode
  • -XX:+UseCMSCompactAtFullCollection
  • -XX:+CMSFullGCsBeforeCompaction
  • -XX:+UseCMSCollectionPassing

The command line flag -XX:+UseParNewGC no longer has an effect. ParNew can only be used with CMS and CMS requires ParNew. Thus, the -XX:+UseParNewGC flag has been deprecated and will likely be removed in a future release.

JEP 248: Make G1 the Default Garbage Collector

Makes Garbage-First (G1) the default garbage collector (GC) on 32- and 64-bit server configurations. Using a low-pause collector such as G1 provides a better overall experience, for most users, than a throughput-oriented collector such as the Parallel GC, which was previously the default.

See Garbage-First Garbage Collector in Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide
JEP 271: Unified GC Logging

Reimplements Garbage Collection (GC) logging using the unified JVM logging framework introduced in JEP 158. GC logging is re-implemented in a manner consistent with the current GC logging format; however, some differences exist between the new and old formats.

See Enable Logging with the JVM Unified Logging Framework in Java Platform, Standard Edition Tools Reference.

JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector

Deprecates the Concurrent Mark Sweep (CMS) garbage collector. A warning message is issued when it is requested on the command line, using the -XX:+UseConcMarkSweepGC option. The Garbage-First (G1) garbage collector is intended to be a replacement for most uses of CMS.

What’s New for Core Libraries in JDK 9

JEP 102: Process API Updates

Improves the API for controlling and managing operating system processes.

The ProcessHandle class provides the process's native process ID, arguments, command, start time, accumulated CPU time, user, parent process, and descendants. The class can also monitor processes' liveness and destroy processes. With the ProcessHandle.onExit method, the asynchronous mechanisms of the CompletableFuture class can perform an action when the process exits.

See Process API in Java Platform, Standard Edition Java Core Libraries Developer's Guidejava.lang.Process, and java.lang.ProcessHandle.

JEP 193: Variable Handles

Defines a standard means to invoke the equivalents of java.util.concurrent.atomic and sun.misc.Unsafe operations upon object fields and array elements.

Defines a standard set of fence operations, which consist of VarHandle static methods that enable fine-grained control of memory ordering. This is an alternative to sun.misc.Unsafe, which provides a nonstandard set of fence operations.

Defines a standard reachability fence operation to ensure that a referenced object remains strongly reachable.

JEP 254: Compact Strings

Adopts a more space-efficient internal representation for strings. Previously, the String class stored characters in a char array, using two bytes (16 bits) for each character. The new internal representation of the String class is a byte array plus an encoding-flag field.

This is purely an implementation change, with no changes to existing public interfaces.

See the CompactStrings option of the java command in Java Platform, Standard Edition Tools Reference.

JEP 264: Platform Logging API and Service

Defines a minimal logging API that platform classes can use to log messages, together with a service interface for consumers of those messages. A library or application can provide an implementation of this service to route platform log messages to the logging framework of its choice. If no implementation is provided, then a default implementation based on the java.util.logging API is used.

JEP 266: More Concurrency Updates

Adds further concurrency updates to those introduced in JDK 8 in JEP 155: Concurrency Updates, including an interoperable publish-subscribe framework and enhancements to the CompletableFuture API.

JEP 268: XML Catalogs

Adds a standard XML Catalog API that supports the Organization for the Advancement of Structured Information Standards (OASIS) XML Catalogs version 1.1 standard. The API defines catalog and catalog-resolver abstractions that can be used as an intrinsic or external resolver with the JAXP processors that accept resolvers.

Existing libraries or applications that use the internal catalog API will need to migrate to the new API to take advantage of the new features.

See XML Catalog API in Java Platform, Standard Edition Java Core Libraries Developer's Guide.

JEP 269: Convenience Factory Methods for Collections

Makes it easier to create instances of collections and maps with small numbers of elements. New static factory methods on the ListSet, and Map interfaces make it simpler to create immutable instances of those collections.

For example:
Set<String> alphabet = Set.of("a", "b", "c");

See Creating Immutable Lists, Sets, and Maps in Java Platform, Standard Edition Java Core Libraries Developer's Guide. For API documentation, see Immutable Set Static Factory MethodsImmutable Map Static Factory Methods, and Immutable List Static Factory Methods.

JEP 274: Enhanced Method Handles

Enhances the MethodHandleMethodHandles, and MethodHandles.Lookup classes of the java.lang.invoke package to ease common use cases and enable better compiler optimizations.

Additions include:
  • In the MethodHandles class in the java.lang.invoke package, provide new MethodHandlecombinators for loops and try/finally blocks.

  • Enhance the MethodHandle and MethodHandles classes with new MethodHandle combinators for argument handling.

  • Implement new lookups for interface methods and, optionally, super constructors in the MethodHandles.Lookup class.

JEP 277: Enhanced Deprecation
Revamps the @Deprecated annotation to provide better information about the status and intended disposition of an API in the specification. Two new elements have been added:
  • @Deprecated(forRemoval=true) indicates that the API will be removed in a future release of the Java SE platform.

  • @Deprecated(since="version") contains the Java SE version string that indicates when the API element was deprecated, for those deprecated in Java SE 9 and beyond.

For example: @Deprecated(since="9", forRemoval=true)

@Deprecated annotations in the core platform have been updated.

You can use a new tool, jdeprscan, to scan a class library (JAR file) for uses of deprecated JDK API elements.

See Enhanced Deprecation in Java Platform, Standard Edition Java Core Libraries Developer's Guide.

See jdperscan in Java Platform, Standard Edition Tools Reference.

JEP 285: Spin-Wait Hints

Defines an API that enables Java code to hint that a spin loop is executing. A spin loop repeatedly checks to see if a condition is true, such as when a lock can be acquired, after which some computation can be safely performed followed by the release of the lock. This API is purely a hint, and carries no semantic behavior requirements. See the method Thread.onSpinWait.

JEP 290: Filter Incoming Serialization Data

Allows incoming streams of object-serialization data to be filtered to improve both security and robustness. Object-serialization clients can validate their input more easily, and exported Remote Method Invocation (RMI) objects can validate invocation arguments more easily as well.

Serialization clients implement a filter interface that is set on an ObjectInputStream. For RMI, the object is exported through a RemoteServerRef that sets the filter on the MarshalInputStream to validate the invocation arguments as they are unmarshalled.

JEP 259: Stack-Walking API

Provides a stack-walking API that allows easy filtering and lazy access to the information in stack traces.

The API supports both short walks that stop at a frame that matches given criteria, and long walks that traverse the entire stack. Stopping at a frame that matches a given criteria avoids the cost of examining all the frames if the caller is interested only in the top frames on the stack. The API enables access to Class objects when the stack walker is configured to do so. See the class java.lang.Stackwalker.

JEP 255: Merge Selected Xerces 2.11.0 Updates into JAXP

Updates the JDK to support the 2.11.0 version of the Xerces parser. There is no change to the public JAXP API.

The changes are in the following categories of Xerces 2.11.0: Datatypes, DOM L3 Serializer, XPointer, Catalog Resolver, and XML Schema Validation (including bug fixes, but not the XML Schema 1.1 development code).

What's New for Nashorn in JDK 9

These are the Nashorn enhancements in JDK 9.

JEP 236: Parser API for Nashorn

Enables applications, in particular IDEs and server-side frameworks, to parse and analyze ECMAScript code.

Parse ECMAScript code from a string, URL, or file with methods from the Parser class. These methods return an instance of CompilationUnitTree, which represents ECMAScript code as an abstract syntax tree.

The package jdk.nashorn.api.tree contains the Nashorn parser API.

JEP 292: Implement Selected ECMAScript 6 Features in NashornImplements many new features introduced in the 6th edition of ECMA-262, also known as ECMAScript 6, or ES6 for short. Implemented features include the following:
  • Template strings
  • letconst, and block scope
  • Iterators and for..of loops
  • MapSetWeakMap, and WeakSet
  • Symbols
  • Binary and octal literals

What’s New for Client Technologies in JDK 9

These are the client technologies enhancements in JDK 9.

JEP 251: Multi-Resolution Images

Enables a set of images with different resolutions to be encapsulated into a single multiresolution image. This could be useful for applications to adapt to display devices whose resolutions may vary from approximately 96dpi to 300dpi during run time.

The interface java.awt.image.MultiResolutionImage encapsulates a set of images with different resolutions into a single multiresolution image, which enables applications to easily manipulate and display images with resolution variants.

JEP 253: Prepare JavaFX UI Controls and CSS APIs for Modularization

Provides public APIs for JavaFX UI controls and CSS functionality that were previously available only through internal packages but are now inaccessible due to modularization.

The new package consists of a set of classes that provides a default implementation for the skin (or the look) of each UI control.

The new class CssParser is a CSS parser that returns a Stylesheet object, which gives you more control over the CSS styling of your application. It’s part of the CSS API (the javafx.css package). The CSS API includes new support classes, including a set of standard converters used by the parser; see the javafx.css.converter package.

JEP 256: BeanInfo Annotations

Replaces the @beaninfo Javadoc tag with the annotation types JavaBeanBeanProperty, and SwingContainer.

These annotation types set the corresponding feature attributes during BeanInfo generation at runtime. Thus, you can more easily specify these attributes directly in Bean classes instead of creating a separate BeanInfo class for every Bean class. It also enables the removal of automatically generated classes, which makes it easier to modularize the client library.

JEP 262: TIFF Image I/O

Adds Tag Image File Format (TIFF) reading and writing as standard to the package javax.imageio. The new package javax.imageio.plugins.tiff provides classes that simplify the optional manipulation of TIFF metadata.

JEP 263: HiDPI Graphics on Windows and Linux

Automatically scales and sizes AWT and Swing components for High Dots Per Inch (HiDPI) displays on Windows and Linux.

The JDK already supports HiDPI "retina displays" on OS X.

Prior to this release, on Windows and Linux, Java applications were sized and rendered based on pixels, even on HiDPI displays that can have pixel densities two to three times as high as traditional displays. This led to GUI components and windows that were too small to read or use.

JEP 272: Platform-Specific Desktop Features

Adds additional methods to the class java.awt.Desktop that enable you to interact with the desktop, including the following:

  • Show custom About and Preferences windows.

  • Handle requests to open or print a list of files.

  • Handle requests to open a URL.

  • Open the native help viewer application.

  • Set the default menu bar.

  • Enable or disable the application to be suddenly terminated.

These new methods replace the functionality of the internal APIs contained in the OS X package, which are not accessible by default in JDK 9. Note that the package is no longer accessible.

JEP 283: Enable GTK 3 on Linux

Enables Java graphical applications, whether based on JavaFX, Swing, or Abstract Window Toolkit (AWT), to use either the GTK+ version 2 or version 3 on Linux or Solaris.

By default, the JDK on Linux or Solaris uses GTK+ 2 if available; if not, it uses GTK+ 3.

To use a specific version of GTK+, set the system property jdk.gtk.version. This system property may have a value of 2, 2.2, or 3. You must set this property before your application loads GTK+, and it must not conflict with a GTK+ version that may have been loaded earlier by another toolkit.

What’s New for Internationalization in JDK 9

These are the internationalization enhancements in JDK 9.

JEP 267: Unicode 8.0

Supports Unicode 8.0. JDK 8 supported Unicode 6.2.

The Unicode 6.37.0 and 8.0 standards combined introduced 10,555 characters, 29 scripts, and 42 blocks, all of which are supported in JDK 9.

JEP 252: CLDR Locale Data Enabled by Default

Uses the Common Locale Data Repository's (CLDR) XML-based locale data, first added in JDK 8, as the default locale data in JDK 9. In previous releases, the default was JRE.

To enable behavior compatible with JDK 8, set the system property java.locale.providers to a value with COMPAT ahead of CLDR.

See CLDR Locale Data Enabled by Default in Java Platform, Standard Edition Internationalization Guide.

JEP 226: UTF-8 Properties Files

Loads properties files in UTF-8 encoding. In previous releases, ISO-8859-1 encoding was used when loading property resource bundles. UTF-8 is a much more convenient way to represent non-Latin characters.

Most existing properties files should not be affected.

See UTF-8 Properties Files in Java Platform, Standard Edition Internationalization Guide.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit or visit if you are hearing impaired.

Java Platform, Standard Edition What’s New in Oracle JDK 9Release 9


Copyright © 2017, Oracle and/or its affiliates. All rights reserved.

This document summarizes features and enhancements in Java SE 9 and in JDK 9, Oracle's implementation of Java SE 9.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

source -

ava 9 is finally released. So it’s high time to go through Java 9 features and see what all major changes it has brought to us.

Java 9 Features

Some of the important java 9 features are;

  1. Java 9 REPL (JShell)
  2. Factory Methods for Immutable List, Set, Map and Map.Entry
  3. Private methods in Interfaces
  4. Java 9 Module System
  5. Process API Improvements
  6. Try With Resources Improvement
  7. CompletableFuture API Improvements
  8. Reactive Streams
  9. Diamond Operator for Anonymous Inner Class
  10. Optional Class Improvements
  11. Stream API Improvements
  12. Enhanced @Deprecated annotation
  13. HTTP 2 Client
  14. Мulti-Resolution Image API
  15. Miscellaneous Java 9 Features

Oracle Corporation is going to release Java SE 9 around end of March 2017. In this post, I’m going to discuss about “Java 9 Features” briefly with some examples.

  1. Java 9 REPL (JShell)

    Oracle Corp has introduced a new tool called “jshell”. It stands for Java Shell and also known as REPL (Read Evaluate Print Loop). It is used to execute and test any Java Constructs like class, interface, enum, object, statements etc. very easily.

    We can download JDK 9 EA (Early Access) software from

    |  Welcome to JShell -- Version 9-ea
    |  For an introduction type: /help intro
    jshell> int a = 10
    a ==> 10
    jshell> System.out.println("a value = " + a )
    a value = 10

    If you want to know more about REPL tool, Please go through Java 9 REPL Basics (Part-1) and Java 9 REPL Features (Part-2).

  2. Factory Methods for Immutable List, Set, Map and Map.Entry

    Oracle Corp has introduced some convenient factory methods to create Immutable List, Set, Map and Map.Entry objects. These utility methods are used to create empty or non-empty Collection objects.

    In Java SE 8 and earlier versions, We can use Collections class utility methods like unmodifiableXXX to create Immutable Collection objects. For instance, if we want to create an Immutable List, then we can use Collections.unmodifiableList method.

    However these Collections.unmodifiableXXX methods are very tedious and verbose approach. To overcome those shortcomings, Oracle corp has added couple of utility methods to List, Set and Map interfaces.

    List and Set interfaces have “of()” methods to create an empty or no-empty Immutable List or Set objects as shown below:

    Empty List Example

    List immutableList = List.of();

    Non-Empty List Example

    List immutableList = List.of("one","two","three");

    Map has two set of methods: of() methods and ofEntries() methods to create an Immutable Map object and an Immutable Map.Entry object respectively.

    Empty Map Example

    jshell> Map emptyImmutableMap = Map.of()
    emptyImmutableMap ==> {}

    Non-Empty Map Example

    jshell> Map nonemptyImmutableMap = Map.of(1, "one", 2, "two", 3, "three")
    nonemptyImmutableMap ==> {2=two, 3=three, 1=one}

    If you want to read more about these utility methods, please go through the following links:

  3. Private methods in Interfaces

    In Java 8, we can provide method implementation in Interfaces using Default and Static methods. However we cannot create private methods in Interfaces.

    To avoid redundant code and more re-usability, Oracle Corp is going to introduce private methods in Java SE 9 Interfaces. From Java SE 9 on-wards, we can write private and private static methods too in an interface using ‘private’ keyword.

    These private methods are like other class private methods only, there is no difference between them.

    public interface Card{
      private Long createCardID(){
        // Method implementation goes here.
      private static void displayCardDetails(){
        // Method implementation goes here.

    If you want to read more about this new feature, please go through this link: Java 9 Private methods in Interface.

  4. Java 9 Module System

    One of the big changes or java 9 feature is the Module System. Oracle Corp is going to introduce the following features as part of Jigsaw Project.

    • Modular JDK
    • Modular Java Source Code
    • Modular Run-time Images
    • Encapsulate Java Internal APIs
    • Java Platform Module System

    Before Java SE 9 versions, we are using Monolithic Jars to develop Java-Based applications. This architecture has lot of limitations and drawbacks. To avoid all these shortcomings, Java SE 9 is coming with Module System.

    JDK 9 is coming with 92 modules (may change in final release). We can use JDK Modules and also we can create our own modules as shown below:

    Simple Module Example

    module { }

    Here We are using ‘module’ to create a simple module. Each module has a name, related code and other resources.

    To read more details about this new architecture and hands-on experience, please go through my original tutorials here:

  5. Process API Improvements

    Java SE 9 is coming with some improvements in Process API. They have added couple new classes and methods to ease the controlling and managing of OS processes.

    Two new interfcase in Process API:

    • java.lang.ProcessHandle
    • java.lang.ProcessHandle.Info

    Process API example

     ProcessHandle currentProcess = ProcessHandle.current();
     System.out.println("Current Process Id: = " + currentProcess.getPid());

    If you want to read more about this new API, please go through my original tutorial at: Java SE 9: Process API Improvements.

  6. Try With Resources Improvement

    We know, Java SE 7 has introduced a new exception handling construct: Try-With-Resources to manage resources automatically. The main goal of this new statement is “Automatic Better Resource Management”.

    Java SE 9 is going to provide some improvements to this statement to avoid some more verbosity and improve some Readability.

    Java SE 7 example

    void testARM_Before_Java9() throws IOException{
     BufferedReader reader1 = new BufferedReader(new FileReader("journaldev.txt"));
     try (BufferedReader reader2 = reader1) {

    Java 9 example

    void testARM_Java9() throws IOException{
     BufferedReader reader1 = new BufferedReader(new FileReader("journaldev.txt"));
     try (reader1) {

    To read more about this new feature, please go through my original tutorial at: Java 9 Try-With-Resources Improvements

  7. CompletableFuture API Improvements

    In Java SE 9, Oracle Corp is going to improve CompletableFuture API to solve some problems raised in Java SE 8. They are going add to support some delays and timeouts, some utility methods and better sub-classing.

    Executor exe = CompletableFuture.delayedExecutor(50L, TimeUnit.SECONDS);

    Here delayedExecutor() is static utility method used to return a new Executor that submits a task to the default executor after the given delay.

    To read more about this feature, please go through my original tutorial at: Java SE 9: CompletableFuture API Improvements

  8. Reactive Streams

    Now-a-days, Reactive Programming has become very popular in developing applications to get some beautiful benefits. Scala, Play, Akka etc. Frameworks has already integrated Reactive Streams and getting many benefits. Oracle Corps is also introducing new Reactive Streams API in Java SE 9.

    Java SE 9 Reactive Streams API is a Publish/Subscribe Framework to implement Asynchronous, Scalable and Parallel applications very easily using Java language.

    Java SE 9 has introduced the following API to develop Reactive Streams in Java-based applications.

    • java.util.concurrent.Flow
    • java.util.concurrent.Flow.Publisher
    • java.util.concurrent.Flow.Subscriber
    • java.util.concurrent.Flow.Processor

    If you want to read more about this new API, please go through my original tutorials at: Introduction to Reactive Programming and Java SE 9: Reactive Streams.

  9. Diamond Operator for Anonymous Inner Class

    We know, Java SE 7 has introduced one new feature: Diamond Operator to avoid redundant code and verbosity, to improve readability. However in Java SE 8, Oracle Corp (Java Library Developer) has found that some limitation in the use of Diamond operator with Anonymous Inner Class. They have fixed that issues and going to release as part of Java 9.

      public List getEmployee(String empid){
         // Code to get Employee details from Data Store
         return new List(emp){ };

    Here we are using just “List” without specifying the type parameter. To read more details about this improvement, please go through my original tutorial at: Java SE 9: Diamond Operator improvements for Anonymous Inner Class

  10. Optional Class Improvements

    In Java SE 9, Oracle Corp has added some useful new methods to java.util.Optional class. Here I’m going to discuss about one of those methods with some simple example: stream method

    If a value present in the given Optional object, this stream() method returns a sequential Stream with that value. Otherwise, it returns an Empty Stream.

    They have added “stream()” method to work on Optional objects lazily as shown below:

    Stream<Optional> emp = getEmployee(id)
    Stream empStream = emp.flatMap(Optional::stream)

    Here method is used convert a Stream of Optional of Employee object into a Stream of Employee so that we can work on this result lazily in the result code.

    To understand more about this feature with more examples and to read more new methods added to Optional class, please go through my original tutorial at: Java SE 9: Optional Class Improvements

  11. Stream API Improvements

    In Java SE 9, Oracle Corp has added four useful new methods to java.util.Stream interface. As Stream is an interface, all those new implemented methods are default methods. Two of them are very important: dropWhile and takeWhile methods

    If you are familiar with Scala Language or any Functions programming language, you will definitely know about these methods. These are very useful methods in writing some functional style code. Let us discuss about takeWhile utility method here.

    This takeWhile() takes a predicate as an argument and returns a Stream of subset of the given Stream values until that Predicate returns false for first time. If first value does NOT satisfy that Predicate, it just returns an empty Stream.

    jshell> Stream.of(1,2,3,4,5,6,7,8,9,10).takeWhile(i -> i < 5 )

    To read more about takeWhile and dropWhile methods and other new methods, please go through my original tutorial at: Java SE 9: Stream API Improvements

  12. Enhanced @Deprecated annotation

    In Java SE 8 and earlier versions, @Deprecated annotation is just a Marker interface without any methods. It is used to mark a Java API that is a class, field, method, interface, constructor, enum etc.

    In Java SE 9, Oracle Corp has enhanced @Deprecated annotation to provide more information about deprecated API and also provide a Tool to analyse an application’s static usage of deprecated APIs. They have add two methods to this Deprecated interface: forRemoval and since to serve this information.

    Read my original tutorial at: Java SE 9: Enhanced @Deprecated annotation to see some useful examples.

  13. HTTP 2 Client

    In Java SE 9, Oracle Corp is going to release New HTTP 2 Client API to support HTTP/2 protocol and WebSocket features. As existing or Legacy HTTP Client API has numerous issues (like supports HTTP/1.1 protocol and does not support HTTP/2 protocol and WebSocket, works only in Blocking mode and lot of performance issues.), they are replacing this HttpURLConnection API with new HTTP client.

    They are going to introduce new HTTP 2 Client API under “” package. It supports both HTTP/1.1 and HTTP/2 protocols. It supports both Synchronous (Blocking Mode) and Asynchronous Modes. It supports Asynchronous Mode using WebSocket API.

    We can see this new API at:

    HTTP 2 Client Example

    jshell> import*
    jshell> import static*
    jshell> import static*
    jshell> URI uri = new URI("")
    uri ==>
    jshell> HttpResponse response = HttpRequest.create(uri).body(noBody()).GET().response()
    response ==>
    jshell> System.out.println("Response was " + response.body(asString()))

    Please go through my original tutorial at: Java SE 9: HTTP 2 Client to understand HTTP/2 protocol & WebSocket, Benefits of new API and Drawbacks of OLD API with some useful examples.

  14. Мulti-Resolution Image API

    In Java SE 9, Oracle Corp is going to introduce a new Мulti-Resolution Image API. Important interface in this API is MultiResolutionImage . It is available in java.awt.image package.

    MultiResolutionImage encapsulates a set of images with different Height and Widths (that is different resolutions) and allows us to query them with our requirements.

    Please go through my original tutorial at: Java SE 9: Мulti-Resolution Image API to understand this new API more with some examples.

  15. Miscellaneous Java 9 Features

    In this section, I will just list out some miscellaneous Java SE 9 New Features. I’m NOT saying these are less important features. They are also important and useful to understand them very well with some useful examples.

    As of now, I did not get enough information about these features. That’s why I am going list them here for brief understanding. I will pickup these Features one by one and add to above section with a brief discussion and example. And final write a separate tutorial later.

    • GC (Garbage Collector) Improvements
    • Stack-Walking API
    • Filter Incoming Serialization Data
    • Deprecate the Applet API
    • Indify String Concatenation
    • Enhanced Method Handles
    • Java Platform Logging API and Service
    • Compact Strings
    • Parser API for Nashorn
    • Javadoc Search
    • HTML5 Javadoc

I will pickup these java 9 features one by one and update them with enough description and examples.

That’s all about java 9 features in brief with examples.

source -

Java용 REPL, JShell 등장 에서 다운로드

불변 Collection 생성 메서드 제공

기존에 guava를 사용해서 생성하던 불변 List, Set, Map, Map.Entry 생성 가능

List immutableList = List.of();
List immutableList = List.of(“one”, “two”, “thress”);
Map immutableMap = Map.of(1, "one", 2, "two");

Java 9 Module System

Jigsaw Project의 특징

  • Modular JDK
  • Modular Java Source Code
  • Modular Run-time Images
  • Encapsulate Java Internal APIs
  • Java Platform Module System

Jigsaw가 주는 이점

  • 편하고 효율적인 Java 개발 환경을 만들기 위해서 시작
  • Jar기반 모노리틱 방식을 개선하여 모듈 지정 및 모듈별 버전 관리 기능이 가능함
  • 필요한 모듈만 구동하여 크기와 성능 최적화가 가능
  • 임베디드와 같은 환경에서 필요한 모듈만 탑재되어 적은 메모리로 로딩이 가능함

간단한 사용법

// Java 코드 최상위에 파일을 만들고, 아래와 같이 사용함
module java.sql {
requires public java.logging;
requires public java.xml;
exports java.sql;
exports javax.sql;
exports javax.transaction.xa;

자세한 사용법은 아래 링크에서 확인

프로세스 API 개선

OS 프로세스 관리 및 컨트롤을 위해서 아래 두개의 패키지가 추가됨


아래와 같이 사용할 수 있음

ProcessHandle self = ProcessHandle.current();
PID = self.getPid();
ProcessHandle.Info procInfo =;
Optional<String[]> args = procInfo.arguments();
Optional<String> cmd = procInfo.commandLine();
Optional<Instant> startTime = procInfo.startInstant();
Optional<Duration> cpuUsage = procInfo.totalCpuDuration();
// Destroying Processes
childProc = ProcessHandle.current().children();
childProc.forEach(procHandle -> {
assertTrue("Could not kill process "
+ procHandle.getPid(), procHandle.destroy());

try-with-resources 개선

void tryWithResourcesByJava7() throws IOException {
BufferedReader reader1 = new BufferedReader(new FileReader("test.txt"));
    try (BufferedReader reader2 = reader1) {
// do something
// final or effectively final이 적용되어 reader 참조를 사용할 수 있음
void tryWithResourcesByJava9() throws IOException {
BufferedReader reader = new BufferedReader(new FileReader("test.txt"));
try (reader) {
// do something

Diamond Operator의 한계를 개선

anonymous inner 클래스에서 diamond operator를 사용할 수 있음

FooClass<Integer> fc = new FooClass<>(1) { 
// anonymous inner class
FooClass<? extends Integer> fc0 = new FooClass<>(1) {
// anonymous inner class
FooClass<?> fc1 = new FooClass<>(1) { 
// anonymous inner class
// 타입 파라메터없이 List만 사용해도 추론이 가능함
public List getPerson(String id) {
return new List(findPersonById(id)){};

Interface Private Method

인터페이스 내에서 private 메서드 사용이 가능해짐

interface NewInterface {

static String staticPrivate() {
"static private";
    private String instancePrivate() {
"instance private";
    default void check() {
String result = staticPrivate();
NewInterface newIf = new NewInterface() {
// anonymous class

result = newIf.instancePrivate();

CompletableFuthre API 개선

// 50초후에 새로운 Executor 생성
Executor executor = CompletableFuture.delayedExecutor(50L, TimeUnit.SECONDS);

Reactive Stream API 추가

Reactive Stream을 구현한 Flow API가 추가됨.


설명은 간단하지만, 필자 생각에는 Java 9의 가장 큰 변화중 하나임.

Optional To Stream

Stream<Optional> person = getPerson(id);
// Optional.stream은 Stream<Optional>을 Stream<Person>으로 바꾸어줌
Stream personStream = person.flatMap(Optional::stream);
// 아래와 같이 Optional로 Stream을 생성할 수 있음. 
Stream<Integer> stream = Optional.of(1).stream();

Stream API 개선

// iterate에 아래와 같이 Predicate을 받을 수 있는 인터페이스 추가
IntStream.iterate(1, i -> i < 100, i -> i + 1)
// 아래 Stream 인터페이스 추가

HTTP2 클라이언트

  • HttpURLConnection를 대체함
  • “jdk.incubator.http” 패키지 추가됨
  • HTTP/1.1 및 HTTP/2 프로토콜 지원
  • 동기/비동기 모드 지원
  • Apache HttpClient, Netty, Jetty와 비교할 수 있는 성능
// 동기 호출
HttpResponse response = HttpRequest
.create(new URI(""))
int responseCode = response.responseCode();
String responseBody = response.body(asString());
// 비동기 호출
HttpRequest request = HttpRequest
.create(new URI(""))
CompletableFuture<HttpResponse> future = request.sendAsync();
if (!future.isDone()) {
HttpResponse response = future.get();

Multi-Resolution Image API

  • java.awt.image.MultiResolutionImage 인터페이스 추가
  • 해상도가 다른 이미지들을 하나의 객체로 캡슐화할 수 있음
  • 요구사항을 통해서 이미지 쿼리 가능

Multi-release JARs

특정 버전에서만 원하는 클래스가 동작하도록 할 수 있음

│ └── versions
│ └── 9
│ └── multirelease
│ └── Helper.class
├── multirelease
├── Helper.class
└── Main.class

여기서 multirelease.jar는 Java 9에서만 META-INF / versions / 9에 있는 Helper.class가 동작되도록 할 수 있다. 이렇게하면 이 Helper.class내에서는 Java 9의 기능을 온전히 활용할 수 있다. 동시에 이전 Java 버전에서 이 JAR를 사용해도 최상위 Helper.class가 사용되기 때문에 Java 버전에 관계없이 동일한 JAR로 호환이 가능하다.

기타 변경 및 개선 사항

  • GC 개선
  • Stack-Walking API
  • Filter Incoming Serialization Data
  • Deprecate the Applet API
  • Indify String Concatenation
  • Enhanced Method Handles
  • Java Platform Logging API and Service
  • Compact Strings
  • Parser API for Nashorn
  • Javadoc에 검색 기능 추가
  • HTML5 Javadoc


source -

'Development > Java' 카테고리의 다른 글

JDK 9 Features  (0) 2018.02.25
javamail - SendFailedException  (0) 2017.04.06
javamail - SMTP BCC  (0) 2017.03.31
java - NIO Selector and epoll  (0) 2017.03.17
java - Architecture of a Highly Scalable NIO-Based Server  (0) 2017.03.17
java - Understanding JUnit's Runner architecture  (0) 2016.07.24
Posted by linuxism

* Case 1

(function(window, $) {

var someVar = true;

var test = {

                some: 'test',

setValue: function() {

                    // some code



window.test = test;

})(window, jQuery);

* Case 2

var test = (function(test, $, undefined) {

    var someVar = true;

    test.some = 'test';

    test.setValue = function() {

        // some code


    return test;

}(window.test || {}, jQuery));

Posted by linuxism