✖


Jump to content

Критика Java

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

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

[ редактировать ]

Проверенные исключения

[ редактировать ]
Дополнительная информация: Обработка исключений (программирование) § Проверенные исключения.

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

Дженерики

[ редактировать ]
Дополнительная информация: дженерики в Java.

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

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

public class MyClass<E> {
    public static void myMethod(Object item) {
        if (item instanceof E) {  //Compiler error
            ...
        }
        E item2 = new E(); //Compiler error
        E[] iArray = new E[10]; //Compiler error
    }
}

Кроме того, в 2016 году был обнаружен следующий пример, показывающий, что Java неработоспособен и, в свою очередь, делает JVM, которые выбрасывали ClassCastExceptions или любые другие ошибки времени выполнения, технически несоответствующими. [5] Это было исправлено в Java 10. 

class Nullless<T, U> {
  class Constrain<B extends U> {}
  final Constrain<? super T> constrain;
  final U u;

  Nullless(T t) {
    u = coerce(t);
    constrain = getConstrain();
  }

  <B extends U>
  U upcast(Constrain<B> constrain, B b) {
    return b;
  }
  U coerce(T t) {
    return upcast(constrain, t);
  }
  Constrain<? super T> getConstrain() {
    return constrain;
  }

  public static void main(String[] args) {
    String zero = new Nullless<Integer,String>(0).u;
  }
}

Существительное-ориентированность

[ редактировать ]
См. Также: Объектно-ориентированное программирование § Критика

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

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

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

[ редактировать ]

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

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

[ редактировать ]

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

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

[ редактировать ]

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

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

[ редактировать ]

Java критиковали за отсутствие поддержки массивов из 2 31 (около 2,1 млрд) и более элементов. [16] [17] Это ограничение языка; Спецификация языка Java , раздел 10.4, гласит, что:

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

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

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

[ редактировать ]

Массивы и примитивы являются чем-то особенным, и с ними нужно обращаться иначе, чем с классами. Это подверглось критике [22] потому что при создании библиотек общего назначения требуется множество вариантов функций.

Параллелизм

[ редактировать ]

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

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

[ редактировать ]

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

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

[ редактировать ]

в Java Хотя арифметика с плавающей запятой в значительной степени основана на IEEE 754 ( Стандарт для двоичной арифметики с плавающей запятой ), некоторые обязательные стандартные функции не поддерживаются даже при использовании strictfp модификатор, такой как флаги исключений и направленные округления. Типы расширенной точности , определенные стандартом IEEE 754 (и поддерживаемые многими процессорами), не поддерживаются Java. [27] [28] [29]

Отсутствие кортежей

[ редактировать ]

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

Абстрактные отношения между кодом и оборудованием

[ редактировать ]

В 2008 году Центр поддержки программных технологий Министерства обороны США опубликовал в «Журнале оборонной разработки программного обеспечения» статью, в которой обсуждалась непригодность Java в качестве первого изучаемого языка. Недостатки заключались в том, что студенты «не чувствовали связи между исходной программой и тем, что на самом деле будет делать аппаратное обеспечение», а также невозможность «выработать представление о стоимости того, что написано во время выполнения, потому что чрезвычайно трудно понять, что вызов метода в конечном итоге будет выполнен». [31] В 2005 году Джоэл Спольски раскритиковал Java как чрезмерную часть университетских учебных программ в своем эссе «Опасности JavaSchools» . [32] Другие, такие как Нед Батчелдер, не согласны со Спольски за критику тех частей языка, которые ему было трудно понять, утверждая, что комментарий Спольски был скорее «субъективной напыщенной речью». [33]

Производительность

[ редактировать ]
Дополнительная информация: производительность Java.

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

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

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

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

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

[ редактировать ]
Дополнительная информация: безопасность Java.

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

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

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

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

В 2007 году исследовательская группа под руководством Марко Пистойи выявила еще один важный недостаток модели безопасности Java: [44] на основе проверки стека . При доступе к ресурсу, чувствительному к безопасности, менеджер безопасности запускает код, который обходит стек вызовов, чтобы убедиться, что кодовая база каждого метода в нем имеет права доступа к ресурсу. Это делается для предотвращения сбивчивых нападок депутатов , которые происходят каждый раз, когда законная, более привилегированная программа обманом заставляет другую злоупотреблять своими полномочиями. Проблема с запутавшимся депутатом — это особый тип повышения привилегий . Пистойя заметил, что при доступе к ресурсу, чувствительному к безопасности, код, ответственный за получение ресурса, может больше не находиться в стеке. Например, метод, выполненный в прошлом, мог изменить значение поля объекта, которое определяет, какой ресурс использовать. Этот вызов метода может больше не находиться в стеке во время его проверки.

Некоторые разрешения неявно эквивалентны разрешениям Java. AllPermission. К ним относятся разрешение на изменение текущего менеджера безопасности (и замена его тем, который потенциально может обойти проверку стека), разрешение на создание экземпляра и использование пользовательского загрузчика классов (который может связать AllPermission вредоносному классу при его загрузке) и разрешение на создание специального разрешения (которое может объявить себя столь же мощным, как и AllPermission через свой implies метод). Эти проблемы описаны в двух книгах Пистойи по безопасности Java. [45] [46]

Параллельные установки

[ редактировать ]

До версии Java 7 установщики не удаляли старые версии Java. В системе Windows часто можно было увидеть несколько установок Java на одном компьютере. [47] [48] [49] Разрешалась множественная установка, и они могли использоваться программами, использующими определенные версии, включая вредоносные программы. Эта проблема решена в Java 7: с разрешения пользователя установщик удаляет более ранние установки. [50]

[ редактировать ]
Дополнительная информация: Своевременная компиляция § Безопасность.

JIT-компиляция в основном использует исполняемые данные и, таким образом, создает проблемы безопасности и возможные эксплойты.

См. также

[ редактировать ]

Примечания

[ редактировать ]
  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 г. Архивировано из оригинала 22 июля 2012 г. Проверено 9 декабря 2006 г.
  4. ^ «Стирание типа» .
  5. ^ Амин, Нада; Тейт, Росс (19 октября 2016 г.). «Системы типов Java и Scala несостоятельны: экзистенциальный кризис нулевых указателей» . Уведомления ACM SIGPLAN . 51 (10): 838–848. дои : 10.1145/3022671.2984004 . ISSN   0362-1340 .
  6. ^ «Спецификации Java SE» .
  7. ^ Йегге, Стив. «Казнь в царстве существительных» .
  8. ^ «Библиотеки Java должны обеспечивать поддержку целочисленной арифметики без знака» . База данных ошибок, Sun Developer Network . Оракул . Проверено 18 января 2011 г.
  9. ^ Оуэн, Шон Р. (5 ноября 2009 г.). «Java и unsigned int, unsigned short, unsigned byte, unsigned long и т.д. (вернее, их отсутствие)» . Проверено 9 октября 2010 г.
  10. ^ «API беззнаковых целочисленных арифметических операций теперь в JDK 8 (блог Oracle Джозефа Д. Дарси)» . Проверено 15 мая 2016 г.
  11. ^ «Перегрузка операторов C++» . 7 апреля 2016 г. Архивировано из оригинала 5 февраля 2020 г. Проверено 5 февраля 2020 г.
  12. ^ Панель форума Java Grande (ноябрь 1998 г.). «Отчет форума Java Grande: Как заставить Java работать на высокопроизводительных вычислениях» (PDF) . СК98 . Архивировано из оригинала (PDF) 18 мая 2013 года . Проверено 10 февраля 2012 г.
  13. ^ Jump up to: а б Морейра, JE; С. П. Мидкифф; М. Гупта; П.В. Артигас; М. Снир; Р. Д. Лоуренс (2000). «Программирование на Java для высокопроизводительных численных вычислений». IBM Systems Journal . 39 (1): 21–56. CiteSeerX   10.1.1.13.1554 . дои : 10.1147/sj.391.0021 . Настоящие прямоугольные многомерные массивы являются наиболее важными структурами данных для научных и инженерных вычислений.
  14. ^ Хатчинсон, Бен (14 июня 2008 г.). «JVM нужны типы значений» . Проверено 3 февраля 2012 г.
  15. ^ «Исходный код java.util.HashMap» . JDK 8 . zGrepCode . Проверено 6 августа 2018 г.
  16. ^ Арндт, Хольгер; Бундшус, Маркус; Нэгеле, Андреас (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 . S2CID   14672978 . ... в Java невозможно иметь массивы, содержащие более 2 31 записи...
  17. ^ «Почему Java Collection.size() возвращает целое число?» . Переполнение стека . Архивировано из оригинала 26 марта 2013 года . Проверено 10 февраля 2012 г.
  18. ^ Джеймс Гослинг; Билл Джой; Гай Стил; Гилад Браха. «Спецификация языка Java» (Третье изд.). Эддисон Уэсли . Проверено 6 февраля 2012 года .
  19. ^ Лоуден, Джеймс (24 марта 2009 г.). «Предложение: Большие массивы (возьмите два)» . Список рассылки для разработчиков монет Java.net . Проверено 10 февраля 2012 г.
  20. ^ "java.util.Collection" . Платформа Java™, спецификация API Standard Edition 7 . Проверено 10 февраля 2012 г.
  21. ^ "java.nio.ByteBuffer" . Платформа Java™, спецификация API Standard Edition 7 . Проверено 6 февраля 2012 года .
  22. ^ Шерман Р. Альперт (IBM) (1998). «Примитивные типы считаются вредными» . Отчет Java, ноябрь 1998 г. (том 3, номер 11) . Проверено 18 ноября 2015 г.
  23. ^ Бринч Хансен (апрель 1999 г.). «Небезопасный параллелизм Java» (PDF) . СИГПЛАН . Проверено 13 октября 2012 г. ; альтернативный URL
  24. ^ Сериализация и десериализация в Java на примере веб-сайта geeksforgeeks.
  25. ^ Сериализация должна умереть. Проблемы безопасности и проблемы с сериализацией случайных объектов. от dzone.com
  26. ^ Блох, Джошуа (2018). Эффективная Java . Аддисон-Уэсли. стр. 339–345. ISBN  978-0-13-468599-1 .
  27. ^ Кахан, В.; Джозеф Д. Дарси (1 марта 1998 г.). «Как числа с плавающей запятой в Java вредят всем и повсюду» (PDF) . Проверено 9 декабря 2006 г.
  28. ^ «Типы, значения и переменные» . Сан Микросистемс . Проверено 9 декабря 2006 г.
  29. ^ «Теория и практика Java: в чем ваша точка зрения? Трюки и ловушки с числами с плавающей запятой и десятичными числами» . ИБМ. 1 января 2003 года . Проверено 19 ноября 2011 г.
  30. ^ «Что не так в Java 8, часть V: кортежи — DZone» . dzone.com . Проверено 18 марта 2023 г.
  31. ^ Роберт Б.К. Дьюар; Эдмонд Шенберг (1 января 2008 г.). «Образование в области компьютерных наук: где инженеры-программисты завтрашнего дня?» . CrossTalk, январь 2008 г. Министерства обороны США Центр поддержки программных технологий . Архивировано из оригинала 12 апреля 2009 года . Проверено 15 марта 2015 г. Ловушки Java как первого языка программирования [...] Студентам было трудно писать программы, не имеющие графического интерфейса, они не чувствовали связи между исходной программой и тем, что на самом деле будет делать оборудование, и (большинство вредный) вообще не понимал семантики указателей, что делало использование C в системном программировании очень сложным.
  32. ^ Джоэл Спольски (29 декабря 2005 г.). «Джоэл о программном обеспечении — опасности JavaSchools» . программное обеспечение joelon . Проверено 18 ноября 2015 г. Достаточно плохо, что JavaSchools не могут отсеять детей, которые никогда не станут великими программистами, а школы могут с полным основанием заявить, что это не их проблема. Промышленность или, по крайней мере, рекрутеры, использующие grep, наверняка требуют обучения Java. Но Java-школы также не могут научить мозг детей быть ловкими, гибкими и достаточно гибкими, чтобы создавать хорошие программы.
  33. ^ Нед Батчелдер (1 января 2006 г.). «Джоэл Спольски — капризный старик» . nedbatchelder.com . Проверено 2 февраля 2016 г. Почему Джоэл выделяет указатели и рекурсию в качестве двух концепций привратников? Потому что он нашел их трудными? Как отмечает Тим ​​Брэй, Java прекрасно разбирается в рекурсии, и в любом случае параллелизм может оказаться более важной и трудной для освоения концепцией. Акцент на рекурсию в языках Лисп несколько чрезмерен и не применим в других культурах программирования. Почему люди думают, что это так важно для разработки программного обеспечения? Не поймите меня неправильно: мне нравится рекурсия, когда она является подходящим инструментом для работы, но это не так уж и часто, чтобы гарантировать, что Джоэл сосредоточит внимание на ней как на фундаментальной концепции.
    Пока мы ищем жесткие концепции, которые отличают мужчин от мальчиков, как насчет той, которая привела нас с Джоэлом в драку два года назад: Исключения. По сути, они ему не нравятся, потому что они его смущают. Отличается ли это от того, что Java-парень не любит указатели? Да, вы можете избегать исключений и использовать возвраты статуса, но вы также можете очень стараться избегать указателей. Означает ли это, что вам следует? Итак, у Джоэла есть концепции, которые ему нравятся (указатели и рекурсия), и он оплакивает их упадок, но, похоже, не замечает, что есть более новые концепции, которые он никогда не усвоил, с которыми дети Java чувствуют себя как дома.
  34. ^ «Игра с тестами компьютерного языка: Java против Gnu C++» . тестыgame.alioth.debian.org. Архивировано из оригинала 13 января 2015 года . Проверено 19 ноября 2011 г.
  35. ^ Jump up to: а б Дж. П. Льюис и Ульрих Нейман. «Производительность Java по сравнению с C++» . Лаборатория графики и иммерсивных технологий, Университет Южной Калифорнии .
  36. ^ «Бенчмарк Java быстрее, чем C++» . Проверено 15 мая 2016 г.
  37. ^ FreeTTS - Пример производительности. Архивировано 25 марта 2009 г. в Wayback Machine , Уилли Уокер, Пол Ламере, Филип Квок.
  38. ^ Джон Д. Кармак (27 марта 2005 г.). «Приключения мобильного телефона» . Блог Джона Кармака . Armadilloaerospace.com. Архивировано из оригинала 24 ноября 2015 года . Проверено 10 ноября 2015 г.
  39. ^ Архитектура безопасности платформы Java SE . Оракул. Проверено 23 апреля 2013 г.
  40. ^ Jump up to: а б «Исследователи отмечают недавний рост числа эксплойтов безопасности Java» .
  41. ^ «Вы проверили Java?» . Архивировано из оригинала 21 сентября 2012 года . Проверено 25 ноября 2010 г.
  42. ^ «Oracle знала о критических недостатках Java еще с апреля» . Регистр . 30 августа 2012 года . Проверено 30 августа 2012 г.
  43. ^ « «Бесшумное, но смертельное» обновление безопасности Java ломает устаревшие приложения – разработчик» . Регистр . Проверено 15 мая 2016 г.
  44. ^ Пистойя, Марко; Банерджи, Аниндья; Науманн, Дэвид А. (май 2007 г.). «Помимо проверки стека: унифицированная модель контроля доступа и безопасности информационных потоков». Симпозиум IEEE по безопасности и конфиденциальности 2007 г. (SP '07) . IEEE. стр. 149–163. дои : 10.1109/sp.2007.10 . ISBN  978-0-7695-2848-9 . S2CID   4112294 .
  45. ^ Пистойя, Марко, изд. (1999). Сетевая безопасность Java 2 . Сетевая серия ITSO (2-е изд.). Река Аппер-Сэддл, Нью-Джерси: Прентис-Холл. ISBN  978-0-13-015592-4 .
  46. ^ Пистойя, Марко, изд. (2004). Корпоративная безопасность Java: создание безопасных приложений J2EE . Бостон, Массачусетс, Мюнхен: Аддисон-Уэсли. ISBN  978-0-321-11889-9 .
  47. ^ Граймс, Роджер А. (15 ноября 2011 г.). «Старые версии Java порождают новые уязвимости безопасности» . Инфомир . Проверено 10 сентября 2023 г.
  48. ^ Криль, Пол (4 мая 2012 г.). «Oracle призывает удалить старые версии Java из-за угроз безопасности» . Инфомир . Проверено 10 сентября 2023 г.
  49. ^ «Почему мне следует удалять старые версии Java из моей системы?» . Ява . 10 сентября 2023 г. Проверено 10 сентября 2023 г.
  50. ^ «Автоматическое обновление Java 6 до Java 7» . Оракул . 10 сентября 2023 г. Проверено 10 сентября 2023 г.
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Criticism_of_Java&oldid=1234766651"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 60dfec9046369b81195856025471cf0b__1721082780
URL1:https://arc.ask3.ru/arc/aa/60/0b/60dfec9046369b81195856025471cf0b.html
Заголовок, (Title) документа по адресу, URL1:
Criticism of Java - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)