avaje-jex
avaje-jex copied to clipboard
Start Http3
initial draft of Http3.
part of #46
relies on https://github.com/ptrd/flupke/issues/18 and https://github.com/ptrd/flupke/issues/17
@mechite what do you think of this so far
Remember that jex exclusively uses virtual threads so that we can avoid needing to implement any async stuff
exclusively uses virtual threads
right.. didn't know that. you learn something new every day
You can put in a manual override to use a regular executor, but the whole thing was designed with virtual threads in mind
random question... is the .impl package preferred here?
in Avaje projects the pattern I picked up was either — same package,
public interface SomeInterface ... & final ... DSomeInterface ...,
...or with a "subpackage" named .core for implementations
(I don't care — but consistency is gold)
consider me baffled, these transport tests are so flaky
this might be the fabled udp unreliability, I can't tell if it's a client or server issue, given the total lack of java webtransport clients in the ecosystem.
I think I get it, it was sending the data frames before the ssl frames, so just need a delay before sending data.
EDIT: apparently it was something else
after https://github.com/ptrd/flupke/issues/29 is resolved we should be good to go
@rbygrave I'm good with this