Download a PDF of this article
Networking capabilities were built into Java’s core libraries right from the start. For developers, the fact that networking was built into a major development platform was a welcome change, because organizations didn’t have to rely on third-party libraries or invest resources to create their own low-level networking code to support common networking protocols.
Of course, in the 1990s, not every application needed networking—but now networking support is an absolute requirement for nearly all platforms. Indeed, most of today’s most popular business and consumer applications wouldn’t exist without the ability to connect to services using the HTTP protocol.
That said, Java’s very widely used HTTP Client API hadn’t seen a significant improvement until the new API started to incubate in JDK 9 as JEP 110 and was made standard in JDK 11 as JEP 321.
David Delabassée, a developer advocate in the Java Platform Group at Oracle, recently spoke with Oracle Java architects Daniel Fuchs and Michael McMahon to discuss some of the recent network updates to the Java platform. Here are a few of the highlights from that conversation.
Delabassée: Why was the new Java HTTP Client API introduced?
McMahon: The original, 25-year-old Java HTTP Client API is old and has limitations. It was hard to use and hard to maintain. Part of the API supported protocols that aren’t used anymore, such as Gopher, which adds to complexity.
Plus, the old client is blocking and ties up a thread for the entire duration of a request, regardless of how long that is going to take. In addition, the old client was for the HTTP/1.1 protocol and needed to evolve to support the newer HTTP/2 protocol.
Fuchs: The new HTTP Client API started to incubate in JDK 9 and was later made standard and permanent in JDK 11. It supports both HTTP/1.1 and HTTP/2, supports WebSockets, and improves security. More importantly, the new client is modern and easy to use. For example, it uses the popular Builder pattern.
Delabassee: How does the new client work?
Fuchs: To send a request, you first need to create an HTTP client; there is a builder for that. Using a builder, you create a client instance and configure its state. For example, you can specify which protocol to use (such as HTTP/1.1 or HTTP/2) and whether to follow redirects. You also can set the proxy selector, set the necessary contexts for Transport Layer Security (TLS), and so on.
Once built, your HTTP client can be used to send multiple requests and is immutable. Requests can be sent multiple times, and you can choose whether they are sent synchronously or asynchronously.
Delabassée: Moving beyond the HTTP Client API, UNIX-domain socket channels were added to Java 16. What can you tell us about that?
McMahon: UNIX-domain sockets are like TCP/IP sockets, except that these sockets are used only for local interprocess communication (IPC), and they are addressed through file system pathnames, rather than through an IP address and port number.
UNIX-domain socket channels, which appeared in JEP 380, offer several benefits for applications that need to do only local IPC or IPC between containers. Performance is one benefit: By cutting out the TCP/IP stack, you can improve throughput and lower CPU utilization. These sockets can also improve security because if you need only local IPC, you don’t need to open ports to the network.
With UNIX-domain sockets, you can also make use of file system access controls and user credentials for additional security. When testing them with Docker, we found that UNIX-domain sockets make it easier to set up communication between containers.
To make all this work, JEP 380 added the following API elements:
◉ A new socket address class, java.net.UnixDomainSocketAddress
◉ A UNIX constant value in the existing java.net.StandardProtocolFamily enum
◉ New open factory methods on SocketChannel and ServerSocketChannel that specify the protocol family
◉ Updates to the SocketChannel and ServerSocketChannel specifications to allow you to define how the channels to the UNIX-domain sockets behave
It should also be mentioned that despite the name, UNIX-domain sockets are also available on Windows!
Delabassée: Typically, with a network connection, security is enforced at the network level, such as by using firewalls and reverse proxies. How can security be enforced with UNIX-domain sockets?
McMahon: One level of security is the old Java platform security model. For that, there’s a single permission, which enables or disables the feature if a security manager is running.
Beyond that, the main way you get security is through the operating system, its user and groups, and its file permissions, where you can restrict access to file system nodes through user IDs and group IDs.
An additional useful feature, which works on the UNIX platform but not on Windows, is via testing user credentials. If a client socket channel is connected to a server socket channel, either side can request the identity of the user at the opposite side.
Delabassée: There is a new simple web server and API targeted for Java 18. Can you give us a quick overview?
McMahon: JEP 408 will deliver a simple web server to serve static content. JEP 408 includes an API for programmatic creation and customization of the server and its components.
As its name implies, the Simple Web Server’s design is explicitly minimal. It is intended for development purposes, as well as for testing and educational use, but it is certainly not a full-featured server that you should use in production! For example, it doesn’t offer security features.
The Simple Web Server is based on the web server implementation in the com.sun.net.httpserver package that has been included in the JDK since 2006. That package is officially supported, and it’s extended with APIs to simplify server creation and enhance request handling. The Simple Web Server can be used via the dedicated command-line tool jwebserver or programmatically via its API.
To reiterate, the Simple Web Server is intended for educational, development testing, and debugging purposes only.
Delabassee: Any final thoughts about the new networking capabilities?
Fuchs: We discussed the HTTP Client API, UNIX-domain socket channels, and the Simple Web Server. Those features are quite visible because developers can use them directly. In parallel to those features, the Java teams continue to work on the platform itself, such as on some features that are not so visible but nevertheless are strategic going forward.
For example, slowly but surely Project Loom is coming—and so we are looking at making sure that our networking implementation will play nice with virtual threads. That was the motivation for JEP 353, which reimplements the legacy Socket API, and JEP 373, which reimplements the legacy DatagramSocket API.
Source: oracle.com
Posts
0 comments:
Post a Comment