Closed davecromberge closed 2 years ago
This is now ready for review.
Let's not merge just yet. I want to give Alex a chance to look at it.
Thank you both for the review. I would like to include an additional runtime check on the runtime version in this PR, is it acceptable to throw an exception if the user is on an unsupported version? Strictly speaking, errors would only affect users allocating direct memory on Java 9 or 10, but I think it's safest just to disable them completely.
I talked to Alex and Will about your question. If the user, running 9 or 10 and not attempting to allocate off-heap memory, can do pretty much anything else, our recommendation is to just leave it be and not prematurely throw if you detect 9 or 10. As long as it is documented that we don't support 9 or 10 it should be OK. It would be nice it we could throw an intelligent error message if the user attempts to allocate off-heap memory.
Thank you for this feedback - I think this makes sense. Design-wise, we could probably initialise the user runtime's capabilities as an enum and check these capabilities whenever the Memory API is invoked. Perhaps we can revisit this post-release.
In the meantime, I have reverted the premature exception since these versions might be implicitly supported if the user only allocates memory on heap. Once merged, I'll prepare these changes for release.
This removes support for Java9 and Java10. These versions are not LTS versions and in the case of Java9, no longer receive security patches.