Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "how to master HTTP2 and REPL of Java9". In the operation of actual cases, many people will encounter such a dilemma. Next, let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

HTTP/2

The HTTP/2 standard is the * version of the HTTP protocol. The current version of HTTP/1.1, which began in 1999, has very serious problems, including:

Peer blocking

In HTTP/1.1, the order in which responses are received is the same as the order in which requests are sent. This means that, for example, when viewing a large HTML page that contains many small images, the image resource will have to queue up after the HTML page resource, and the image resource cannot be sent until the browser has fully loaded the HTML page. This is known as "peer blocking" and can lead to many potential page rendering problems.

In HTTP/2, response data can be transmitted by block (chunk) or even cross-transmitted, so the multiplexing of request and response is really realized.

Limit on the number of connections to a site

There is a description in the HTTP/1.1 standard: "A single-user client cannot maintain more than 2 connections to any server." This limitation, along with the problem of peer blocking, severely limits the performance of the page.

HTTP/2 breaks this limitation and believes that the connection is persistent and will be closed only after the user jumps or when a technical failure occurs. The use of multiplexing will help reduce page performance bottlenecks.

Overhead of HTTP control head

The current version of HTTP uses simple, text-based HTTP header information to control communication. The advantage of this is that it is very simple and easy to understand, and debugging is also very simple, simply by connecting to the specified port and typing some text. However, using text-based protocols can cause small response packets to swell disproportionately. In addition, a large number of HTTP responses have little or no payload (for example, HEAD requests are just to determine if resources have changed). For responses that actually contain only * * modification time, using entirely text-based header information (about 700bytes, which cannot be compressed in HTTP1.1, although it's easy to do) is an incredible waste in the current HTTP standard.

Another idea is to use binary encoding for HTTP header information. This approach can greatly improve the speed of smaller requests and take up very little network bandwidth. This is the approach that HTTP/2 has chosen, and although standards set in protocol spirit should choose text-based protocols, there is a compelling reason for binary efficiency to do so.

Expectations brought by HTTP/2

The HTTP/2 standard was created by the IETF HTTP working group, which is made up of representatives and engineers from Mozilla, Google, Microsoft, Apple, and other companies, and is chaired by Mark Nottingham, a senior engineer from Akamai, a leading company in CDN. Therefore, HTTP/2 is a version made to optimize large, high-traffic websites, which ensures performance and network bandwidth consumption on the basis of simple implementation and easy debugging.

The president of the organization summarized some of the key attributes of HTTP/2:

Same HTTP API

Lower cost request

Network and server side friendliness

Cache push

Thinking revolution

More encryption methods

The meaning it brings to Java

Java has supported HTTP since version 1.0, but most of the code comes from a completely different era. For example, Java's support for HTTP is designed around relatively protocol-independent frameworks (URL classes), so this implementation was unclear in the 1990s, when websites became dominant.

Java's support for HTTP is based on the design ideas of the time, but times have changed, and the most important thing is that HTTPS did not appear when Java's original support for HTTP came out. As a result, Java's API uses HTTPS as a kind of flower grafting, resulting in complexity that cannot be simplified.

In modern society, HTTPS begins to become ubiquitous, making HTTP an increasingly backward technology. Even the US government has now approved plans to move entirely to HTTPS-only.

The support of JDK kernel for HTTP has been unable to keep up with the development of real networks. In fact, even JDK8 has only delivered a client that supports HTTP/1.0, however, most developers have already switched to third-party client libraries, such as Apache's HttpComponents.

All this means that support for HTTP/2 will be the core function of Java over the next decade. It also allows us to re-examine our inherent thinking, rewrite a set of API and provide the opportunity to start over. HTTP/2 will be the main API that every developer will face in the next few years.

The new API no longer insists on protocol neutrality, allowing developers to completely abandon the way they used it. This set of API only focuses on the HTTP protocol, but it is important to further understand that HTTP/2 does not fundamentally change the original semantics. Therefore, this set of API is independent of the HTTP protocol and provides support for frame and connection processing in the new protocol.

In the new API, a simple HTTP request can be created and processed as follows:

HttpResponse response = HttpRequest .create (new URI ("http://www.infoq.com")) .body (noBody ()) .get () .send (); int responseCode = response.responseCode (); String responseBody = response.body (asString ()); System.out.println (responseBody))

This API, which conforms to the fluent style / builder model (fluent/builder), is more modern and comfortable for developers than existing legacy systems.

Although the current code base only supports HTTP/1.1, it already includes a new API. This allows developers to use and validate the new API experimentally during the completion of HTTP/2 support.

The relevant code has entered the OpenJDK sandbox warehouse and soon logged into the backbone of JDK 9. At that point, the new API will begin to be automatically built into the binary beta version of Oracle. Support for HTTP/2 is now available and will be finalized in the coming months.

In the meantime, you can use Mercurial to move out the source code and compile your relocation code according to the AdoptOpenJDK build instructions, so you can use the new API experimentally.

* * one of the batch completion features is asynchronous API that is out of reach of the current version. This feature allows long-running requests to be switched to background threads managed by VM through the sendAsync () method:

HttpRequest req = HttpRequest .create (new URI ("http://www.infoq.com")) .body (noBody ()) .get (); CompletableFuture aResp = req.sendAsync (); Thread.sleep (10); if (! aResp.isDone ()) {aResp.cancel (true); System.out.println (" Failed to reply quickly... "); return;} HttpResponse response = aResp.get ()

Compared with the implementation of HTTP/1.1, the new API brings developers the most convenience, because HTTP/1.1 does not provide a cancellation mechanism for requests that have been sent to the server, while HTTP/2 allows the client to send cancellation commands to requests that have been processed by the server.

JShell

Many languages provide an interactive environment for exploratory development. In some cases (especially Clojure and other Lisp dialects), the interactive environment takes up most, if not all, of the developer's coding time. REPL is also widely used in other languages, such as Scala or JRuby.

Of course, Java has released the Beanshell scripting language before, but it has not been fully standardized, and the project has been inactive in recent years. The introduction of the Nashorn Javascript implementation in Java 8 (and jjs REPL) opens the door to wider consideration of REPL and makes interactive development possible.

An effort to introduce modern REPL into Java 9, starting with JEP 222, is included in OpenJDK's Kulla project. The name Kulla comes from ancient Babylonian mythology and is the god of construction. The purpose of the project is to provide a "complete Java" experience at the nearest distance. The project does not introduce new non-Java semantics and disables semantics in the Java language that are not useful for interactive development (such as upper-level access control modifications or synchronization semantics).

Like all REPL, JShell provides a command line rather than an IDE-like experience. Statements and expressions can be evaluated immediately in the context of the execution state, rather than having to be packaged into a class. Methods are also free-floating and do not have to belong to a particular class. Instead, JShell uses the code snippet "snippets" to provide the upper execution environment.

Like HTTP/2 API, JShell is already developing independent projects to avoid affecting the stability of backbone builds during a period of rapid development. JShell is expected to merge into the backbone during August 2015.

Developers can now refer to the AdoptOpenJDK instructions and build Kulla from scratch (the source code is available from the Mercurial address).

For some hands-on experiments, it may be easiest to use a separate experimental jar. These jar packages are built by the community for developers who don't want to build from scratch.

These experimental jar packages are available from AdoptOpenJDK CloudBees's CI build example.

To use them, you need to install the Java 9 beta version (or the built version of OpenJDK 9). Then download the jar file, rename it to kulla.jar, and enter the following on the command line:

$java-jar kulla.jar | Welcome to JShell-- Version 0.610 | Type / help for help->

This is the standard interface for REPL, and as usual, commands start with a single character and end up being issued.

JShell has a fairly complete (but still evolving) help syntax, which is easily available with the following command:

/ help Type a Java language expression, statement, or declaration. Or type one of the following commands: / l or / list [all]-- list the source you have typed / seteditor-- set the external editor command to use / e or / edit-- edit a source entry referenced by name or id / d or / drop-- delete a source entry referenced by name or id / s or / save [all | history]-- save the source you have typed / o or / open Open a file as source input / v or / vars-- list the declared variables and their values / m or / methods-- list the declared methods and their signatures / c or / classes-- list the declared classes / x or / exit-- exit the REPL / r or / reset-- reset everything in the REPL / for / feedback-- feedback information: off Concise, normal, verbose, default, or? / p or / prompt-toggle display of a prompt / cp or / classpath-add a path to the classpath / h or / history-history of what you have typed / setstart-read file and set as the new start-up definitions / savestart-save the default start-up definitions to the file /? Or / help-- this help message /!-- re-run last snippet /-- re-run n-th snippet /-re-run n-th previous snippet Supported shortcuts include:-- show possible completions for the current text Shift- for current method or constructor invocation Show a synopsis of the method/constructor

JShell supports automatic completion of the TAB key, so we can easily find println () or any other method we want to use:

-> System.out.print

Print (printf (println)

Traditional expressions are also easy to evaluate, but Java's statically typed features are a little more stringent than other dynamically typed languages. JShell automatically creates temporary variables to hold the value of the expression and ensures that they remain in the context field for later use:

-> 3 * (4 + 5)

| | Expression value is: 27 |

| | assigned to temporary variable $1 of type int |

-> System.out.println (. 1)

twenty-seven

We can also use the / list command to view all the source code entered so far:

-> / list 9: 3 * (4 + 5) 10: System.out.println ($1)

Use the / vars command to display all variables (both explicit and temporary) and the values they currently hold:

-> String s = "Dydh da" | Added variable s of type String with initial value "Dydh da"-> / vars | int $1 = 27 | String s = "Dydh da"

In addition to supporting simple lines of code, REPL allows you to create classes and other user-defined types very easily. For example, you can create a class with a short line like this (note that opening and closing parentheses are required):

-> String s = "Dydh da" | Added variable s of type String with initial value "Dydh da"-> / vars | int $1 = 27 | String s = "Dydh da"

The very concise, free-floating nature of the JShell code means that we can easily use REPL to demonstrate the functionality of the Java language. For example, let's look at the famous type problem, the covariant problem of Java arrays:

-> Pet [] pets = new Pet [1] | Added variable pets of type Pet [] with initial value [LPet;@2be94b0f-> Cat [] cats = new Cat [1] | Added variable cats of type Cat [] with initial value [LCat;@3ac42916-> pets = cats | Variable pets has been assigned the value [LCat;@3ac42916-> pets [0] = new Pet () | java.lang.ArrayStoreException thrown: REPL.$REPL13 $Pet | at (# 20:1)

Such capabilities make JShell a great teaching or research tool and closest to the Scala REPL experience. With the / classpath switch, additional jar packages can be loaded so that interactive exploratory API can be used directly in REPL.

Participate in

Major IDE has begun to provide builds that support earlier versions of JDK 9-- including Netbeans and Eclipse Mars. IntelliJ 14.1 is said to support JDK9, but it is not clear how much support for the new modular JDK extension.

So far, these IDE do not support HTTP/2 and JShell, because these features have not yet landed on the backbone of OpenJDK, but developers should expect them to appear in the standard JDK beta version as soon as possible, and there are IDE plug-ins to follow. These API are still under development, and the project is actively seeking end-user use and participation.

The JDK 9 Outreach programme is also underway to encourage developers to test their code and applications on JDK 9 before it arrives. HTTP/2 & JShell aren't the only new features being worked on-other new JDK 9 functionality under development as JEPs includes

The JDK 9 campaign is also encouraging developers to test their code and run applications on JDK 9. The new features under development include not only HTTP/2 and JShell--, but also other new features being developed as JEP,JDK 9:

Update of 102Process API (Process API Updates)

Compiler Control (Compiler Control)

227 Unicode 7.0

245 verify the virtual machine line tag parameter (Validate JVM Command-Line Flag Arguments)

248: G1 as the default garbage collector (Make G1 the Default Garbage Collector)

Series of updates for TLS (TLS Updates) (JEP 219,244249)

A complete list of all JEP currently under consideration (and which Java version should be placed) can be found here.

This is the end of the content of "how to master HTTP2 and REPL of Java9". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.