Здравствуйте, ·, Вы писали:
·>А если она использует тот же JDK-шний io, то всё ок.
Ну я не особый знаток джавного ландшафта; но помимо стандартного IO в виде файлов/сокетов могут быть всякие сторонние решения.
То есть понятно, что если у нас есть какой-нибудь JDBC-шный драйвер, который внутре лезет на сервер через стандартный сокетный API, то всё зазеленеет само.
А если там какой-то high performance код, который работает с сетевой карточкой в чистой юзермоде, то чудес не случится.
·>Да. Ещё расчёт на то, что в java принято писать pure-решения. В отличие от того же c#, где на каждый чих DllImport.
Я так и подумал. Получается, тут преимущество java является обратной стороной её недостатка — трудности интеграции с нативным hi-perf кодом помогают оптимизировать low-perf код.

S>> Если нет — то приложение просто взорвётся при переходе на виртуальные потоки.
·>Да. Возможная грабля, похоже. В смысле вряд ли оно это сможет обнаружить как-то. Но ведь реальные треды никуда не уходят. Если есть такой код, который плотно взаимодействует с нативом и делает всякие странные вещи, то его можно всё ещё пускать на реальных тредах.
Тут главное — понять, можно ли пускать. В джаве популярны стеки глубиной в сотни вызовов. Вполне невинный гражданский код, который вызывает что-то из pure-java пакета, может через сотню-другую вызовов упереться в какой-то JNI, да ещё и зависимым от конфигурации образом. То есть в домашних тестах всё будет летать огнём, а в проде какая-нибудь экзотическая зависимость неожиданно стрельнет .

Я не спец в low-level; поэтому не знаю — есть ли способ определить, лазил ли сделанный нами вызов натива в TLS, чтобы сделать хотя бы fail fast с внятной диагностикой (вместо чтения мусора).