Jesse Gallagher

Since this compiles cleanly locally, I guess that the build failure here is because the built upstream API is the JEE8-targeted one, which would make sense.

Indeed. I think this is waiting for it to become practical to merge in the `jakarta.*` move from the API project. Otavio has an [original PR for that sitting around](https://github.com/eclipse-ee4j/nosql/pull/55),...

I do think it'd be good for the API to have minimal references to other Jakarta specs for this portability reasons, but there are also a few cases where it...

I don't have much to add other than: thanks for adding this! I hadn't yet had an occasion to move to JEE 10, but I did today, hit this problem...

I've been tinkering with this, but I think it's probably not really worth doing. There's a lot of fiddliness around ClassLoaders that makes it tricky, and realistically what would probably...

Virtual Views have me intrigued for sure. I'm not worried about JNX's direction, since I'm basically the primary maintainer of it, but the stuff going into Domino JNA since they...

Though straightforward in basic use, it turns out this runs afoul of some OSGi classloading, at least during Tycho-run tests. For example, the call that builds the Bean Validator hits...

I'm tempted to just wait this out, and then remove all uses of AccessController in one pass, as JEE is doing upstream. There may be a transitional period where changing...

That's another category that I've pondered. My experiences with Java logging frameworks other than just java.util.logging make me very, very wary of adding any in, but it could be worth...

Since this will technically be a breaking change, it'd make sense to put this in 3.0