Критика Java - Википедия - Criticism of Java

В Язык программирования Java и Программная платформа Java подвергались критике за выбор дизайна языка и платформы, включая реализацию универсальных шаблонов, принудительное объектно-ориентированное программирование, обработку беззнаковых чисел, реализацию арифметики с плавающей запятой и историю уязвимостей безопасности в основной реализации Java VM. , HotSpot. Кроме того, программное обеспечение, написанное на Java, особенно его ранние версии, подвергалось критике за его производительность по сравнению с программным обеспечением, написанным на других языках программирования. Разработчики также отметили, что различия в различных реализациях Java необходимо принимать во внимание при написании сложных программ Java, которые должны использоваться в этих реализациях.[1]

Синтаксис и семантика языка

Дженерики

Дальнейшая информация: Дженерики в Java

Когда дженерики были добавлены в Java 5.0, уже существовала большая структура классов (многие из которых уже были устарел ), поэтому дженерики были выбраны для реализации с использованием стирание типа чтобы позволить совместимость миграции и повторное использование этих существующих классов. Это ограничивало возможности, которые могло быть предоставлено этим дополнением по сравнению с другими языками.[2][3]

Поскольку дженерики были реализованы с использованием стирание типа фактический тип общего параметра шаблона E недоступен во время выполнения. Таким образом, в Java невозможны следующие операции:[4]

общественный учебный класс Мой класс<E> {    общественный статический пустота myMethod(Объект элемент) {        если (элемент экземпляр E) {  // Ошибка компилятора            ...        }        E item2 = новый E();   // Ошибка компилятора        E[] iArray = новый E[10]; // Ошибка компилятора    }}

Ориентация на существительное

Смотрите также: Объектно-ориентированное программирование § Критика

По своему замыслу, Java побуждает программистов думать о программном решении в терминах существительных (классов), взаимодействующих друг с другом, и думать о глаголах (методах) как об операциях, которые могут выполняться над этим существительным или с ним.[5] Стив Йегге утверждает, что это вызывает ненужные ограничения на выразительность языка, потому что класс может иметь несколько функций, которые работают с ним, но функция привязана к классу и никогда не может работать с несколькими типами.[6]

Во многих других мультипарадигма языках существует поддержка функций как конструкции верхнего уровня. В сочетании с другими языковыми функциями, такими как перегрузка функции (один глагол, несколько существительных) и / или общие функции (один глагол, семейство существительных с определенными свойствами), программисту дается возможность решить, имеет ли смысл решать конкретную проблему с помощью существительных или глаголов. Java версии 8 введены некоторые функции функционального программирования.

Скрытая связь между кодом и оборудованием

В 2008 г. Министерство обороны США Центр поддержки программных технологий (Center Software Technology Support) опубликовал в "Journal of Defense Software Engineering" статью, в которой обсуждалась непригодность Java в том виде, в каком она была впервые обнаружена. язык программирования в образовании. Недостатки, присущие Java как первому языку, заключались в том, что учащиеся «не чувствовали связи между исходной программой и тем, что на самом деле будет делать аппаратное обеспечение», а также невозможность «понять стоимость времени выполнения написанного, потому что это чрезвычайно сложно понять, что вызовет любой метод ".[7] по аналогии Джоэл Спольски в 2005 году в своем эссе критиковал Java как чрезмерно ориентированную часть учебной программы Опасности JavaSchools.[8] Другие, такие как Нед Батчелдер, не согласны со Спольски за критику частей языка, которые ему было трудно понять, утверждая, что комментарий Спольски был скорее «субъективной тирадой».[9]

Беззнаковые целые типы

В Java отсутствует родной беззнаковое целое типы. Беззнаковые данные часто генерируются из программ, написанных на C, а отсутствие этих типов препятствует прямому обмену данными между C и Java. Беззнаковые большие числа также используются в ряде полей числовой обработки, включая криптографию, что может сделать Java более неудобным для использования для этих задач.[10]Хотя можно частично обойти эту проблему с помощью кода преобразования и использования больших типов данных, это затрудняет использование Java для обработки данных без знака. Хотя 32-разрядное целое число со знаком может использоваться для хранения 16-разрядного значения без знака без потерь, а 32-разрядное значение без знака потребует 64-разрядного целого числа со знаком, 64-разрядное значение без знака не может быть легко сохранено с использованием любого целочисленного типа, потому что в языке Java не существует типов размером более 64 бит. Во всех случаях потребляемая память может увеличиваться до двух раз, и любая логика, которая зависит от правил два дополнения переполнение обычно должно быть переписано. Если абстрагироваться с использованием функций, вызовы функций становятся необходимыми для многих операций, которые являются родными для некоторых других языков. В качестве альтернативы можно использовать целые числа со знаком Java для подражать целые числа без знака того же размера, но это требует детального знания побитовые операции.[11] Некоторая поддержка беззнаковых целочисленных типов была предоставлена ​​в JDK 8, но не для беззнаковых байтов и без поддержки в языке Java.[12]

Перегрузка оператора

Java критиковали за то, что она не поддерживает возможность реализации определяемых пользователем операторов.[нужна цитата ] Перегрузка оператора улучшает читаемость,[13] таким образом, его отсутствие в Java может сделать код менее читаемым, особенно для классов, представляющих математические объекты, такие как комплексные числа, матрицы и т. д. Форма перегрузки оператора является реализовано на языке: в частности, кроме добавления числовых примитивных типов, оператор используется для конкатенации строк. Однако эта форма перегрузки является встроенной функцией языка, и пользователи никоим образом не могут определять свои собственные операторы.

Составные типы значений

В Java отсутствуют составные типы значений, такие как структуры в C - пакеты данных, которые обрабатываются напрямую, а не косвенно через ссылки. В некоторых случаях типы значений могут значительно улучшить производительность и сэкономить память.[14][15][16] Типичный пример - Java HashMap, который внутренне реализован как массив HashMap.Entry объекты.[17] Поскольку в Java отсутствуют типы значений, этот массив фактически является массивом ссылок (указателей) на Вход объекты, которые, в свою очередь, содержат ссылки на объекты ключей и значений. Поиск чего-либо на карте требует неэффективного двойного косвенного обращения. Если Вход были типом значения, массив мог хранить пары ссылок на ключ и значение напрямую, исключая первое косвенное обращение, увеличивая местонахождение и уменьшение использования памяти и кучи фрагментация. Если бы Java и дальше поддерживала общие примитивные типы, примитивные ключи и значения могли бы храниться в массиве напрямую, удаляя второе косвенное обращение.

Большие массивы

Java подверглась критике за то, что не поддерживает массивы более 231−1 (около 2,1 миллиарда) элементов.[18][19][20] Это ограничение языка; то Спецификация языка JavaВ разделе 10.4 говорится, что:

Массивы должны быть проиндексированы по значениям типа int ... Попытка получить доступ к компоненту массива с длинным значением индекса приводит к ошибке времени компиляции.[21]

Поддержка больших массивов также потребует изменений в JVM.[22] Это ограничение проявляется в таких областях, как коллекции, ограниченные 2 миллиардами элементов.[23] и невозможность отображать в памяти непрерывные сегменты файлов размером более 2 ГБ.[24] В Java также отсутствуют настоящие многомерные массивы (непрерывно выделенные отдельные блоки памяти, доступ к которым осуществляется одним косвенным обращением), что ограничивает производительность для научных и технических вычислений.[15]

В Java нет эффективного способа инициализировать массивы. При объявлении массива JVM компилирует его в байт-коды с инструкциями, которые устанавливают его элементы один за другим во время выполнения. Поскольку Java-методы не могут быть больше 64 КБ, массивы даже скромных размеров со значениями, назначенными непосредственно в коде, будут выдавать сообщение «Ошибка: слишком большой код» при компиляции.[25][нужен лучший источник ]

Интеграция примитивов и массивов

Тот факт, что массивы и примитивы в некоторой степени особенные, и к ним нужно относиться иначе, чем к (другим) объектам, подвергался критике.[26] потому что это требует написания множества вариантов при создании общих библиотек.

Параллелизм

Пер Бринч Хансен утверждал в 1999 году[27] что реализация параллелизма в Java в целом и мониторы в частности, не предоставляют гарантий и принудительных мер, необходимых для безопасного и надежного параллельного программирования. В то время как программист может установить дизайн и кодирование условности чтобы, скажем, осуществлять контролируемый доступ только к глобальным переменным потока, язык и компилятор не предпринимают никаких попыток принудительно обеспечить этот контролируемый доступ. Т.е. программист может по ошибке разрешить неконтролируемый доступ к глобальным переменным потока, и компилятор не обнаружит этого.

Сериализация

Java предоставляет механизм, называемый сериализацией объекта, где объект может быть представлен как последовательность байтов, которая включает данные объекта, а также информацию о типе объекта и типах данных, хранящихся в объекте. После того, как сериализованный объект был записан в файл, он может быть прочитан из файла и десериализован, то есть информация о типе и байты, которые представляют объект и его данные, могут быть использованы для воссоздания объекта в памяти.[28] Это создает очень серьезные теоретические и фактические риски безопасности.[29][30]

Арифметика с плавающей запятой

Хотя Java плавающая точка арифметика во многом основана на IEEE 754 (Стандарт двоичной арифметики с плавающей запятой), некоторые функции не поддерживаются даже при использовании strictfp модификатор, такой как флаги исключений и направленное округление - возможности, предусмотренные стандартом IEEE Standard 754. Кроме того, с плавающей запятой повышенной точности типы, разрешенные в 754 и присутствующие во многих процессорах, не разрешены в Java.[31][32][33]

Спектакль

Дальнейшая информация: Производительность Java

На заре Java (до HotSpot ВМ был реализован в Java 1.3 в 2000 году) было много критики производительности. Было продемонстрировано, что Java работает со скоростью, сравнимой с оптимизированным собственным кодом, а современные JVM реализации регулярно тестируется как одна из самых быстрых доступных языковых платформ - обычно в 3 раза по сравнению с C и C ++.[34]

Производительность Java значительно улучшился по сравнению с ранними версиями.[35] Производительность JIT-компиляторы относительно собственных компиляторов, в некоторых оптимизированных тестах было показано, что они очень похожи.[35][36][37]

Байт-код Java может либо интерпретироваться во время выполнения виртуальной машиной, либо он может быть скомпилирован во время загрузки или выполнения в собственный код, который выполняется непосредственно на оборудовании компьютера. Интерпретация выполняется медленнее, чем собственное выполнение, и компиляция во время загрузки или выполнения имеет начальное снижение производительности для компиляции. Все современные высокопроизводительные реализации JVM используют подход компиляции, поэтому после первоначального запуска производительность аналогична машинному коду.

Геймдизайнер и программист Джон Д. Кармак заключили в 2005 году о Java на сотовые телефоны: «Самая большая проблема в том, что Java действительно медленная. На чистом уровне процессора / памяти / дисплея / связи большинство современных сотовых телефонов должны быть значительно лучше игровых платформ, чем Game Boy Advance. С Java на большинстве телефонов вы останетесь с о мощности процессора оригинального 4,77 МГц (sic) IBM PC, и плохой контроль над всем ".[38]

Безопасность

Дальнейшая информация: Безопасность Java

Платформа Java обеспечивает архитектуру безопасности[39] который разработан, чтобы позволить пользователю запускать ненадежный байт-код в «песочнице» для защиты от вредоносного или плохо написанного программного обеспечения. Эта функция «песочницы» предназначена для защиты пользователя путем ограничения доступа к определенным функциям платформы и API, которые могут быть использованы вредоносное ПО, например, доступ к локальной файловой системе, выполнение произвольных команд или доступ к сетям связи.

В 2010 году значительно увеличилось количество вредоносных программ, нацеленных на бреши безопасности в механизме песочницы во многих широко используемых реализациях Java, включая Oracle. Эти недостатки позволяют ненадежному коду обойти ограничения песочницы, подвергая пользователя вредоносным атакам. Целевые недостатки безопасности, которые уже были исправлены с помощью обновлений безопасности от сопровождающих JVM, использовались на компьютерах без обновлений безопасности.[40]

Критики предположили, что обновленные версии Java не используются, потому что многие пользователи не осведомлены о том, что Java установлена, отсутствует общая осведомленность о том, как обновлять Java, и (на корпоративных компьютерах) многие компании ограничивают установку программного обеспечения и медленно развертывают обновления.[40][41]

Oracle подвергался критике за то, что в течение долгого времени не предоставлял обновления безопасности Java для известных ошибок безопасности, несмотря на то, что эти ошибки безопасности имели известные эксплойты.[42] Когда Oracle наконец приступила к исправлению широко используемых недостатков в Java 7, они удалили Java 6 на машинах пользователей, несмотря на то, что она широко использовалась корпоративными приложениями, которые, по утверждению Oracle, не были затронуты этими недостатками.[43]

В 2007 году исследовательская группа под руководством Марко Пистойя, выявил еще один важный недостаток модели безопасности Java,[44] который основан на инспекция стека. Это означает, что во время доступа к чувствительному к безопасности ресурсу диспетчер безопасности запускает обход стека, который проверяет, что кодовая база каждого метода в текущем стеке вызовов авторизована для доступа к чувствительному к безопасности ресурсу. Это сделано для предотвращения запутанные депутатские нападки, которые происходят каждый раз, когда законные, более привилегированные компьютерная программа обманом другой программой злоупотребляет своими полномочиями в системе. Проблема растерянности депутата - это особый тип повышение привилегий. Проблема с этим подходом, как заметил Марко Пистойя, и другие. заключается в том, что в момент доступа к чувствительному к безопасности ресурсу код, отвечающий за идентификацию этого ресурса, может больше не находиться в текущем стеке. Например, метод, выполненный в прошлом, мог изменить значение поля объекта, которое используется для определения ресурса, к которому осуществляется доступ. Этот метод мог уже появиться из стека, когда происходит проверка стека. Другие ограничения модели безопасности Java заключаются в том, что определенные разрешения неявно эквивалентны разрешениям Java. AllPermission. К ним относятся разрешение на изменение текущего диспетчера безопасности (и замена его на тот, который потенциально может обойти проверку стека), разрешение на создание экземпляра и использование пользовательского загрузчика классов (который может выбрать привязку AllPermission к вредоносному классу при его загрузке), а также разрешение на создание настраиваемого разрешения (которое потенциально может объявить себя таким мощным, как AllPermission посредством злонамеренной реализации своего подразумевает метод). Эти проблемы также задокументированы в Марко Пистойя две книги по безопасности Java: Сетевая безопасность Java 2 (второе издание) и Корпоративная безопасность Java.

Несколько параллельных установок Java

В версиях Java до 7 было нормально, что программа установки не обнаруживала и не удаляла предыдущие установки Java. На компьютере с Windows было довольно часто видеть несколько установок Java 6 на одном компьютере, которые различались только версией обновления. Разрешено использование нескольких Jav, и к ним могут обращаться программы, ищущие определенные версии.

Это приводит к тому, что новые установки Java предоставляют только новые языковые функции и исправления ошибок, но не исправляют уязвимости безопасности, поскольку вредоносные программы могут искать более старые предыдущие выпуски Java и использовать их, а не новейшие версии.

Java 7 обновляла предыдущие версии, но не искала наличия Java 6 и более ранних версий.[45]

Нет возможности автоматического самообновления

С 2014 года стандартные инструменты сторонних производителей (такие как Adobe Flash и Adobe Reader), которые подвергались тщательной проверке на уязвимость, были переведены на модель автоматического обновления в Windows. Эта модель не требует вмешательства пользователя и гарантирует быстрое решение проблем безопасности без дополнительных усилий со стороны системных пользователей или администраторов.

По состоянию на 2015 год Java 8 по-прежнему требует, чтобы пользователь компьютера вручную самостоятельно устанавливал обновления Java. Эти обновления могут применяться только теми, у кого есть права администратора. Средство обновления Windows Java часто запускает прерывистый случайный запрос на повышение уровня контроля учетных записей пользователей; однако выбор «Да» или «Нет» для повышения прав по-прежнему приведет к тому же сообщению «Требуется обновление Java».

Смотрите также

Примечания

  1. ^ Вонг, Уильям (27 мая 2002 г.). «Пишите один раз, отлаживайте везде». electronicdesign.com. Архивировано из оригинал 21 марта 2009 г.. Получено 3 августа 2008. До сих пор обещание Java «писать один раз, работать везде» не сбылось. Основная часть Java-приложения будет мигрировать между большинством реализаций Java, но использование специфической для виртуальной машины функции вызывает проблемы с переносом.
  2. ^ «Дженерики на Java». Object Computing, Inc. Архивировано с оригинал 2 января 2007 г.. Получено 9 декабря 2006.
  3. ^ «Что не так с Java: удаление типа». 6 декабря 2006 г.. Получено 9 декабря 2006.
  4. ^ «Стирание шрифта».
  5. ^ «Технические характеристики Java SE».
  6. ^ Егге, Стив. «Казнь в царстве существительных».
  7. ^ Роберт Б.К. Дьюара; Эдмонд Шенберг (1 января 2008 г.). "Образование в области компьютерных наук: где инженеры-программисты завтрашнего дня?". CrossTalk, январь 2008 г.. Министерство обороны США Центр поддержки программных технологий. Архивировано из оригинал 12 апреля 2009 г.. Получено 15 марта 2015. Подводные камни Java как первого языка программирования [...] Студентам было трудно писать программы, не имевшие графического интерфейса, не имевшие представления о взаимосвязи между исходной программой и тем, что на самом деле будет делать оборудование, и (большинство повреждающий) вообще не понимал семантику указателей, что делало использование C в системном программировании очень сложным.
  8. ^ Джоэл Спольски (29 декабря 2005 г.). «Джоэл о программном обеспечении - опасности JavaSchools». joelonsoftware. Получено 18 ноября 2015. Достаточно плохо, что JavaSchools не могут отсеять детей, которые никогда не станут хорошими программистами, что школы могут с полным основанием сказать, что это не их проблема. Промышленность или, по крайней мере, рекрутеры, которые используют grep, несомненно, требуют обучения Java. Но школы JavaSchools также не могут научить детей быть умелыми, гибкими и достаточно гибкими, чтобы делать хороший дизайн программного обеспечения.
  9. ^ Нед Батчелдер (1 января 2006 г.). «Джоэл Спольски - капризный старик». nedbatchelder.com. Получено 2 февраля 2016. Почему Джоэл выбрал указатели и рекурсию как две концепции привратника? Потому что он нашел их трудными? Как указывает Тим ​​Брей, Java прекрасно справляется с рекурсией, и параллелизм может быть более важной и сложной концепцией для освоения в любом случае. Акцент на рекурсии в языках Lisp является чрезмерным и не распространяется на другие культуры программирования. Почему люди думают, что это так важно для разработки программного обеспечения? Не поймите меня неправильно: я люблю рекурсию, когда это правильный инструмент для работы, но это не так часто, чтобы гарантировать, что Джоэл сосредоточил внимание на ней как на фундаментальной концепции.
    Пока мы ищем жесткие концепции, которые отделяют мужчин от мальчиков, как насчет того, из-за которого мы с Джоэлом поссорились два года назад: исключения. В основном они ему не нравятся, потому что они его сбивают с толку. Это чем-то отличается от Java-парня, которому не нравятся указатели? Да, вы можете избежать исключений и использовать возврат статуса, но вы также можете очень постараться, чтобы избежать указателей. Значит ли это, что вам следует? Итак, у Джоэла есть концепции, которые ему нравятся (указатели и рекурсия), и он сожалеет об их упадке, но, похоже, не замечает, что есть новые концепции, которые он никогда не улавливал, и с которыми Java-детки чувствуют себя как дома.
  10. ^ «Библиотеки Java должны обеспечивать поддержку беззнаковой целочисленной арифметики». База данных ошибок, Sun Developer Network. Oracle. Получено 18 января 2011.
  11. ^ Оуэн, Шон Р. (5 ноября 2009 г.). «Java и unsigned int, unsigned short, unsigned byte, unsigned long и т. Д. (Точнее, их отсутствие)». Получено 9 октября 2010.
  12. ^ «Беззнаковый целочисленный арифметический API теперь в JDK 8 (блог Джозефа Д. Дарси Oracle)». Получено 15 мая 2016.
  13. ^ «Перегрузка оператора C ++». 7 апреля 2016.
  14. ^ Панель форума Java Grande (ноябрь 1998 г.). «Отчет форума Java Grande: как заставить Java работать для высокопроизводительных вычислений» (PDF). SC98.
  15. ^ а б Moreira, J.E .; С. П. Мидкифф; М. Гупта; П. В. Артигас; М. Снир; Р. Д. Лоуренс (2000). «Программирование на Java для высокопроизводительных численных вычислений». Журнал IBM Systems. 39 (1): 21–56. CiteSeerX  10.1.1.13.1554. Дои:10.1147 / sj.391.0021. Настоящие прямоугольные многомерные массивы являются наиболее важными структурами данных для научных и инженерных вычислений.
  16. ^ Хатчинсон, Бен (14 июня 2008 г.). «JVM нужны типы значений». Получено 3 февраля 2012.
  17. ^ "Исходный код java.util.HashMap". JDK 8. zGrepCode. Получено 6 августа 2018.
  18. ^ Арндт, Хольгер; Бундшус, Маркус; Нэгеле, Андреас (2009). «На пути к матричной библиотеке следующего поколения для Java» (PDF). 2009 33-я ежегодная Международная конференция по компьютерному программному обеспечению и приложениям IEEE. С. 460–467. CiteSeerX  10.1.1.471.7567. Дои:10.1109 / compsac.2009.67. ISBN  978-0-7695-3726-9. ... в Java невозможно иметь массивы с более чем 231 записи ...
  19. ^ «Почему Java Collection.size () возвращает int?». Переполнение стека. Архивировано из оригинал 26 марта 2013 г.. Получено 10 февраля 2012.
  20. ^ Карпентер, Боб (28 июля 2010 г.). «Абстракция большого битового массива (для Java, C и т. Д.)». Блог LingPipe. Получено 10 февраля 2012.
  21. ^ Джеймс Гослинг; Билл Джой; Гай Стил; Гилад Браха. «Спецификация языка Java» (Третье изд.). Эддисон Уэсли. Получено 6 февраля 2012.
  22. ^ Лоуден, Джеймс. «Предложение: большие массивы (дубль два)». Список рассылки Java.net coin-dev. Получено 10 февраля 2012.
  23. ^ "java.util.Collection". Платформа Java ™, Standard Edition 7 Спецификация API. Получено 10 февраля 2012.
  24. ^ "java.nio.ByteBuffer". Платформа Java ™, Standard Edition 7 Спецификация API. Получено 6 февраля 2012.
  25. ^ Дэвид Флэнаган. Java в двух словах. п. 77.
  26. ^ Шерман Р. Альперт (IBM) (1998). «Примитивные типы считаются вредными». Отчет Java, ноябрь 1998 г. (том 3, номер 11). Получено 18 ноября 2015.
  27. ^ Бринч Хансен (апрель 1999 г.). «Небезопасный параллелизм Java» (PDF). СИГПЛАН. Получено 13 октября 2012.; альтернативный URL
  28. ^ Сериализация и десериализация на Java с примером с сайта geeksforgeeks
  29. ^ Сериализация должна умереть Проблемы безопасности и проблемы с сериализацией случайных объектов. автор: dzone.com
  30. ^ Блох, Джошуа (2018). Эффективная Java. Эддисон-Уэсли. С. 339–345. ISBN  978-0-13-468599-1.
  31. ^ Kahan, W .; Джозеф Д. Дарси (1 марта 1998 г.). "Как плавающая точка в Java причиняет вред всем и везде" (PDF). Получено 9 декабря 2006.
  32. ^ «Типы, значения и переменные». Sun Microsystems. Получено 9 декабря 2006.
  33. ^ «Теория и практика Java: где ваша точка зрения? Уловки и ловушки с плавающей запятой и десятичными числами». IBM. 1 января 2003 г.. Получено 19 ноября 2011.
  34. ^ "Игра" Тесты компьютерного языка: Java против Gnu C ++ ". benchmarksgame.alioth.debian.org. Архивировано из оригинал 13 января 2015 г.. Получено 19 ноября 2011.
  35. ^ а б Дж. П. Льюис и Ульрих Нойман. «Производительность Java по сравнению с C ++». Лаборатория графики и иммерсивных технологий, Университет Южной Калифорнии.
  36. ^ «Тест Java Faster than C ++ Benchmark». Получено 15 мая 2016.
  37. ^ FreeTTS - Пример использования производительности В архиве 25 марта 2009 г. Wayback Machine, Уилли Уокер, Пол Ламер, Филип Квок
  38. ^ Джон Д. Кармак (27 марта 2005 г.). "Приключения мобильного телефона". Блог Джона Кармака. armadilloaerospace.com. Архивировано из оригинал 24 ноября 2015 г.. Получено 10 ноября 2015.
  39. ^ Архитектура безопасности платформы Java SE. Oracle. Проверено 23 апреля 2013.
  40. ^ а б «Исследователи подчеркивают недавний всплеск эксплойтов безопасности Java».
  41. ^ "Вы проверили Java?". Архивировано из оригинал 3 сентября 2012 г.. Получено 25 ноября 2010.
  42. ^ «Oracle знала о критических недостатках Java с апреля». 30 августа 2012 г.. Получено 30 августа 2012.
  43. ^ "'Тихое, но смертоносное «обновление безопасности Java ломает устаревшие приложения - разработчик». Получено 15 мая 2016.
  44. ^ Пистойя, Марко; Банерджи, Аниндья; Науманн, Дэвид А. (май 2007 г.). "Beyond Stack Inspection: Единая модель контроля доступа и безопасности информационных потоков". Симпозиум IEEE 2007 по безопасности и конфиденциальности (SP '07). IEEE: 149–163. Дои:10.1109 / sp.2007.10. ISBN  978-0-7695-2848-9.
  45. ^ «Приложение А». www.java.com. Получено 3 марта 2018.

внешняя ссылка