David, I understand that you don't use this feature of the JDK and that's
absolutely fine. I'm not the type of person to impose my way of doing things on
anyone. I hope that you aren't either. There are obviously many people in the
community that DO love and use this httpserver for many reasons that I won't go
into here as that is not the point of this discussion.
IIRC JDK is backward compatible so highly unlikely that it's going to be
removed. If you did find a way to remove it, I would also be open to having the
source code donated to myself to refactor and rebuild under a different
license. I'd be open to discussing this in more detail as well if need be.
Going back to the original discussion, you mention that points 2, 3 and 4 are
subjective. As per my original request, please do put forward your points of
view so that they can be discussed in more detail if you believe that they are
wrong.
Pragmatically speaking, the development can be done on your end to improve the
JDK OR on my end at a cost. I'm open to either.
Please do try and stay on topic in future responses.
Thanks & RegardsAshton
On Tuesday, 20 February 2018, 19:52:55 GMT, David Lloyd
<david.ll...@redhat.com> wrote:
Ashton, I don't think anyone disagrees with your four points at a high
level (though #4 might be a bit subjective, and #2 and #3 are
obviously design points that would theoretically be subject to
debate).
However, at the same time, you're not really going to see anyone
lining up and clamoring for a major rewrite of the JDK's HTTP server
right now, or maybe ever again. And the reason is exactly that there
are many external options now - enough that the internal server is
almost a legacy artifact at this point (after all it was IIRC only
introduced to support the in-JDK web services classes which may soon
be dropped from the JDK altogether). And I think that you are
definitely not going to inspire anyone to suddenly contribute effort
to overhauling it by listing off a couple of super-high-level
requirements.
That said, if you want to breathe life back into it, your best bet is
probably incremental improvement along a well-defined road map. Based
on my perspective, I still wouldn't be super hopeful that the OpenJDK
maintainers would be really interested at this point (particularly in
major changes), but if you really like the code base for some reason,
you also have the option of forking it. Particularly speaking, I
don't think you'll find many people who are interested in engaging in
any sort of design debate about it at this stage of its life.
Hope this helps.
On Tue, Feb 20, 2018 at 11:24 AM, Ashton Hogan <ashtonho...@ymail.com> wrote:
> Hi Rob
>
> Can you please read what I initially asked again, I'm not asking about new
> frameworks or web servers. I'm stating 4 points that need to be addressed in
> the EXISTING jdk6 web server. Again, if you disagree with any of these 4
> points can you please state WHY and WHAT the alternative to the respective
> POINT is
>
> On Tuesday, 20 February 2018, 17:18:20 GMT, Rob McKenna
> <rob.mcke...@oracle.com> wrote:
>
>
> W.r.t. alternatives the HTTP serving landscape on the JVM is rich and
> diverse at this point. Projects worth a look include Grizzly, Netty, Jetty,
> Tomcat, Undertow, Rapidoid and the many cool frameworks build on top of
> these technologies. (e.g. Jooby, SparkJava, Play to name a few)
>
> -Rob
>
> On 20/02/18 16:15, Ashton Hogan wrote:
>> These items are essential to keeping the server up to date and keeping
>> the code at Oracle clean and up to standard:
>>
>> 1. Update to HTTP22. Remove excess threads, only one thread is needed3.
>> Replace handler with a FIFO queue4. Clean up code, ideally with
>> http://elegantobjects.org principles
>> If you disagree on any of them please reply with why and what the
>> alternative should be
--
- DML
