JEP proposed to target JDK 18: 408: Simple Web Server
Joe Darcy
joe.darcy at oracle.com
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 oracle.com> 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/com.sun.net.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
(https://web.archive.org/web/19980215011039/http://java.sun.com/products/jdk/faq/faq-sun-packages.html)
and continuing to today
(https://www.oracle.com/java/technologies/faq-sun-packages.html), 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.*
namespace.
Changes to Java SE APIs and JDK API go through the CSR process
(https://wiki.openjdk.java.net/display/csr) which provides compatibility
and specification review.
HTH,
-Joe
More information about the jdk-dev
mailing list