JDK 12 patrol: Another JEP proposed to target JDK 12

Share
  • November 5, 2018
Technology

A new era began with the release of JDK 10. Lat month, we moved on even further with the release of Java SE 11 (JDK 11), the first LTS release in Oracle’s new six-month cycle.

You can download Java 11 here.

That being said, JDK 12 is not set up for release yet, but the development repositories are open for bug fixes, small enhancements, and JEPs so it is time for a new thread to keep track of everything that goes live.

And since JDK 11 featured 3 JEP contributions from the community (the largest number of community contributions to a release so far) let’s keep up the pace!

Proposed to target JDK 12

Summary: Add a basic suite of microbenchmarks to the JDK source code, and make it easy for developers to run existing microbenchmarks and create new ones.

Goals:

  • Based on the [Java Microbenchmark Harness (JMH)][1]
  • Stable and tuned benchmarks, targeted for continuous performance testing
    • A stable and non-moving suite after the Feature Complete milestone of a feature release, and for non-feature releases
    • Support comparison to previous JDK releases for applicable tests
  • Simplicity
    • Easy to add new benchmarks
    • Easy to update tests as APIs and options change, are deprecated, or are removed during development
    • Easy to build
    • Easy to find and run a benchmark
  • Support JMH updates
  • Include an initial set of around a hundred benchmarks in the suite

 

Update October 11, 2018

Today we add two more JEPs to the targeted to JDK 12 list and we see the implementation of JEP 341 been pushed into jdk/jdk repository.

Let’s have a closer look.

Targeted to JDK 12

JEP 325: Switch Expressions (Preview)

Summary: Extend the switch statement so that it can be used as either a statement or an expression, and that both forms can use either a “traditional” or “simplified” scoping and control flow behavior. These changes will simplify everyday coding, and also prepare the way for the use of pattern matching (JEP 305) in switch. This will be a preview language feature.

Motivation: As we prepare to enhance the Java programming language to support pattern matching (JEP 305), several irregularities of the existing switch statement — which have long been an irritation to users — become impediments. These include the default control flow behavior (fall through) of switch blocks, the default scoping of switch blocks (the block is treated as one single scope) and that switch works only as a statement, even though it is commonly more natural to express multi-way conditionals as expressions.

The current design of Java’s switch statement follows closely languages such as C and C++, and supports fall-through semantics by default. Whilst this traditional control flow is often useful for writing low-level code (such as parsers for binary encodings), as switch is used in higher-level contexts, its error-prone nature starts to outweigh its flexibility. We propose to introduce a new form of switch label, written “case L ->” to signify that only the code to the right of the label is to be executed if the label is matched.

JEP 326: Raw String Literals (Preview)

Summary: Add raw string literals to the Java programming language. A raw string literal can span multiple lines of source code and does not interpret escape sequences, such as n, or Unicode escapes, of the form uXXXX. This will be a preview language feature.

Goals

  • Make it easier for developers to
    • express sequences of characters in a readable form, free of Java indicators,
    • supply strings targeted for grammars other than Java, and
    • supply strings that span several lines of source without supplying special indicators for new lines.
  • Raw string literals should be able to express the same strings as traditional string literals, except for platform-specific line terminators.
  • Include library support to replicate the current javac string-literal interpretation of escapes and manage left-margin trimming.

Non-Goals

  • Do not introduce any new String operators.
  • Raw string literals do not directly support string interpolation. Interpolation may be considered in a future JEP.
  • No change in the interpretation of traditional string literals in any way, including:
    • multi-line capability,
    • customization of delimiters with repeating open and close double-quotes, and
    • handling of escape sequences.

In addition to JEPs 325 and 326 being targeted to JDK 12, the implementation of JEP 341 has been pushed into jdk/jdk repository.

 

Update  

Targeted to JDK 12

JEP 340: One AArch64 Port, Not Two

Summary: Remove all of the sources related to the arm64 port while retaining the 32-bit ARM port and the 64-bit aarch64 port.

Tasks to be completed as part of this JEP:

  • Remove all arm64-specific sources and #ifdefs related to 64-bit versus 32-bit builds in open/src/hotspot/cpu/arm
  • Scan the remaining JDK sources for #ifdefs related to this port
  • Remove the build option for building this port. Make the aarch64 port the default build for the 64-bit ARM architecture.
  • Validate that the remaining 32-bit ARM port continues to build and run the conformance tests with no regressions that did not exist prior to the changes related to this JEP.

JEP 341: Default CDS Archives

Summary: Enhance the JDK build process to generate a class data-sharing (CDS) archive, using the default class list, on 64-bit platforms.

Goals

  • Improve out-of-the-box startup time
  • Eliminate the need for users to run -Xshare:dump to benefit from CDS

Non-Goals

  • We will generate the default archive only for native builds, not for cross-compiled builds.
  • We will generate the default archive only for 64-bit builds; support for 32-bit builds may be added later.

JEP drafts

JEP draft: Support ByteBuffer mapped over non-volatile memory

Summary: Allow MappedByteBuffers to be mapped over non-volatile memory with writes committed via an efficient cache line flush.

JEP draft: Implement C++14 Language Features

Summary: Introduce C++14 compliant language features into HotSpot C++ source code.

 

Update September 17, 2018

JEP candidates

JEP 340: One AArch64 Port, Not Two

Summary: Remove all of the sources related to the arm64 port while retaining the 32-bit ARM port and the 64-bit aarch64 port.

JEP 341: Default CDS Archives

Summary: Enhance the JDK build process to generate a class data-sharing (CDS) archive, using the default class list, on 64-bit platforms.

JEP 342: Limit Speculative Execution

Summary: Help developers and deployers defend against speculative-execution (“Spectre”) vulnerabilities by providing a means to limit speculative execution, and enable further mitigations to be implemented in future releases.

JEP 343: Packaging Tool

Summary: Create a new tool for packaging self-contained Java applications. The jpackager tool will take as input a Java application and a Java run-time image, and produce a Java application image that includes all the necessary dependencies.

 

Update September 5, 2018

Proposed to target

Granted, two features may not seem like much but we’re just getting started!

JEP 325: Switch Expressions (Preview)

Summary: Extend the switch statement so that it can be used as either a statement or an expression, and that both forms can use either a “traditional” or “simplified” scoping and control flow behavior. These changes will simplify everyday coding, and also prepare the way for the use of pattern matching (JEP 305) in switch. This will be a preview language feature.

SEE ALSO: “Developers will see Java 11 as a better, cleaner implementation of the features they use in Java 8”

JEP 326: Raw String Literals (Preview)

Summary: Add raw string literals to the Java programming language. A raw string literal can span multiple lines of source code and does not interpret escape sequences, such as n, or Unicode escapes, of the form uXXXX. This will be a preview language feature.

While we are on the JDK 12 topic, don’t miss our interview series about Project Skara. What do you think is the most beneficial alternative SCM and code review for the JDK source code? Check out what the experts had to say.

The results of the JAXenter poll seem to be pretty clear. Git wins. That’s it. No further explanation needed.

On the other hand, the three interviews we had with Java experts paint a not-so-crystal-clear picture. Let me explain.

In the first interview, we talked to Java Champion and JavaOne Rock Star speaker Stephen Colebourne, who seems to be rather enthusiastic about the prospect of migrating JDK source code management to Git.

From my perspective, I think using Git instead of Mercurial is a great idea. I can’t see any case to move to any other SCM.

Stephen Colebourne

However, for our second interview, we caught up with OpenJDK Author Patrick Reinhart who based his view mostly on the popularity of Git as opposed to Mercurial.

For new contributors, Git seems to be more tool-friendly than Mercurial is at the moment.

Patrick Reinhart

For our last interview, that went online just yesterday, we talked to OpenJDK committer Thomas Stüfe, who seems to have a rather conservative opinion on the matter.

 I see no pressing technical reasons to switch to Git. I work with both SCMs and to me, none has a clear lead in performance or functionality.

Thomas Stüfe

See all the interviews here: 

zgqwzg

    DevOpsCon Whitepaper 2018

    Free: BRAND NEW DevOps Whitepaper 2018

    Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Michiel Rook, Christoph Engelbert, Scott Sanders and many more.

    Download whitepaper for free

uzqwg

The post JDK 12 patrol: Another JEP proposed to target JDK 12 appeared first on JAXenter.

Source : JAXenter

You may also like...