There has been no duplicate work luckily. The OmniConcurrent lib is just the alternative approach I mentioned I was working on during the platform call. The PR had been open for 3 days, and a diverse set of reviewers
from different companies was tagged.
The other PR with the Payara code was open for even longer (8 days) and didn't get any response. I think both the PRs and the mailing list are important vehicles for discussion, so the PR could have solicited
at least some discussion. That PR was ready to go in, no duplication of effort was required by the Payara team. See
https://github.com/eclipse-ee4j/glassfish/pull/23989 It could either be given permission, or copied fully and then sent back as a PR (so that the PR would be fully under Payara's
name). I sent an e-mail about that to Payara, suggesting exactly that 9 days ago.
In the discussion on the platform mailing list the ask to give permission for much of the glue code didn't get much of a response either, and the much smaller PR for just the CDI extension (that would benefit
Concurrency RI anyway, even without GlassFish in the equation) already seemed somewhat controversial.
That all said, as mentioned there's no duplication really, as it would still be better to have all the code directly in GlassFish under the EPL. The OmniConcurrent lib is just the backup solution here. It could
be just enough to get to ballot, and then at a time and pace that is convenient for everyone it can be replaced. Additionally note that the appserver/concurrent package has not been deleted from GlassFish. This was done exactly for this reason.
Hope this all makes it more clear.
