New candidate JEP: 408: Simple Web Server

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

New candidate JEP: 408: Simple Web Server

mark.reinhold
https://openjdk.java.net/jeps/408

  Summary: Provide a command-line tool to start a minimal web server
  that serves static files in the current directory. This low-threshold
  utility will be useful for prototyping, ad-hoc coding, and testing
  purposes, particularly in educational contexts.

- Mark
Reply | Threaded
Open this post in threaded view
|

Re: New candidate JEP: 408: Simple Web Server

Remi Forax
----- Mail original -----
> De: "mark reinhold" <[hidden email]>
> À: "Julia Boes" <[hidden email]>
> Cc: [hidden email], "jdk-dev" <[hidden email]>
> Envoyé: Lundi 29 Mars 2021 21:16:06
> Objet: New candidate JEP: 408: Simple Web Server

> https://openjdk.java.net/jeps/408
>
>  Summary: Provide a command-line tool to start a minimal web server
>  that serves static files in the current directory. This low-threshold
>  utility will be useful for prototyping, ad-hoc coding, and testing
>  purposes, particularly in educational contexts.


big +1,

For teaching purpose, i'm currently using a thin wrapper with an API close to expressjs [1] on top of com.sun.net.httpserver.HttpServer.
 
>
> - Mark

Rémi

[1] https://github.com/forax/jexpress
Reply | Threaded
Open this post in threaded view
|

Re: New candidate JEP: 408: Simple Web Server

Krzysztof K.
In reply to this post by mark.reinhold
Hi,
Is there a plan to change the package name?
I always thought that com.sun.* package was for old internal code and I assume I'm not the only one.

Regards,
Krzysztof Krason

On Mon, Mar 29, 2021 at 9:16 PM <[hidden email]> wrote:
https://openjdk.java.net/jeps/408

  Summary: Provide a command-line tool to start a minimal web server
  that serves static files in the current directory. This low-threshold
  utility will be useful for prototyping, ad-hoc coding, and testing
  purposes, particularly in educational contexts.

- Mark


--
Krzysztof Krason
Reply | Threaded
Open this post in threaded view
|

Re: Re: New candidate JEP: 408: Simple Web Server

Julia Boes

Hi Krzysztof,

 

Is there a plan to change the package name?

I always thought that com.sun.* package was for old internal code and I assume I'm not the only one.

 

the simple server builds on the existing API in the com.sun.net.httpserver package, which was added in JDK 1.6. At that time, the convention for JDK-specific APIs was to use the com.sun namespace. Other examples are com.sun.nio.sctp or com.sun.security.ntlm. In more recent times, this convention has been replaced with the jdk namespace. Both name spaces are JDK-specific, as such the simple server API is a supported JDK API.

 

Given that we're simply building on top of the long-standing API in com.sun.net.httpserver, revisiting the package name is out of the scope of this project.

 

Regards,

Julia

Reply | Threaded
Open this post in threaded view
|

Re: New candidate JEP: 408: Simple Web Server

Alex Buckley-3
In reply to this post by Krzysztof K.
Further to Julia's comments:

All of the com.sun namespace is JDK-specific -- it's not part of the
Java SE Platform API.

Around 90% of the com.sun namespace is internal to the JDK -- not
intended for use outside the JDK. An example is the
com.sun.security.ntlm package in the java.base module.

Around 10% of the com.sun namespace is supported for use outside the
JDK. Examples of supported com.sun APIs include:

- The Compiler Tree API (four com.sun packages exported by the
jdk.compiler module)
- The HTTP Server API (two com.sun packages exported by the
jdk.httpserver module)
- The SCTP API (the com.sun.nio.sctp package exported by the jdk.sctp
module)
- JDK-specific extensions to the NIO API (the com.sun.nio.file package
exported by the jdk.unsupported module)

You can view a list of the internal com.sun packages and the supported
com.sun packages at
https://cr.openjdk.java.net/~mr/jigsaw/jdk8-packages-strongly-encapsulated

To aid migration, all of the com.sun packages were open for reflection
_by default_ in JDK 9 through 15. Things were tightened up in JDK 16,
and from JDK 17 you will need to use `--add-opens` if your application
or library code wants to reflect over a com.sun package. You will still
be able to program directly against the _supported_ com.sun packages,
such as the HTTP Server API.

Finally, a related point:  The sun.misc package has been exported and
available for reflection since JDK 9. It was neither removed nor
strongly encapsulated in JDK 9. It was available in JDK 9, and continues
to be available in JDK 17.

Alex

On 3/29/2021 10:51 PM, Krzysztof K. wrote:

> Hi,
> Is there a plan to change the package name?
> I always thought that com.sun.* package was for old internal code and I
> assume I'm not the only one.
>
> Regards,
> Krzysztof Krason
>
> On Mon, Mar 29, 2021 at 9:16 PM <[hidden email]> wrote:
>
>> https://openjdk.java.net/jeps/408
>>
>>    Summary: Provide a command-line tool to start a minimal web server
>>    that serves static files in the current directory. This low-threshold
>>    utility will be useful for prototyping, ad-hoc coding, and testing
>>    purposes, particularly in educational contexts.
>>
>> - Mark
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Re: New candidate JEP: 408: Simple Web Server

Zheka Kozlov
In reply to this post by Julia Boes
Can we put at least new classes to some java.* package (SimpleFileServer, HttpHandlers, Request)? For example, java.net.httpserver.

вт, 30 мар. 2021 г. в 20:14, Julia Boes <[hidden email]>:
Hi Krzysztof,

Is there a plan to change the package name?
I always thought that com.sun.* package was for old internal code and I assume I'm not the only one.

the simple server builds on the existing API in the com.sun.net.httpserver package, which was added in JDK 1.6. At that time, the convention for JDK-specific APIs was to use the com.sun namespace. Other examples are com.sun.nio.sctp or com.sun.security.ntlm. In more recent times, this convention has been replaced with the jdk namespace. Both name spaces are JDK-specific, as such the simple server API is a supported JDK API.

Given that we're simply building on top of the long-standing API in com.sun.net.httpserver, revisiting the package name is out of the scope of this project.

Regards,
Julia
Reply | Threaded
Open this post in threaded view
|

Re: [External] : Re: Re: New candidate JEP: 408: Simple Web Server

Julia Boes
Hi Zheka,

On 05/04/2021 16:09, Zheka Kozlov wrote:
> Can we put at least new classes to some java.* package (SimpleFileServer,
> HttpHandlers, Request)? For example, java.net.httpserver.


The new classes extend/implement/build upon the existing abstractions in
jdk.httpserver, they have a clear API relationship and cannot be easily
separated out. Indeed, separating them out would make things much more
confusing, given they are a logical extension of the existing classes. Where
would we cut ties exactly? Old vs. new API points would be a misleading
distinction here and we would end up with a partial and incomplete package that
cannot stand on its own feet.

If the HTTP Server API were ever to be standardized (moved to the java.
namespace), it should be considered as a whole - with all the additional
considerations this would bring. And as said before, the java. vs. jdk.
namespace question is bigger than this JEP and will not be addressed in this work.

Regards,
Julia
Reply | Threaded
Open this post in threaded view
|

Re: [External] : Re: Re: New candidate JEP: 408: Simple Web Server

Alan Bateman
On 06/04/2021 11:25, Julia Boes wrote:

> :
> The new classes extend/implement/build upon the existing abstractions in
> jdk.httpserver, they have a clear API relationship and cannot be easily
> separated out. Indeed, separating them out would make things much more
> confusing, given they are a logical extension of the existing classes. Where
> would we cut ties exactly? Old vs. new API points would be a misleading
> distinction here and we would end up with a partial and incomplete package that
> cannot stand on its own feet.
>
> If the HTTP Server API were ever to be standardized (moved to the java.
> namespace), it should be considered as a whole - with all the additional
> considerations this would bring. And as said before, the java. vs. jdk.
> namespace question is bigger than this JEP and will not be addressed in this work.
Right, and the effort to do that should not be under estimated as it
would be very difficult to agreement on the scope. Also just to mention
that the original proposal for the web services stack in Java SE 6 (web
services callbacks were the the original motive for the http server API)
did have the http server API in the javax.* name space. JSR 270 (the
umbrella JSR for Java SE 6) had some concerns so it had to be introduced
as a JDK-specific API instead.

-Alan