Если для заказчика аудит — это чисто денег попилить и нет понимания того, что с точки зрения безопасности новая Java без аудита может быть лучше чем версия, которая проходила аудит 15 лет назад, то тут только руками развести можно. У них, случаем, Internet Explorer 6-й не стоит? )
Если оно работало и его никто не изменял, а также если вы были уверены, что со сторны безопасности к нему было не подступиться — то и черт с ним. Но если у вас мало-мальски живой проект, то почему бы не обновиться на актуальную JDK?
Все же в преддверии выхода Java 9 — статья имеет интерес уже больше с точки зрения истории, чем с точки зрения практического использования. Разве что модули вдруг понадобились прямо «здесь и сейчас».
В описании мысленного эксперимента с китайской комантой не вводятся какие-либо ограничения на то, как именно выглядит система правил/преобразований.
Нет никаких объективных причин считать, что «китайская комната» не способна «самообучаться», «порождать дополнительные рекации», «выкидывать устаревшие реакции». Более того, по условиям эксперимента она обязана уметь это всё делать, чтобы убедить внешнего наблюдателя, что она «знает китайский».
Суть утверждения Серла в том, что любое полноценное общение теоретически вполне возможно без сознания, но с использованием для ответов достаточно подробных правил интерпретации вопросов собеседника. Более общий вывод Сёрла говорит о том, что любые манипуляции с синтаксическими конструкциями не могут приводить к пониманию.
С такими выводами экспримента «китайской комнаты» многие не согласны. Почему мы не можем считать систему «китайской комнтаы» разумной? Почему мы не можем допускать, что данная система понимает, о чем говорит?
Поэтому мне кажется очень странным приводить «китайскую комнату» контаргументом к чему либо, как это делает автор.
По моей памяти речи про удаление Unsafe и прочего в Java 9 никогда и не шло — речь шла о том, что классы типа Unsafe перестанут быть доступными (by default), а станут именно что внутенними классами (что совершенно логично с учетом Jigsaw), но будут доступны при добавлении дополнительного флага. Т.е. если хочешь Unsafe — стартуй JVM с флагом.
Что касается удаления вообще (после Java 9) — нужно понимать, что Unsafe нужны были для выполнения некоторых сугубо внутренних трюков. В Java 9 некоторые вещи в той или иной степени уже сделаны без Unsafe (например через VarHandles). Костыли в виде Unsafe уже не нужны, но увы, их нужно поддерживать, так как их уже используют библиотеки. А раз нужно поддерживать, то в итоге усложняется (и частично замедляется) та самая логика, которая стоит за Unsafe и VarHandles. Т.е. если бы Unsafe можно был выкинуть, то, возможно, JVM можно было бы в некоторых случаях сделать быстрее.
С другой стороны — доступ к Unsafe без флага в Java9 будет для большинства удобнее.
Мне кажется автоматизация и роботизация в значительной степени «помогают» абстрагироваться от проблем морали. Нажать кнопку, которая запустит автоматическую систему ведения войны может быть проще, чем нажать на спусковой крючок. Более того, подобная система может вводиться в строй постеменно, плавно. Так что конкретного момента когда человек сознательно отдает машине команду на убийство может и не быть.
Речь о том, что для многих сценариев того, что будет в Java 9 — достаточно.
Нет никаких объективных причин считать, что «китайская комната» не способна «самообучаться», «порождать дополнительные рекации», «выкидывать устаревшие реакции». Более того, по условиям эксперимента она обязана уметь это всё делать, чтобы убедить внешнего наблюдателя, что она «знает китайский».
Поэтому мне кажется очень странным приводить «китайскую комнату» контаргументом к чему либо, как это делает автор.
Что касается удаления вообще (после Java 9) — нужно понимать, что Unsafe нужны были для выполнения некоторых сугубо внутренних трюков. В Java 9 некоторые вещи в той или иной степени уже сделаны без Unsafe (например через VarHandles). Костыли в виде Unsafe уже не нужны, но увы, их нужно поддерживать, так как их уже используют библиотеки. А раз нужно поддерживать, то в итоге усложняется (и частично замедляется) та самая логика, которая стоит за Unsafe и VarHandles. Т.е. если бы Unsafe можно был выкинуть, то, возможно, JVM можно было бы в некоторых случаях сделать быстрее.
С другой стороны — доступ к Unsafe без флага в Java9 будет для большинства удобнее.