JEP proposed to target JDK 18: 408: Simple Web Server

Joe Darcy joe.darcy at
Mon Oct 11 21:54:33 UTC 2021

On 10/11/2021 1:10 PM, Simone Bordet wrote:
> Hi,
> On Mon, Oct 11, 2021 at 7:18 PM Julia Boes <julia.boes at> wrote:
>> Hi Simone,
>> On 09/10/2021 17:32, Simone Bordet wrote:> As a Jetty Project co-lead, and
>> having witnessed:
>>> * the number of perils in URL parsing
>>> * the number of perils in URL decoding
>>> * the number of perils in URL to file-system Path conversions, which
>>> are file-system/os dependent
>>> * the number of perils in file-system aliasing, also file-system/os dependent
>>> I really wonder if this JEP is going to be an OpenJDK liability, also
>> Let me start by saying that this JEP does not add new functionality, but rather
>> exposes existing implementations. The Simple Web Server is located in
>> jdk.httpserver/, a package that has been there since 2006
>> (JDK 1.6) and that is officially supported.
> Sorry, but considering that truly official java.* APIs are being
> removed, I fail to understand how classes in jdk.* or com.sun.* are
> "officially supported", when it was made very clear that developers
> should not depend on those because they can change without any advice,
> etc.
> Can you clarify what you mean here?

There are distinct evolution and compatibility policies for several 
categories of APIs associated with the JDK, several broad buckets:

* Java SE APIs (approximately public and protected elements of the 
java.* modules, which include the java.* and javax.* packages): These 
APIs have a strong compatibility policy, but can be removed from the 
platform after going through the deprecation-for-removal process.

* official JDK APIs (approximately public and protected elements of the 
jdk.* modules): similar compatibility policy to Java SE APIs, but there 
is more leeway on the timing and size of changes. For example, it is 
more likely to have API changes to JDK APIs in an update release (rather 
than a feature release) compared to changes in Java SE APIs (since 
changing a Java SE in a maintenance release would require a maintenance 
review of the platform specification).

One example of an official JDK API is the tree api, com.sun.source.tree, 
which is in part a supplement of sorts to the javax.lang.model Java SE API.

* unofficial / accidental JDK APIs: Going back multiple decades 
and continuing to today 
(, the 
sun.* APIs are *not* part of the JDK's official API and should *not* be 
relied on by code outside of the JDK. In early years, this policy lacked 
enforcement mechanisms. Start in JDK 6, javac started warning about uses 
of such classes and modularity in JDK 9 added further mechanisms. 
Selected portions of sun.*, in particular sun.misc.Unsafe, do get 
special handling.

To emphasize, APIs in a sun.* namespace are regarded differently than 
either APIs in a com.sun.* or jdk.* namespace or a java.* or java.* 

Changes to Java SE APIs and JDK API go through the CSR process 
( which provides compatibility 
and specification review.



More information about the jdk-dev mailing list