Язык программирования Java и программная платформа Java критиковали за выбор дизайна на языке и платформах, в том числе реализации дженерик, принудительный объектно-ориентированного программирования, обработок чисел без знака, реализации арифметики с плавающей точкой и историями уязвимости безопасности в основной реализации виртуальной машины Java, HotSpot . Кроме того, программное обеспечение, написанное на Java, особенно его ранние версии, подвергалось критике за его производительность по сравнению с программным обеспечением, написанным на других языках программирования. Разработчики также отметили, что различия в различных реализациях Java необходимо учитывать при написании сложных программ Java, которые должны использоваться в этих реализациях. [1]
Синтаксис и семантика языка
Дженерики
Когда дженерики были добавлены в Java 5.0, уже существовала большая структура классов (многие из которых уже устарели ), поэтому дженерики были выбраны для реализации с использованием стирания типов, чтобы обеспечить совместимость миграции и повторное использование этих существующих классов. Это ограничивало возможности этого дополнения по сравнению с другими языками. [2] [3]
Поскольку универсальные шаблоны были реализованы с использованием стирания типа, фактический тип общего параметра шаблона E недоступен во время выполнения. Таким образом, в Java невозможны следующие операции: [4]
public class MyClass < E > { public static void myMethod ( Object item ) { if ( item instanceof E ) { // Ошибка компилятора ... } E item2 = new E (); // Ошибка компилятора E [] iArray = new E [ 10 ] ; // Ошибка компилятора } }
Ориентация на существительное
По своему замыслу Java побуждает программистов думать о программном решении в терминах существительных (классов), взаимодействующих друг с другом, и думать о глаголах (методах) как об операциях, которые могут выполняться над этим существительным или с ним. [5] Стив Йегге утверждает, что это вызывает ненужные ограничения на выразительность языка, потому что класс может иметь несколько функций, которые работают с ним, но функция привязана к классу и никогда не может работать с несколькими типами. [6]
Во многих других языках с несколькими парадигмами есть поддержка функций как конструкции верхнего уровня. В сочетании с другими языковыми функциями, такими как перегрузка функций (один глагол, несколько существительных) и / или универсальные функции (один глагол, семейство существительных с определенными свойствами), программист получает возможность решить, имеет ли смысл решать конкретная проблема в терминах существительных или глаголов. Java версии 8 представила некоторые функции функционального программирования.
Скрытая связь между кодом и оборудованием
В 2008 году Центр поддержки программных технологий Министерства обороны США опубликовал в «Журнале оборонной программной инженерии» статью, в которой обсуждалась непригодность Java в качестве языка программирования, впервые изученного в образовании. Недостатки Java как первого языка заключались в том, что учащиеся «не чувствовали связи между исходной программой и тем, что на самом деле будет делать аппаратное обеспечение», и невозможность «сформировать представление о стоимости времени выполнения написанного, потому что это чрезвычайно сложно понять, что вызовет любой метод ". [7] Точно так же Джоэл Спольски в 2005 году в своем эссе «Опасности JavaSchools» критиковал Java как чрезмерно ориентированную часть учебной программы . [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 может сделать код менее читаемым, особенно для классов, представляющих математические объекты, такие как комплексные числа, матрицы и т. д. Язык содержит только один нечисловой использование для операторов, и это конкатенация строк, реализованная с помощью +
оператора. Однако это реализовано только в компиляторе и компилируется в StringBuilder - невозможно создавать пользовательские перегрузки операторов.
Составные типы значений
В Java отсутствуют составные типы значений, такие как структуры в C, пакеты данных, которыми манипулируют напрямую, а не косвенно через ссылки. В некоторых случаях типы значений могут значительно улучшить производительность и сэкономить память. [14] [15] [16] Типичным примером является Java HashMap , которая внутренне реализована как массив объектов HashMap.Entry . [17] Поскольку в Java отсутствуют типы значений, этот массив фактически представляет собой массив ссылок (указателей) на объекты Entry , который, в свою очередь, содержит ссылки на объекты ключей и значений. Поиск чего-либо на карте требует неэффективного двойного косвенного обращения. Если бы Entry был типом значения, массив мог бы хранить пары ссылок на ключ и значение напрямую, устраняя первое косвенное обращение, увеличивая локальность и уменьшая использование памяти и фрагментацию кучи . Если бы Java и дальше поддерживала общие примитивные типы, примитивные ключи и значения могли бы храниться в массиве напрямую, удаляя второе косвенное обращение.
Большие массивы
Java критиковали за то, что она не поддерживает массивы из более чем 2 31 -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 (до того, как виртуальная машина 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 на большинстве телефонов вы остаетесь примерно с мощностью процессора оригинального IBM PC с частотой 4,77 МГц (так в оригинале) и плохим контролем над всем ». [38]
Безопасность
Платформа 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
помощью злонамеренной реализации своего implies
метода). Эти проблемы также задокументированы в двух книгах Марко Пистойи по безопасности Java : Java 2 Network Security (Second Edition) и Enterprise Java Security .
Несколько параллельных установок 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».
Смотрите также
- Сравнение Java и C ++
- Сравнение Java и C #
- Сравнение платформ Java и .NET
- Производительность Java
- Напишите один раз, бегите куда угодно
Заметки
- ↑ Вонг, Уильям (27 мая 2002 г.). «Пишите один раз, отлаживайте везде» . electronicdesign.com. Архивировано из оригинального 21 марта 2009 года . Проверено 3 августа 2008 года .
До сих пор обещание Java «писать один раз, работать везде» не сбылось. Основная часть Java-приложения будет мигрировать между большинством реализаций Java, но использование специфической для виртуальной машины функции вызывает проблемы с переносом.
- ^ «Дженерики на Java» . Object Computing, Inc. Архивировано из оригинального 2 -го января 2007 года . Источник +9 Декабрь 2006 .
- ^ «Что не так с Java: удаление типа» . 6 декабря 2006 . Источник +9 Декабрь 2006 .
- ^ «Стирание шрифта» .
- ^ «Спецификации Java SE» .
- ^ Егге, Стив. «Казнь в царстве существительных» .
- ^ Роберт Б.К. Дьюар; Эдмонд Шенберг (1 января 2008 г.). "Образование в области компьютерных наук: где инженеры-программисты завтрашнего дня?" . CrossTalk января 2008 . Центр поддержки программных технологий Министерства обороны США . Архивировано из оригинального 12 апреля 2009 года . Проверено 15 марта 2015 года .
Подводные камни Java как первого языка программирования [...] Студентам было трудно писать программы, не имевшие графического интерфейса, не имевшие представления о взаимосвязи между исходной программой и тем, что на самом деле будет делать оборудование, и (большинство повреждающий) вообще не понимал семантику указателей, что делало использование C в системном программировании очень сложным.
- ^ Джоэл Спольски (29 декабря 2005 г.). «Джоэл о программном обеспечении - опасности JavaSchools» . joelonsoftware . Проверено 18 ноября 2015 года .
Достаточно плохо, что JavaSchools не могут отсеять детей, которые никогда не станут хорошими программистами, что школы могут с полным основанием сказать, что это не их проблема. Промышленность или, по крайней мере, рекрутеры, которые используют grep, несомненно, требуют обучения Java. Но школы JavaSchools также не могут научить детей быть умелыми, гибкими и достаточно гибкими, чтобы делать хороший дизайн программного обеспечения.
- ^ Нед Батчелдер (1 января 2006 г.). «Джоэл Спольски - капризный старик» . nedbatchelder.com . Проверено 2 февраля +2016 .
Почему Джоэл выбрал указатели и рекурсию как две концепции привратника? Потому что он нашел их трудными? Как указывает Тим Брэй, Java отлично справляется с рекурсией, и параллелизм может быть более важной и сложной концепцией для освоения в любом случае. Акцент на рекурсии в языках Lisp является чрезмерным и не распространяется на другие культуры программирования. Почему люди думают, что это так важно для разработки программного обеспечения? Не поймите меня неправильно: я люблю рекурсию, когда это правильный инструмент для работы, но это не так часто, чтобы гарантировать, что Джоэл сосредоточил внимание на ней как на фундаментальной концепции.
Пока мы ищем жесткие концепции, которые отделяют мужчин от мальчиков, как насчет того, из-за которого мы с Джоэлом поссорились два года назад: исключения. В основном они ему не нравятся, потому что они его сбивают с толку. Это чем-то отличается от Java-парня, которому не нравятся указатели? Да, вы можете избежать исключений и использовать возврат статуса, но вы также можете очень постараться, чтобы избежать указателей. Значит ли это, что вам следует? Итак, у Джоэла есть концепции, которые ему нравятся (указатели и рекурсия), и он сожалеет об их упадке, но, похоже, не замечает, что есть новые концепции, которые он никогда не улавливал, и с которыми Java-детки чувствуют себя как дома. - ^ «Библиотеки Java должны обеспечивать поддержку беззнаковой целочисленной арифметики» . База данных ошибок, Sun Developer Network . Oracle . Проверено 18 января 2011 года .
- ^ Оуэн, Шон Р. (5 ноября 2009 г.). «Java и unsigned int, unsigned short, unsigned byte, unsigned long и т. Д. (Вернее, их отсутствие)» . Проверено 9 октября 2010 года .
- ^ «API беззнаковой целочисленной арифметики теперь в JDK 8 (Oracle Weblog Джозефа Д. Дарси)» . Дата обращения 15 мая 2016 .
- ^ «Перегрузка оператора C ++» . 7 апреля 2016 г.
- ^ Панель форума Java Grande (ноябрь 1998 г.). «Отчет форума Java Grande: как заставить Java работать для высокопроизводительных вычислений» (PDF) . SC98 .
- ^ а б Морейра, JE; ИП Мидкифф; М. Гупта; П.В. Артигас; М. Снир; РД Лоуренс (2000). «Программирование на Java для высокопроизводительных численных вычислений». IBM Systems Journal . 39 (1): 21–56. CiteSeerX 10.1.1.13.1554 . DOI : 10.1147 / sj.391.0021 .
Настоящие прямоугольные многомерные массивы являются наиболее важными структурами данных для научных и инженерных вычислений.
- ^ Хатчинсон, Бен (14 июня 2008 г.). «JVM нужны типы значений» . Проверено 3 февраля 2012 года .
- ^ "Исходный код java.util.HashMap" . JDK 8 . zGrepCode . Проверено 6 августа 2018 .
- ^ Арндт, Хольгер; Бундшус, Маркус; Нэгеле, Андреас (2009). «На пути к матричной библиотеке следующего поколения для Java» (PDF) . 2009 33-я ежегодная Международная конференция по компьютерному программному обеспечению и приложениям IEEE . С. 460–467. CiteSeerX 10.1.1.471.7567 . DOI : 10.1109 / compsac.2009.67 . ISBN 978-0-7695-3726-9.
... в Java невозможно иметь массивы с более чем 2 31 записями ...
- ^ «Почему Java Collection.size () возвращает int?» . Переполнение стека . Архивировано из оригинального 26 марта 2013 года . Проверено 10 февраля 2012 года .
- ^ Карпентер, Боб (28 июля 2010 г.). «Абстракция Big Bit-Packed Array (для Java, C и т. Д.)» . Блог LingPipe . Проверено 10 февраля 2012 года .
- ^ Джеймс Гослинг; Билл Джой; Гай Стил; Гилад Браха. «Спецификация языка Java» (Третье изд.). Эддисон Уэсли . Проверено 6 февраля 2012 года .
- ^ Лоуден, Джеймс. «Предложение: большие массивы (дубль два)» . Список рассылки Java.net coin-dev . Проверено 10 февраля 2012 года .
- ^ "java.util.Collection" . Платформа Java ™, стандартная версия 7. Спецификация API . Проверено 10 февраля 2012 года .
- ^ "java.nio.ByteBuffer" . Платформа Java ™, стандартная версия 7. Спецификация API . Проверено 6 февраля 2012 года .
- ^ Дэвид Флэнаган. Java в двух словах . п. 77.
- ^ Шерман Р. Альперт (IBM) (1998). «Примитивные типы считаются вредными» . Отчет Java, ноябрь 1998 г. (Том 3, номер 11) . Проверено 18 ноября 2015 года .
- ^ Бринч Хансен (апрель 1999 г.). «Небезопасный параллелизм Java» (PDF) . СИГПЛАН . Проверено 13 октября 2012 года .; альтернативный URL
- ^ Сериализация и десериализация на Java с примером с сайта geeksforgeeks
- ^ Сериализация должна умереть Проблемы безопасности и проблемы с сериализацией случайных объектов. автор: dzone.com
- ^ Блох, Джошуа (2018). Эффективная Java . Эддисон-Уэсли. С. 339–345. ISBN 978-0-13-468599-1.
- ^ Kahan, W .; Джозеф Д. Дарси (1 марта 1998 г.). «Как плавающая точка в Java причиняет вред всем и везде» (PDF) . Источник +9 Декабрь 2006 .
- ^ «Типы, значения и переменные» . Sun Microsystems . Источник +9 Декабрь 2006 .
- ^ «Теория и практика Java: где ваша точка зрения? Уловки и ловушки с плавающей запятой и десятичными числами» . IBM. 1 января 2003 . Проверено 19 ноября 2011 года .
- ^ «Игра компьютерных тестов: Java vs Gnu C ++» . benchmarksgame.alioth.debian.org. Архивировано из оригинала 13 января 2015 года . Проверено 19 ноября 2011 года .
- ^ а б JP Льюис и Ульрих Нойман. «Производительность Java по сравнению с C ++» . Лаборатория графики и иммерсивных технологий, Университет Южной Калифорнии .
- ^ «Java Faster than C ++ Benchmark» . Дата обращения 15 мая 2016 .
- ^ FreeTTS - Перформанс Case Study Заархивированные 25 марта 2009 в Wayback Machine , Вилли Уокер, Пол Lamere, Филип Квок
- ^ Джон Д. Кармак (27 марта 2005 г.). "Приключения мобильного телефона" . Блог Джона Кармака . armadilloaerospace.com. Архивировано из оригинального 24 ноября 2015 года . Проверено 10 ноября 2015 года .
- ^ Архитектура безопасности платформы Java SE . Oracle. Проверено 23 апреля 2013.
- ^ а б «Исследователи подчеркивают недавний всплеск использования уязвимостей безопасности Java» .
- ^ "Вы проверили Java?" . Архивировано из оригинального 3 -го сентября 2012 года . Проверено 25 ноября 2010 года .
- ^ «Oracle знала о критических недостатках Java с апреля» . 30 августа 2012 . Проверено 30 августа 2012 года .
- ^ « « Бесшумное, но смертоносное »обновление безопасности Java ломает устаревшие приложения - разработчик» . Дата обращения 15 мая 2016 .
- ^ Пистойя, Марко; Банерджи, Аниндья; Науманн, Дэвид А. (май 2007 г.). "Beyond Stack Inspection: Единая модель контроля доступа и безопасности информационных потоков". Симпозиум IEEE 2007 г. по безопасности и конфиденциальности (SP '07) . IEEE: 149–163. DOI : 10,1109 / sp.2007.10 . ISBN 978-0-7695-2848-9.
- ^ «Приложение А» . www.java.com . Проверено 3 марта 2018 .
Внешние ссылки
- Free But Shackled - The Java Trap , эссе Ричарда Столлмана о движении за свободное программное обеспечение (от 12 апреля 2004 г.)
- Образование в области компьютерных наук: где инженеры-программисты завтрашнего дня? (от 8 января 2008 г.)
- Какие плохие особенности Java?