Re: Does anyone have context on jdk.httpserver?
Hi, I would like to revisit this. I have signed the OCA for another PR I worked on - I believe it covers all of my contributions. The websockets license looks to be very permissive. But it seems like this is something Oracle could reach out to the authors to resolve. I could also simply create a whiteroom ws impl, as I did for the http2 support - it’s a pretty small surface api. I am more than willing to work on this, but I need to know what the feasibility is of it actually being included. Even if the work was limited to “better support for vt”, some of the changes are more extensive (like the SSL handling). Regards, Robert > On Jan 22, 2024, at 3:08 AM, Alan Bateman wrote: > > On 22/01/2024 08:43, Robert Engels wrote: >> See github.com/robaho/httpserver for a more capable fork of the JDK code. >> >> Would love to create a PR to move the core changes back into the JDK but the >> net-dev folks don’t seem to be interested > > As I recall, it wasn't really possible to do any assessment because the > "contribution" wasn't covered by the OCA. In addition, I think you said in > one of the mails that it includes code from another project (for websocket or > HTTP upgrade?) and it's a big deal to have to import and work through the > license issues with 3rd party code. > > At a high level it seems reasonable to update the HTTP server implementation > to work better with virtual threads but updating it to be a more fully > featured HTTP server goes beyond what this HTTP server was/is intended for. > > -Alan > >
Re: Does anyone have context on jdk.httpserver?
Ok, based on this I don’t think VT (virtual threads) related structure and performance improvements make sense. If you can’t do the other elements you’re forced to use a different implementation anyway and the performance issues can be addressed there. Thanks for the feedback. Robert > On Jan 8, 2025, at 2:04 AM, Alan Bateman wrote: > > On 07/01/2025 15:18, robert engels wrote: >> Hi, >> >> I would like to revisit this. I have signed the OCA for another PR I worked >> on - I believe it covers all of my contributions. >> >> The websockets license looks to be very permissive. But it seems like this >> is something Oracle could reach out to the authors to resolve. > > The simple HTTP server in the JDK was never meant to be a fully featured and > high performance server. Instead it's meant for very simple usages, so think > getting started, the rite of passage to serve up a file, and local testing. > If someone wants a production ready server then there are dozens to choose > from. > > So I think highly questionable as to whether it's worth putting any time into > adding websockets or HTTP/2 support. > > >> I could also simply create a whiteroom ws impl, as I did for the http2 >> support - it’s a pretty small surface api. >> >> I am more than willing to work on this, but I need to know what the >> feasibility is of it actually being included. >> >> Even if the work was limited to “better support for vt”, some of the changes >> are more extensive (like the SSL handling). > There may be a few small things that would make sense to bring to net-dev to > discuss. I assume "vt" means virtual threads so if there is some issues there > then bring them to the mailing list to get some agreement that they are worth > doing. > > -Alan.
Re: RFR: 8348967: Deprecate security permission classes for removal
On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan wrote: > Please review this change to terminally deprecate the following security > related permission classes: `java.security.AllPermission`, > `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, > `javax.security.auth.AuthPermission`, > `javax.security.auth.PrivateCredentialPermission`, > `javax.security.auth.kerberos.DelegationPermission`, > `javax.security.auth.kerberos.ServicePermission`, > `com.sun.security.jgss.InquireSecContextPermission`. These classes were only > useful in conjunction with the Security Manager, which is no longer supported. > > The current API note in these classes was reused as the deprecation text. > > Release Note: https://bugs.openjdk.org/browse/JDK-8353680 Sad day when the Java backwards compatibility promise is thrown out the window because a bunch of developers need work to do. Removing these classes does nothing towards the reduced api surface the goal of removing the SM had. I suspect these classes haven’t changed in 20 years. - PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2778984443
