mcimadamore commented on PR #12033: URL: https://github.com/apache/lucene/pull/12033#issuecomment-1369960003
> I think this is special, but also according to spec JEP 12: Because Loom has two types of preview features: One inside the JVM and the other one co-developed inside the class library. For the Panama this is not the case, the code to access memory segments is always available because it also shares code with many other features like ByteBuffers (that also use the memory scopes). So ByteBuffers wont work if you would disable the scoped memory access. I think the difference between Loom and Panama is just accidental, rather than deliberate. Both are preview features - but since Loom goes deep into the JVM, choices were made to tie Loom closer to the preview command-line - that is, parts of support for continuations/virtual threads will be disabled if `enable-preview` is not there. Moreover, Loom does a lot more checks than Panama - for instance, when you use a virtual thread, Loom checks that `--enable-preview` is there - e.g. it doesn't trust the classfile version to be the source of truth (see the PreviewFeatures class in the JDK). If we added a similar check for the Panama API, the trick described in this PR would no longer work. (It is of course debatable as to whether *all* preview API should behave like this - as I stated, the discrepancies so far are more accidental than anything else, due to preview APIs being something rather "new"). As for the FFM API, I'm not planning to make things stricter (unless it is decided as a more global policy for preview APIs) - I don't think it will make sense given the point where the API is. But I wouldn't be surprised if checks like the ones in Loom would become *the norm* for any new preview API (of course that doesn't affect this PR directly). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
