Jetty 10 and 11 Have Arrived!

The Eclipse Jetty team is proud to announce the release of Jetty 10 and Jetty 11! Let’s first get into the details of Jetty 10, which includes a huge amount of enhancements and upgrades. A summary of the changes follows.

Minimum Java Version

The minimum required Java version for Jetty 10 is now Java 11.
As new versions of the OpenJDK are released, Jetty is tested for compatibility and is at this point compatible with versions up to Java 15.

WebSocket Refactor

• Major refactor of Jetty WebSocket code. The Jetty WebSocket core API now provides the RFC6455 protocol implementation. The Jetty and Javax WebSocket APIs are separate layers which use the new WebSocket core implementation. 
• Support for RFC8441 WebSocket over HTTP/2 on both WebSocket client and WebSocket server. This allows a HTTP/2 stream to be upgraded to a WebSocket connection allowing the single TCP connection to be shared by both HTTP/2 and WebSocket protocols.
• Various improvements and cleanups to the Jetty WebSocket API.

Self Ordering Webapp Configurations.

• The new WebAppContext Configuration API, useful for embedded Jetty users, have been made simpler to use.
• The available Configurations are discovered with the ServiceLoader, so that often all that is required is to add a feature jar onto the server classpath for that feature to be applied to all web applications.
• Configurations are self ordering using before/after dependencies defined in the Configurations themselves. This removes the need to explicitly order Configurations or to use add-after style semantics.
• A Configuration now includes the ability to condition the Webapp classloader so that classes/packages on the server class loader can be explicitly hidden, protected and/or exposed to the Webapp classloader.

HTTP Session Refactor

The HTTP session storage integrations were refactored to be consistent. Previously, the various integrations discovered expired sessions in different ways and with different thresholds for expiry. The refactoring applies the same uniform criteria for expiry no matter the persistence technology used. Some of the configuration properties have changed as a result of the refactoring.

New XML DTD

The Jetty XML files now validate against the new configure_10_0.dtd.  We encourage moving to the new DTD.

Jetty Distribution Change

There is no longer a jetty-distribution artifact, use the equivalent jetty-home artifact.
The $JETTY_BASE mechanism has not changed.  Upgrades should be mostly transparent, only custom XML in your $JETTY_BASE and logging require migration.

Jetty-Quickstart Just Got Easier to Use

In Jetty 10 it is easier to use the jetty-quickstart mechanism to improve the start-up time of webapps. Previously it was necessary to enable the quickstart module and also create a special context xml file for your webapp and explicitly apply some configuration. With Jetty 10 you no longer need the special context xml file: you simply enable the quickstart module, and then edit the generated start.d/quickstart.ini file to either force generation or use a pre-generated quickstart file.

Expanded JPMS Support

Jetty 10 is now fully JPMS compliant with proper JPMS modules and module-info.class files, improving over Jetty 9.4.x where only the Automatic-Module-Name was defined for each artifact.
This allows other libraries to leverage Jetty JPMS modules properly, and use jlink to create custom images that embed Jetty.

HTTP Client

HttpClient has undergone a number of changes, in particular:

• An improved API for setting request and response headers, based on the new HttpFields and HttpField.Mutable APIs.
• An improved API for setting request content, based on a reactive model where the demand of content and buffer recycling can now be performed separately. This allows applications to provide request content implementations in a much simpler way, without the need to know HttpClient implementation details.
• The introduction of ClientConnector, a reusable component that manages the connections opened by HttpClient that can now be shared with HTTP2Client, and that centralizes the configuration of other components such as the Executor, the Scheduler, the SslContextFactory, and the TCP properties.
• The introduction of a dynamic HttpClientTransport that allows switching, for example, from HTTP/1.1 to HTTP/2 after negotiation with the server. This allows us to write web spiders or proxies that can prefer HTTP/2 but fall back to HTTP/1.1 if the server does not support HTTP/2.
• Support for tunneling WebSocket over HTTP/2 (this feature is primarily used by the WebSocketClient – for the application it should be transparent)
• Support for the PROXY protocol so that proxy applications that use HttpClient can use the PROXY protocol and forward client TCP data (and metadata when using PROXY v2) to the server.

Logging

Jetty 9 and earlier had its own Logging Facade.
Starting with Jetty 10, that custom facade has been completely replaced by SLF4J 2.0 API usage. You can use any logging implementation you want with Jetty, as long as there is an SLF4J 2.x implementation available for it.
The entire org.eclipse.jetty.util.log package has seen large changes in Jetty 10.

• org.eclipse.jetty.util.log.Log is deprecated and all methods just delegate to SLF4J.
• org.eclipse.jetty.util.log.Logger is deprecated and is not used.
• No other classes from Jetty 9 exist in this package.

In Jetty 10, there is also a new optional SLF4J implementation provided by Jetty in the form of (jetty-slf4j-impl) which performs the same functionality as the old StdErrLog from Jetty 9 and earlier, with support for configuring logging levels via the jetty-logging.properties classpath resource.
The format of the jetty-logging.properties file is almost identical to what it was before.
The following properties have been removed (and cause no changes in the configuration and no warnings or errors in Jetty 10 forward)

• org.eclipse.jetty.util.log.class=<classname>
  • This has no property replacement, correct SLF4J jar file usage is how you configure this.
• org.eclipse.jetty.util.log.IGNORED=<boolean>
  • There is no replacement for “IGNORED” logging level.
• org.eclipse.jetty.util.log.announce=<boolean>
  • Logging announcement is not a feature of Jetty but could be part of the logging implementation you choose, configuring this would be in the logging implementation you choose.
• org.eclipse.jetty.util.log.SOURCE=<boolean>
• org.eclipse.jetty.util.log.stderr.SOURCE=<boolean>
  • Source logging is a possible feature of the specific SLF4J implementation you choose,  check their documentation.

There are new properties as well:

• org.eclipse.jetty.logging.appender.NAME_CONDENSE=<boolean>
  • This was the old org.eclipse.jetty.util.log.stderr.LONG which controlled the output of the logger name.  (true means the package name are condensed in the output, false means the fully qualified class name is used in output) – defaults to true
• org.eclipse.jetty.logging.appender.THREAD_PADDING=<int>
  • This was the old org.eclipse.jetty.util.log.StdErrLog.TAG_PAD for aligning all messages to a common offset from the start of the log line. – defaults to -1
• org.eclipse.jetty.logging.appender.MESSAGE_ESCAPE=<boolean>
  • This was the old org.eclipse.jetty.util.log.stderr.ESCAPE for turning on/off the escaping of control characters found in the message text. – defaults to true
• org.eclipse.jetty.logging.appender.ZONE_ID=<timezone-id>
  • This defaults to java.util.TimeZone.getDefault() and is present to allow setting the output timestamp in the desired timezone.

Jetty 11

When Oracle donated the JavaEE project to the Eclipse foundation, they maintained the copyright to the javax.* namespace. Subsequently, future versions of JavaEE, now called JakartaEE, would be required to use a new namespace for those packages. Instead of an incremental process, the Eclipse foundation opted for a big bang approach and packages formerly under the javax.* namespace has been refactored under the new jakarta.* namespace.
Enter Jetty 11. Jetty 11 is identical to Jetty 10 except that the javax.* packages now conform to the new jakarta.* namespace. Jetty 10 and 11 will remain in lockstep with each other for releases, meaning all new features or bug fixes in one version will be available in the other.
It is important to note that Jetty 10.x will be the last major Jetty version to support the javax.* namespace. If this is alarming, be assured that Jetty 10 will be supported for a number of years to come. We have no plans on releasing it only to drop support for it in 12-18 months.