Я не знаю, какие JVM реализуют / не реализуют прямые байтовые буферы. Но, в некотором смысле, это не особенно актуально ... потому что всегда возможно, что какой-нибудь поставщик выпустит новую JVM, которая изменяет уравнение, поддерживая / не поддерживая прямые ByteBuffers.
Должна ли библиотека JNI всегда кодировать управляемые ByteBuffers и отправлять прямые ByteBuffers в качестве оптимизации?
Это зависит от вашей цели.
Если ваша цель - максимальная переносимость, то ваш код JNI не должен предполагать, что доступны прямые байтовые буферы.
Если ваша цель - добиться максимальной производительности, ваш код может предполагать, что прямые байтовые буферы всегда будут доступны (и прервутся, если это не так). В качестве альтернативы вы можете иметь две разные библиотеки JNI (или условно скомпилированные варианты одной и той же библиотеки), которые сторона Java выбирает во время выполнения в зависимости от поддержки платформой прямых ByteBuffers.
Но все это кажется немного оторванным от реальности. Идя по маршруту JNI, вы неявно идете по пути непереносимости. Вам уже приходится иметь дело с собственными библиотеками, которые (по крайней мере) должны быть перекомпилированы для разных JVM и разных целевых платформ. И я бы подумал, что тестирование на всех поддерживаемых платформах необходимо.
Таким образом, не ожидайте каких-либо значительных сокращений для поддержки мультиплатформенности вашего кода JNI.