Статьи про программирование

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

Плохо написанный/Вводящий в заблуждение раздел

Следующее предложение начинает раздел Влияние на производительность (под критикой)…

Java получила репутацию медленной производительности. В первую очередь потому. Что большинство пользователей нацелены на виртуальную машину Java. А не на компиляцию языка непосредственно в машинный код.

Это предложение неверно по нескольким причинам.

Смысл этого предложения. Сравнивая его с собственным исполнением. Заключается в том. Что JVMS интерпретируют байт-код Java. Хотя это может быть так в ранних версиях Java. Сегодня это почти никогда не происходит. Практически все современные JVM компилируют байт-код Java в собственный машинный код перед его запуском. Кроме того, хотя существует несколько компиляторов Java. Которые могут создавать собственный исполняемый файл из Java-проекта. Большинство Java-приложений поставляются в виде Java-байт-кода и полагаются на JVM для их выполнения. Компиляция языка непосредственно в автономный исполняемый файл (машинный код) подразумевает. Что не только JVM не используется. Но и библиотеки Java. Которые, безусловно. Использует приложение. Также компилируются и доставляются в виде собственного кода. Сегодня это просто не так. Spookfish 05:26, 17 декабря 2005 (UTC)

Компиляция Java на родной машине всегда будет обеспечивать большую надежность и не обязательно производительность. Что также должно быть понято. Так это то. Что Java уже находится на задворках со скоростью выполнения по сравнению с такими. Как .NET, которые. Конечно же. Не имеют проблем типа JVM/Native. Говоря языком доктора Адриана Джониано (профессора компьютерных наук RMIT Doncaster). Вся эта проблема JVM сама по себе делает Java почти наверняка устаревшей в течение 5 лет. Если она не будет решена. И ожидается. Что к тому времени Microsoft набросится на развитую .Net. Если какое-либо утешение придет к Java. И это проблемы с компиляцией. Это будет то, что. По крайней мере. Когда SUN поставила продукт. Он асинхронно расширил свои собственные драйверы. Чтобы согласовать любые проблемы с потоками. Переносимость все фарс в конце концов.

Я не знаю, кто написал этот последний абзац. Но он показывает другой взгляд на реальность, чем мой. Во — первых. У нас есть приложения. Которые работают как JVM или C++ (с препроцессором для преобразования). И они имеют сопоставимую скорость-для некоторого кода Java-апплеты почему-то даже работают быстрее. Современные JIT очень хороши — и они запускают машинный код. Что касается переносимости: мы поставляем Java-апплеты. Которые работают на Windows. Mac и Linux-боксах. А также Java-плееры для мобильных телефонов. Я не думаю. Что .NET делает это. Stephen B Streater 21:57, 8 марта 2006 (UTC)

Влияние на производительность

В разделе Критика:Влияние на производительность упоминается. Что сборка мусора Часто для больших наборов данных с большим количеством мелких элементов GC может доминировать в обычных реализациях malloc/free. А в других случаях может быть сопоставимым. См. http://www.hpl.hp.com/personal/Hans_Boehm/gc/#details подробнее о популярной C-реализации сборки мусора. С другой стороны. Языковые характеристики:Автоматическая секция сбора мусора очень accuarte и независима. — Крис Марселлино

На самом деле. Простой эксперимент по выполнению free(malloc(10)); в узком цикле на C или C++ и эквивалентном цикле Java GC превосходит обычные реализации free/malloc в десять раз. В Sun JDK выделение составляет около 10 машинных инструкций. А освобождение — (почти) ноль инструкций. Так как GC не касается мусора. Однако время жизни объектов может повлиять на это довольно упрощенное измерение из-за поколенческого GC. Я подозреваю. Что было бы трудно прокомментировать это в статье. Не попав в неприятности с некоторыми людьми. Это несколько спекулятивно. Но утверждение о том. Что Weregerbil 01:27, 16 января 2006 (UTC)

Неверная информация

Есть параграф о сетевых средствах. Который соединяет цель Это неправильный абзац. Но я не знаю. Как лучше его разделить. Помогите, пожалуйста… —Алан Д

Я не вижу в этом никакой проблемы. Единственные места. Где они упоминаются вместе, — это те. Где они конкретно упоминаются как цели языка, где —НРС

Если вы не видите в этом проблемы. То я счастлив. —Алан Д


Еще несколько тем для добавления

Любой доброволец для : — Модели безопасности Java ? — процесс сообщества Java ?

История Java

Было бы неплохо сделать несколько заметок об истории версий Java. Особенно важно. Какая версия включена в какой браузер. Кваку

Может быть, вы путаете Java с JavaScript?
В какой-то момент Java 1.1 была включена в состав IE. С тех пор его вынули (?). Но он подключается к текущему браузеру, но вы должны DL & установить его. —Frecklefoot 16:19, 16 апреля 2004 (UTC)
Я просто добавил предложение ближе к началу. Чтобы устранить неоднозначность между Java и JavaScript. Что чаще встречается на веб-страницах и как их функция отличается на веб-страницах? Я бы предположил. Что javascript используется чаще. Но на самом деле я этого не знаю. Было бы неплохо. Если бы кто-то. Обладающий большими знаниями в этой области, чем я. Мог помочь усилить это различие. Поскольку я готов предположить, что мы. Не компьютерные спортсмены. Довольно часто путаем их. Сполдинг 14:49, 19 февраля 2005 (UTC)

См. http://c2.com/cgi/wiki?JavaHistory, которая утверждает. Что платформа Java (а не язык) была разработана Томом Стэмбо и его компанией Bridge Systems.


Отзывы

Ли, взгляните на [1]. Хорошие отзывы до сих пор! 🙂 —LMS


Это статья

Это должно быть перенесено в howto где-то. Так как это вообще не описывает язык.

Одним из самых запутанных понятий для тех. Кто только начинает изучать язык Java. Является понятие ClassPath, который должен быть установлен. Прежде чем что-либо может быть скомпилировано или выполнено.
В последних версиях Java есть параметр-classpath, который делает ненужным устанавливать переменную окружения CLASSPATH. На самом деле, я не использовал последнее с тех пор. —Maik 17:46, 2004 Oct 13 (UTC)

Java это тоже платформа

Хм, я думаю. Что этой статье помог бы обзор старого технического документа Java. Во-первых, Java-это не только язык. Но и платформа. Статья в ее нынешнем виде сбивает с толку по этому вопросу. Кроме того, одной из основных целей проектирования является относительно безопасный язык для среднестатистических программистов. Поэтому пальцы не режутся о трудные части программирования.

Тем не менее. Эта статья написана хорошо. И я бы изменил ее прямо сейчас. Если бы не потребовалось немного времени. Чтобы не сильно изрезать текст. Может быть, я бы избавился от той части. Которая говорит. Что за Java стоят

Статья называется Если статья не проясняет этого. То, возможно. Ее можно немного переформулировать и связать с другой статьей о платформе. И, честно говоря. Белая бумага-это довольно ужасный источник информации-это в основном рекламная статья для Sun. Которая содержит все их цели и идеи. Но ни одна из повседневных реалий большинства работающих Java-программистов. Это энциклопедия. А не рекламный носитель. —НРС
Тем не менее. Эта статья в настоящее время является перенаправлением для Groovy было бы очень полезно указать на сводную статью. Такую как раздел Java на странице Sun Microsystems. Я сделаю то же самое замечание на странице платформы Java. Пользователь:webmink
Я начал с этого. [[Пользователь:Smyth|– Smyth]] 13:11, 13 ноября 2004 (UTC)
На странице Платформа (вычисление) также есть раздел Java как платформа.—Jondel 18:49, 25 Sep 2004 (UTC)

Java: платформа и промежуточное ПО тоже

Мне бы тоже хотелось описание как платформы. Java-это не только 1)платформа и 2) язык. Это также промежуточное программное обеспечение. Некоторые из этих категорий или определений должны быть вставлены или сделаны. Jondel

Java не зависит от платформы

это миф, вводящий в заблуждение и неправильное название.

Скорее всего, JVM вездесуща на всех типах устройств и чипов. Когда они говорят. Что платформа независима. Это на самом деле потому. Что интерпретатор Java или JVM можно найти почти везде(на всех устройствах/чипах/пакетах sw). Установка интерпретатора или JVM стала отраслевым стандартом. Java не является независимой от платформы, Java является платформой( или вездесущий JVM или интерпретатор Java является платформой). Jondel 04:09, 13 мая 2004 (UTC)~~

Я думаю о языке программирования как о его синтаксисе. Семантике и стандартных библиотеках. Для Java эти три вещи в значительной степени независимы от платформы. В реальной жизни большинство Java-приложений будут выполняться одинаково на всех платформах.
Проблема здесь в стандартных библиотеках. Синтаксис и семантика высокоуровневых языков. Как правило. Не зависят от платформы. Но иногда стандартные библиотеки таковыми не являются. Итак, две важные вещи. Которые можно сказать о независимости платформы: 1) интепретер вездесущ (это действительно имеет значение-сравните SmallTalk). 2) стандартные библиотеки не зависят от платформы. Кто-нибудь видел, как сказать это, не испортив хорошую статью? -BK 207.96.29.129 14:16, 9 сентября 2005 (UTC)
Это правда, что Java требует платформенно-зависимого интерпретатора. Но я бы не стал характеризовать интерпретатор как часть Точно так же. Как я не рассматривал бы компилятор как часть языка для скомпилированного языка.
Верно также и то. Что в Java существуют специфические для платформы API, но они. Как правило. Не поощряются или устарели в документации. Вполне возможно избежать этих API почти для всех приложений. И на практике их избегают большую часть времени. Язык программирования Java не является полностью независимым от платформы. Но он делает очень хорошую работу.
Бен Арнольд 04:50, 13 мая 2004 (UTC)
Другая категория ?
Договорились о языке. И он довольно хорошо справляется с тем. Чтобы быть независимым от платформы. Вы, кажется. Программист.
Я ориентируюсь на новичков и новичков. Кроме того, я хотел сосредоточиться на аспекте платформы.
Термин Если речь идет о Java. То важно объяснить или исследовать ее аспект как платформы и интерпретатора Java. Что делать, если новая ОС не имеет JVM? Программист должен знать. Что любой байт-код нуждается в интерпретаторе. Люди склонны думать. Что платформа-это то место. Где была скомпилирована программа?
Может быть, это должно быть в другой категории (программное обеспечение Java?Платформа Java? Java API?), так как интерпретатор на самом деле не является частью языка программирования Java. Джондель 05:49, 13 мая 2004 (UTC)~~
Я придерживаюсь (крайнего) мнения. Что интрепретер или компилятор не имеют абсолютно никакого отношения к языку и что языки следует рассматривать так же абстрактно. Как красный цвет. А не как горшок с красной краской. CGS 19:20, 13 мая 2004 (UTC).
Я чувствую себя совсем по-другому. Хотя я понимаю разницу между языком и тем. Как он используется. Понимание того. Как этот язык обычно используется (в смысле того. Обычно ли он компилируется или интерпретируется и т. Д.), Имеет решающее значение для понимания того. Что это такое. В случае этой статьи я думаю. Что было бы ошибкой не упомянуть в обсуждении независимости от платформы, что java обычно компилируется в независимый от платформы байт-код и что байт-код выполняется на JVM (с возможностью использования JIT). —BK 65.213.77.129 14:24, 9 сентября 2005 (UTC)

Удалена инструкция

Это появилось в одной из статей. И я действительно не думаю. Что это энциклопедическое содержание. Это действительно больше инструкция для нас, писателей. Поэтому я просто оставлю ее здесь в разговоре.:

Java является торговой маркой Sun Microsystems. Как и все торговые марки, Правильно: Для получения дополнительной информации посетите политику товарных знаков Sun.


Версии JDK

Как нижеприведенная версия JDK относится к так называемой

  • JDK 1.0, 1995
  • JDK 1.1
  • JDK 1.2
  • JDK 1.3
  • JDK 1.4, 2002
  • JDK 2.0, 2003

Я понимаю. Что все 1.2 и выше-это Вот страница Java 2: [2]

Что это за JDK 2.0???? Последняя версия 1.5 Enochlau

—JDK-это SDK-это API. А полный набор-это платформа—

Привет! Пожалуйста. Поправьте меня. Если я ошибаюсь.

Для большинства разработчиков программного обеспечения JDK (Java Development Kit) — это не что иное, как SDK. Но на языке Java. SDK обычно предоставляются компанией на коммерческой основе. Их также обычно называют АПИСАМИ. Полный набор. Позволяющий вам программировать. Обычно называют платформами. Было бы хорошо обратиться к java.sun.com… Пока же я считаю. Что JDK 2-это Java 2 и то же самое. Что Java 1.2 . Jondel

  • Java 2-это java 1.2 up. Изменение было сделано с тех пор. Как там произошли значительные изменения в java API. dns

JDK 1.5 называется Java 5.0 и J2SE 5.0 — я знаю. Что это сбивает с толку. Но именно так называется последняя версия. J2SE/J2ME/J2EE 5.0 на самом деле.. Причина, по которой они передумали и назвали его J2SE 5.0 вместо J2SE 1.5, заключалась в том. Что это было такое большое улучшение по сравнению с предыдущими версиями. Та же идея, что и тогда. Когда они увеличили платформу с Java до Java 2 на 1.2..

Версии
JDK Ява Платформа
1.0 1.0 1
1.1 1.1 1
1.2 1.2 2
1.3 1.3 2
1.4 1.4 2
1.5 5.0 2

Говоря о версиях, я считаю. Что Java Web Start был выпущен где-то в 2000 году, то есть примерно в версии 1.3.1, если это имеет значение. Статья: Анонс технологии Java Web Start

Если вы хотите еще больше путаницы: не будет никаких Вместо этого они будут называться А сокращать его См. Статью Sun об именовании. Weregerbil 15:25, 17 января 2006 (UTC)

Неугодная фразировка

Я возражаю против фразы Это бессмысленно и бесполезно. Однако я уже удалил его один раз. И автор снова вставил его. Я не настолько ненавижу его. Чтобы снова удалить. Поэтому оставлю это мудрым редакторам Википедии.


Языковые средства

— О каких

Может быть, динамическая загрузка класса? —Doradus 21:51, 13 августа 2003 (UTC)
Который на самом деле не является частью языка. Как определено в http://java.sun.com/docs/books/jls/index.html Отражение полностью обеспечивается библиотеками классов. Если мы откроем его до этого. То C может сделать то же самое.
Нет, динамическая загрузка класса не является отражением. Две разные вещи. Динамическая загрузка классов является частью языка Java. См. http://java.sun.com/docs/books/jls/second_edition/html/execution.doc.html#44459 Он гораздо более распространен и интегрирован в Java. Чем в C; фактически все классы в Java загружаются динамически.
Именно так работает виртуальная машина Java, а не язык программирования Java. Конечно, они невероятно запутаны. Но я чувствую. Что могу смело провести черту и сказать. Что динамическая нагрузка. О которой вы говорите. Не является частью языка. (Я. Конечно, надеюсь. Что родные реализации языка программирования Java не будут делать то же самое!)
Хорошо, а что будет. Когда я скажу Я думаю. Что так же работает VM, а не язык? Честно говоря. Мы можем спорить об этом весь день. Но если вы действительно не думаете. Что динамическая загрузка классов является фундаментальной частью языка Java. То, возможно. Мы просто должны согласиться не согласиться. Как вы говорите ниже, это не так важно. —Doradus 13:08, 19 Aug 2003 (UTC)
Кроме того. Тот факт, что языковая функция реализована в библиотеке, является просто хорошим дизайном и не означает, что эта функция не является частью языка. —Doradus 15:52, 18 августа 2003 (UTC)
Я бы сказал. Что они являются частью языка Си. Потому что они влияют на синтаксис. ИМО, что-то не является частью языка до тех пор. Пока не появятся связанные с ним синтаксические элементы. До этого момента я могу избавиться от него и заменить его. Это очень далеко от того. Чтобы быть чем-то. Что имеет какое-либо отношение к языковым средствам для создания сетей. Как динамическая загрузка классов языка программирования Java (если таковые имеются. Относящиеся к этому языку. А не к его реализации) отличает его сетевые средства от другого языка настолько. Что о них стоит упомянуть?
Поскольку IIRC вся мотивация добавления динамической загрузки классов заключалась в том. Чтобы позволить программам загружаться и запускаться постепенно по сети. —Doradus 13:08, 19 августа 2003 (UTC)

Java не была разработана с целью Если вы не удовлетворены достижением этих целей Java. Беспристрастное обсуждение того. Как и почему эти цели не полностью достигнуты. Должно следовать за их подробным описанием.


Линк безеркер

Кто-то совсем безерк со ссылками: [3]. Серьезно, нужны ли ссылки на

Это изменение должно быть поддержано. К сожалению. За это время произошли изменения.

Возможно, нам нужно защитить эту страницу до тех пор. Пока не будет сделано обратное и не будут включены последующие изменения. Но жаль. Что чей-то труд пойдет впустую. Jay 14:00, 9 декабря 2003 (UTC)

Был сделан возврат и слияние более поздних редакций. (См. Википедию:Делайте ссылки только на контекст для справки). Jay 14:30, 9 декабря 2003 (UTC)

Должны ли мы показывать здесь логотип Java без разрешения? Веб-сайт логотипа Sun http://logos.sun.com говорит. Что условия очень строгие для использования его логотипов. Jay 14:10, 18 марта 2004 (UTC)

Я бы сказал. Что нет — логотип должен быть удален. RedWolf 01:15, 19 марта 2004 (UTC)

Прочитав соглашение об использовании логотипов Java, я не верю. Что Википедия может использовать логотип Java на своем сайте. Если это не одобрено Sun MicroSystems. Поэтому я собираюсь удалить логотип из статьи.

Также смотрите: http://www.sun.com/policies/trademarks/#20a

RedWolf 02:36, 19 марта 2004 (UTC)

Wikipedia:Logos заявляет: Нет необходимости запрашивать официальное разрешение у корпорации перед использованием ее логотипа. Если использование является добросовестным использованием. Не создает никакого впечатления. Что логотип связан с Википедией или статьей. В которой он появляется. Или одобряет ее. И не создает никаких разумных оснований для жалобы владельца товарного знака. Цель приведенных выше конкретных руководящих принципов состоит в том. Чтобы соответствовать этим условиям Fredrik 14:19, 19 марта 2004 (UTC)

Если логотип Java можно использовать в Википедии. То почему он не был должным образом обработан в соответствии с Wikipedia:Logos? Например, шаблонный текст на странице описания изображения и подпись к изображению? RedWolf 17:52, 19 марта 2004 (UTC)

Не спрашивайте меня. Я не загружал и не вставлял его в первую очередь… Я просто заменил изображение низкого качества на лучшее. Если удаление кажется мне правильным. Я не собираюсь дальше защищать это дело. Фредрик 19:46, 19 марта 2004 (UTC)


Запутанная терминология

Из статьи: Это не следует путать с

сломать этикетку; 

и

продолжить метку; 

операторы в C и C++. Которые функционируют идентично goto.

Как пользователь C++. Я очень смущен. Так как эти операторы не существуют в стандартном C/C++. Я удалил эту часть. Может быть, автор имел в виду какое-то нестандартное расширение?

Я согласен. Операторы Только на Java у них есть такая метка. —DavidCary 17:45, 19 октября 2004 (UTC)


Описывать языковые конструкции или нет?

Я твердо убежден. Что статьи о языках программирования должны быть сосредоточены на их развитии и истории. А также на том. Что отличает этот язык от всех остальных. Эта статья делает большую работу по изложению этих вещей. Однако, как программист с eir руками в нескольких других дисциплинах, я думаю. Что такая статья не является местом. Чтобы вдаваться в какие-либо подробности о языковых конструкциях. Я лично бегло просматриваю такие описания. И читатель. Не являющийся l33t. Наверняка сделает то же самое. Тонкости, скажем. Обработки исключений или манипулирования строками просто не могут быть переданы в одном или даже десяти абзацах текста в статье Википедии. Кроме того,

Таким образом. Программистам не нужна синтаксическая информация (она у них уже есть). А непрограммистам она не нужна. Я действительно думаю. Что программа

Тем не менее, возможно. Статьи о языках программирования должны ссылаться на статьи. Которые более подробно освещают их конкретные синтаксические или семантические нюансы. Или ссылаться на Викибуки.

Дживс 14:35, 25 марта 2004 (UTC)

Я полностью с вами согласен. Я очень удивлен. Что в статье не упоминаются такие важные вопросы. Как открытый источник Java и такие инструменты. Как проекты gcj и classpath, а также просто синтаксические объяснения циклов. Никогда не стесняйтесь вносить изменения. В большинстве случаев это выглядит плохо для вас, потому что это плохо. — Таку 05:16, 28 марта 2004 (UTC)

Такуямурата редактирует

Это касается 2 правок пользователя:TakuyaMurata.

  • Тот, что с комментарием Если он был перемещен. Пожалуйста. Укажите новое название статьи. Если он был удален на основе приведенного выше обсуждения. То я не согласен. Синтаксис языка так же важен для статьи. Как и все остальное.

Jay 07:05, 28 марта 2004 (UTC)

  • Я не согласен с изменениями. Эта статья стала полнометражной статьей со всей этой информацией. Я думаю. Что мы должны. По крайней мере. Добавить материал о версиях еще в. Саша Слуцкер 12:51, 28 марта 2004 (UTC)

Ладно, вы оба, почему? Как обсуждалось выше. Нет никаких оснований подробно останавливаться на синтаксисе. Википедия — это не руководство по языку. Кроме того, раздел синтаксиса языка ужасно неполон. Я настроил новую статью так. Чтобы поместить ее в VfD. Дайте нам комментарии. Также нет никаких оснований предоставлять подробную информацию о том. Какая версия поддерживает какие платформы. Я знаю. Что она была опубликована, но я только что улучшил статью, устранив избыточность. — Taku 15:09, 28 марта 2004 (UTC)

Что это значит :
Почему вы думаете, что
Избыточность не является проблемой до тех пор. Пока одна и та же информация представлена по-разному. Маркированный список полезен. Когда читатель хочет небрежно просмотреть длинную статью. Jay 15:35, 28 марта 2004 (UTC)
Я переместил некоторую синтаксическую информацию в краткий обзор синтаксиса Java. Извините, что забыл упомянуть. Вопрос в следующем: действительно ли полезна таблица версий по годам? В разделе истории все еще упоминается. Когда была выпущена каждая версия. И не требуется много времени. Чтобы просмотреть этот раздел. — Таку 15:49, 28 марта 2004 (UTC)
Нет никаких причин удалять маркированную информацию. Это было очень полезно. Я кладу его обратно. Пожалуйста. Не вынимайте его снова. Саша Слуцкер 23:29, 28 марта 2004 (UTC)

Опрос

Я предлагаю вернуть эту статью в том виде. В котором она была до изменений Таку от 28 марта и позже. На том основании. Что содержание. Которое было удалено или изменено. Сделало статью значительно менее полезной. Если есть что-то. Что Таку хочет удалить. Таку может сначала попытаться найти консенсус для изменений. Пожалуйста. Укажите свою поддержку или несогласие. Jamesday 15:26, 6 апреля 2004 (UTC)

Можете ли вы указать. Как это сделать? Вы имеете в виду синтаксис Java? — Taku 16:05, Apr 6, 2004 (UTC)
Разделы:

  • Структуры управления
  • Неструктурированный контроль (ранние выходы из циклов и методы порций)
  • Таблица примитивных типов данных
  • Вход/выход
То есть то. Что Джей и Саша. По-видимому. Возражают против удаления чуть выше этого опроса. Удаление лишило нас возможности сравнивать возможности управления и обработки данных этого языка с возможностями других. Jamesday 20:06, 6 апреля 2004 (UTC)

Поддержка:

  1. Jamesday 15:26, 6 апреля 2004 (UTC)

Противопоставлять:

  1. Кевин Сафф 16:10, 6 апреля 2004 (UTC). Я не вижу, что было Во всяком случае, я думаю. Что теперь эту историю следует разбить на отдельную статью История языка программирования Java
Я думаю. Что он имеет в виду этот [4], хотя я все еще не уверен. Что он имеет в виду под модифицированным или значительно менее полезным. — Taku 16:18, 6 апреля 2004 (UTC)

Я понимаю. Я не смотрел правки до 28 марта. Так как он упомянул только 28 марта и позже. Я думаю. Что эта информация могла бы войти в Синтаксис языка программирования Java, если бы он еще не существовал. Как другие длинные статьи о языке программирования имеют дело с конкретным синтаксисом? Кевин Сафф 16:27, 6 апреля 2004 (UTC)

Это бывает по-разному. C имеет его в синтаксисе C, но очень мало о самом языке в основной статье C. Этот (Java) был гораздо более информативным. Основная статья на языке Си выглядит довольно слабо. Описывая историю и тому подобное. Но не сам язык. В какой-то момент я посмотрю и посмотрю. Как поместить описание языка Си в основную статью. А историю-во вспомогательную. Jamesday 20:37, 6 апреля 2004 (UTC)

Я вижу; это похоже на философскую битву за то. Что синтаксис или история языка более фундаментальны. Что плохого в том. Чтобы поместить обзор в основную статью и создать отдельные статьи для каждой? Такие языки. Как C и Java. Безусловно. Кажутся достаточно важными. Чтобы оправдать несколько статей. Помещение всего синтаксиса в основную статью, по-видимому, ограничивает то, что можно сказать о нем (например, историю и разборчивость синтаксиса, что довольно интересно для языка Си!) Kevin Saff 22:55, 6 апреля 2004 (UTC)

Полностью за. Давай сделаем это. Дживс 08:28, 7 апреля 2004 (UTC)

Воздержаться:

  1. Таку 16:05, 6 апреля 2004 (UTC)

Комментарии:

  • Опрос бессмыслен. Потому что всякий раз. Когда мы возвращаемся к какой-либо версии, кто-то. Включая меня. Сделает еще одно редактирование. Которое может противоречить возвращенной версии.
  • Опрос бессмыслен, потому что это вики, а не демократия.
  • См. Обсуждение:Синтаксис Java. Пользователь:Фредрик предложил включить информацию. Связанную с синтаксисом. В семейство фигурных скобок. Хотя я не могу представить. Как это можно сделать. Я был бы счастлив. Если бы он или кто-то другой сделал это. Jay 19:46, 7 апреля 2004 (UTC)

Произношение

Указывает ли Sun. Как должно произноситься слово Мерриам-Уэбстер [5] говорит. Что и Я всегда слышал и использовал вторую форму. Но мой коллега использует первую версию. И это сводит меня с ума! Действительно ли Солнце диктует, как они ожидают, что оно будет фонетизировано? —Веснушчатая нога 16:19, 16 апреля 2004 (UTC)

Американцы склонны произносить его Jova (Канадцы обычно говорят это с твердым Джеймс Гослинг. Изобретатель Java, канадец. Живущий в США. Который произносит его Jova.

Steve-o 03:27, 17 апреля 2004 (UTC)

Как в Ни то. Ни другое не кажется мне правильным. В Новой Зеландии мы используем звук Думая о канадском произношении. Может быть. Именно это вы и подразумеваете под Мы используем очень сильный звук в теле и парке. Так что это может сбить с толку.

Проще говоря. Я произношу Яву в рифму с лавой. И это имеет для меня смысл. Предположительно. Индонезиец смог бы дать наиболее точное произношение. Или я делаю неверные предположения об этимологии этого имени.

Использование

Бен Арнольд

Это потому. Что американцы говорят. Что тело. Как baaahhdeeeДиспрозия 11:21, 25 апреля 2004 (UTC)
Ну, я произношу яву с буквой Если подумать. Я говорю не Я не говорю hove. Я говорю have (хотя я фанат Jay-Z:)). Так что это произносится ява. А не джова. Это именно то. Что я говорю и что я слышал здесь. В Юго-Западном Онтарио (2 цента от викимембера на тренировке).

204.101.190.5 00:42, 7 мая 2004 (UTC)

Небольшой раздел об этом в статье может быть интересным. Я живу в Новой Зеландии. Как Бен. И мы произносим его Яхва. Единственный другой способ произнести это. Который я могу придумать. — это Джавва. (Предполагая. Что диспрозия права, говоря. Как граждане США произносят Java как тело.) )

В первом абзаце статьи Java-программы являются переносимыми с точки зрения их спецификации. Потому что язык (за некоторыми исключениями. Такими как jni) не зависит от формы базовой архитектуры. Компиляция программ в JVM дает вам переносимый двоичный транспортный уровень. Но это принципиально не имеет отношения к самой Java и к переносимости Java — программ.


Я живу в Германии. И я (хотя у меня довольно ограниченные способности по-английски 😉 ) произнес бы его как *yarwa* с буквой

Цитата о Java

Smalltalk в сочетании с простой элегантностью C++

Аудитория и контекст.

Привет,

Я новичок на этом сайте и имею большой профессиональный интерес к языку программирования Java.

У меня есть две проблемы. Которые могли бы попасть в область сильной критики в отношении текста на сегодняшний день.

Во-первых, нет ничего плохого в тексте как таковом. Однако мне трудно определить. Кому эта аудитория пишется. Это техническое сообщество разработчиков Java-программирования? или мир в целом. Любая из этих аудиторий столкнулась бы с трудностями при чтении этой статьи. Это особенно сложный вопрос из-за того. Что я смог выделить несколько различных и разрозненных аудиторий. Каждая из которых требовала много различных точек зрения.

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

Я вижу основу того. Что было написано. Как реальную ценность в том. Чтобы иметь дело со сложностью Java и сообщать об этом тем. Кто хочет или должен знать. Поскольку Ява продолжает расширяться и становится все более и более повседневной

Спасибо

Разделите это. JRE и JDK разделены

Я думаю. Что раздел Java Runtime Environment должен иметь свою собственную статью. Такую же. Как и комплект разработчика. Что мы могли бы сделать. Так это сделать рекламу на нем в этой статье и иметь там См.Также: Java runtime environment.

Причина, по которой я предлагаю разделить его. Заключается в том. Что язык программирования java. Среда выполнения java и набор разработчика java-это три разные вещи/идеи. Это может прояснить ситуацию. —ShaunMacPherson 05:11, 5 ноября 2004 (UTC)

Я уже начал с этого. [[Пользователь:Smyth|– Smyth]] 13:12, 13 ноября 2004 (UTC)

JVM и JRE

В чем же разница между ними ??. 😕

JVM-это общий термин, см. JRE конкретно относится к продукту Sun. Включающему в себя их собственную реализацию JVM и собственную реализацию Java API. [[Пользователь:Smyth|– Smyth]] 13:13, 13 ноября 2004 (UTC)

JDK включает в себя JRE. JRE включает в себя JVM. JDK доступен для скачивания разработчиками. JRE доступен для скачивания клиентами. Анвар саадат 03:00, 25 марта 2006 (UTC)

Близко. Анвар саадат. Но не совсем верно. JDK (Он содержит все виды инструментов для создания и построения Java-программ. JRE (Он содержит только компоненты. Необходимые для запуска обычной Java-программы. И поставляется в комплекте с JDK (потому что разработчикам он тоже нужен). Но JVM (Текущий продукт Sun JVM называется На самом деле это вторая попытка Sun создать JVM — их первая попытка была ответственна за большую часть фольклора Но есть и другие JVM. Некоторые из которых лучше работают с Java-программами. Чем Sun HotSpot JVM (например, IBM JVM). И даже Sun в настоящее время предоставляет две по-разному настроенные JVM, доступные из команды РоссПаттерсон 03:42, 25 марта 2006 (UTC)

Ответы на язык Java устарели

Жалобы на сборники и кастинг и т. Д. В этом разделе устарели с generics & auto-unboxing в v1.5 (которые обсуждаются в следующем разделе). И я не вижу никакой другой точки в этом разделе. Но чувствую. Что если я удалю его. Он будет заменен. Кто-нибудь хочет его починить?

Не обязательно все используют Java 1.5, и поэтому проблемы все еще остаются. Конечно, было бы неплохо добавить некоторые упоминания о том. Что они были исправлены с выпуском 1.5. — Таку 18:57, 12 ноября 2004 (UTC)

Я добавил версии 5.0. Хотя раздел Java IO нуждается в некотором подобном обращении. Почему я сосредотачиваюсь на IO по всей Java, мне кажется странным —Calvin 21:33, 16 ноября 2004 (UTC)

Потому что ввод-вывод вроде как жизненно важен для любого серьезного серверного приложения? В частности. До nio было невозможно закодировать однопоточное серверное приложение. Управляемое событиями (что. Безусловно. Является лучшим методом для определенных типов серверов) на java. Plugwash 17:51, 22 апреля 2006 (UTC)

Гослинг??

Я думаю. Что в первом абзаце следует либо опустить упоминание о Гослинге. Либо объяснить. Кто он такой. В том виде, как она написана сейчас. Читатель понятия не имеет. Кто такой Гослинг. Пока он или она не продолжит дальше статью. Что сбивает с толку.

Вот абзац, на который я ссылаюсь: Гослинг и его друзья изначально разработали Java. Которая сначала называлась Oak (в честь деревьев за пределами офиса Гослинга). Чтобы заменить C++. Хотя набор функций больше напоминает Objective C.

Произношение, Раунд 2

Это было истории раздел должен нести произношение примечание о том. Что Java-это Кто-нибудь? ADH (t&m) 07:15, 14 января 2005 (UTC)

Я всегда говорю Лучше вообще не упоминать об Диспрозия 07:19, 14 января 2005 (UTC)
То же самое здесь. Я бы произнес это /ˈdʒɑvə/, а не / ˈdʒævə/. Питер О. (Разговор) 07:51, 14 января 2005 (UTC)

Мой плохой, я думал. Что большинство было за

Хотя, вероятно. Не часто встречается среди носителей английского языка, я слышал. Что Java произносится как /java/ (в Нидерландах и Польше) (т. Е. Английское написание Насколько это согласуется с яванским произношением? И насколько распространено это произнесение в Европе? (т. е. по-немецки)

Наверное, излишне говорить, но в Японии — Таку 17:54, 2 апреля 2005 (UTC)

Я только что приземлился на осиротевшую статью Strictfp по случайной ссылке. Я викифицировал его и добавил в категорию:язык программирования Java, но это могло бы сделать с помощью ссылки откуда-то. Беда в том. Что я не знаю. Где это будет уместно — или даже если это уместно. Чтобы сохранить его как самостоятельную статью. Или должно быть где-то объединено (но я не знаю. Где это будет уместно). Я думал о том. Чтобы оставить его. Но я недостаточно знаю об этом предмете. Чтобы знать. Действительно ли он стоит того. Чтобы его сохранить или нет. Я помещаю это здесь. Потому что в качестве избранной статьи эта дискуссионная страница, вероятно. Будет находиться в списках наблюдения людей. Которые знают. О чем они говорят! Thryduulf 15:14, 2 апреля 2005 (UTC)

Я добавил ссылку на strictfp, которая упоминается в истории версий языка программирования Java#. —MarkSweep 18:20, 2 апреля 2005 (UTC)

Правки 67.118.123.235

Еще одно массовое удаление. Пожалуйста. Сначала обсудите большие изменения здесь и получите правильную версию. Пожалуйста :*)

Calvin 22:17, 19 апреля 2005 (UTC)

Запрос ссылок

Привет, я работаю над тем. Чтобы поощрять реализацию целей Википедии:Политика проверяемости. Часть этого заключается в том. Чтобы убедиться. Что статьи ссылаются на свои источники. Это особенно важно для избранных статей. Поскольку они являются заметной частью Википедии. Проект Проверки фактов и ссылок содержит больше информации. Спасибо, и, пожалуйста, оставьте мне сообщение, когда несколько ссылок будут добавлены в статью. — Налоговик 19:35, 22 апреля 2005 (UTC)

Комментарии. Которые были добавлены к статье. Касающейся контроля Солнца. Являются поверхностными и отражают поверхностное понимание JCP и исторической ситуации. В то время как Sun является ведущим специалистом по многим JSR в области функций платформы J2SE. Это не относится к функциям платформы J2ME и не является необходимой особенностью руководства JCP — expert group в настоящее время разнообразно. Кроме того, право собственности на спецификации всегда разделяется руководителем экспертной группы по практическим соображениям. Поэтому последствия того. Что это плохо в случае Sun. Явно очевидны. Если важно, чтобы эта тема была освещена. Потребуется полное объяснение. И я предлагаю. Чтобы подходящее место для этого было в теме JCP. Что касается противоречий — ну. Это спорно среди тех. Кто этого не понимает! —Webmink 01:49, 25 апреля 2005 (UTC)

Несвободные IDE в разделе

Это было в разделе Я надеюсь. Что кто-то. Кто более эрудирован в этой области, чем я. Будет использовать его повторно!

  • Несвободные ИДЫ
В любом случае. Какой смысл в разделе ИСТМ-это просто раздувание. Которое мало что добавляет к статье; в лучшем случае его следует перенести в отдельную статью. Возражения против того. Чтобы я просто убрал его? Neilc 05:18, 14 июля 2005 (UTC)

Экзамен по программе повышения квалификации

В настоящее время Совет колледжа проводит углубленный вступительный экзамен по информатике, который проверяет знания в области Java и объектно-ориентированного программирования. Экзамен также проверяет знания по тематическому исследованию моделирования морской биологии-программе. Написанной на языке Java. В 2003-2004 учебном году экзамен перешел с C++ на Java в качестве основного языка программирования .

Это, кажется. Было добавлено и удалено несколько раз за всю историю этой статьи. Лично я не думаю. Что это имеет отношение к делу (многие учреждения проводят экзамены по Java. Этот не особенно примечателен). Но если он и должен быть в статье. То уж точно не относится к разделу Я заметил. Что у него изначально был свой собственный курс. Но он, похоже. Был потерян по пути. Я удалил его на данный момент, если кто-то сильно чувствует, что он принадлежит этой статье, пожалуйста, можем ли мы попытаться решить, какой раздел для него подходит? —Batneil 16:39, 24 июля 2005 (UTC)

Именование

Я не думаю. Что язык программирования Java — лучшее название для этой статьи. На самом деле это не так называется. Я предлагаю Java (язык программирования) (в настоящее время редирект) или технологию Java (которая используется [6]. violet/riga (t) 12:36, 28 июля 2005 (UTC)

Большинство статей по языкам программирования следуют формату Диспрозия 12:40, 28 июля 2005 (UTC)

Ты прав. Многие так и делают. Я думаю. Что для них всех было бы лучше иметь его как Тогда, я думаю, лучше оставить его здесь, так как он должен быть последовательным. violet/riga (t) 12:43, 28 июля 2005 (UTC)

публичный, абстрактный. Статичный и окончательный

Я вытащил следующий абзац из раздела об интерфейсах и классах (извините. Я забыл войти в систему перед внесением изменений):

Методы, определяемые интерфейсом. Неявно являются общедоступными и абстрактными. Поля , определенные интерфейсом . Неявно являются общедоступными, статическимии конечными.

Без объяснения значений публичного. Абстрактного. Статического и окончательного этот абзац мало что добавляет. Но добавление объяснений означало бы добавление деталей. А этот абзац. По-видимому. Уже содержит слишком много деталей. Марк Харрисон 06:28, 11 августа 2005 (UTC)

Примеры кода. В частности новый цикл for

Вряд ли пользователь будет иметь отношение к виджетам и ящикам. Это должно быть изменено на for(Элемент e: list)…

Имя Fred для класса. Реализующего Deletable. Также плохо. Это должно быть изменено на что-то вроде раздела, что-то. Что на самом деле будет удалено. Вы не удалили бы Фреда.

Другие плохие примеры включают метод deleteAll. Он должен использовать список вместо массива и должен использовать для каждого цикла.

Токлеф

Эта статья является идеальным кандидатом на {{TOCleft}}. Я нахожу огромное количество пробелов очень расточительным.

Сравните, если хотите:
Без TOCleft: Java-without_TOCleft.png
С TOCleft: Java-with_TOCleft.png

Что все думают? ¦ Reisio 00:29, 2005 24 августа (UTC)

Вперед —Rogerd 03:12, 24 августа 2005 (UTC)

многословие и типизация

Недавняя правка этой статьи утверждала. Что Это неправильно:

  • строго типизированные языки вообще не нуждаются в явных аннотациях типа. Согласно большинству определений строгого типа. Возможно, автор имел в виду статически типизированных.
  • статически типизированные языки также не обязательно требуют явных аннотаций типа: компилятор просто должен иметь возможность выводить информацию о типе во время компиляции. ML и Haskell являются двумя примерами статически типизированных языков. В которых объявления типов являются необычными (большинство типов автоматически выводятся компилятором).

IMHO есть больше к Neilc 20:35, 30 августа 2005 (UTC)

Я думаю. Что мы согласны с тем. Что я считаю главной проблемой… что объявления типов не являются основным фактором многословия Java. У меня нет никаких проблем. Если кто-то хочет поговорить о многословии Java или любом другом воспринимаемом недостатке. Я просто чувствую. Что мы должны точно отразить то. Что уникально для Java. А не то. Что является парадигмой. Которую кто-то нашел бы проблематичной в любом языке. Например, см. предыдущее возражение против геттеров и сеттеров. А также возражение. Что Java не является процедурным языком программирования. Ворона Хоккайдо 21:26, 30 августа 2005 (UTC)

Свойства

Привет. В попытке прояснить то. Что я думал. Было одним из возражений других редакторов против Java. Я написал это:

Свойства — открытые поля. Которые привязаны к коду. А не непосредственно к данным — не поддерживаются в Java. Более подробное соглашение. Включающее методы get и set. Популярно и имеет существенную инструментальную поддержку.

Ворона Хоккайдо вернула мое редактирование с комментарием , у которого, похоже. Есть проблемы с фактичностью, но он не уточнил. Каковы фактические проблемы?

Бен Арнольд 22:14, 30 августа 2005 (UTC)

Java имеет публичные свойства

Я хотел бы обсудить чье-то утверждение о том. Что Java не имеет публичных свойств и что для нее требуются средства доступа. В Java можно объявить все ваши свойства общедоступными и никогда не требовать get/set для манипулирования ими. Если вы этого не хотите. Аксессоры-это просто условность. А не языковое требование. Эта конвенция совершенно необязательна и может соблюдаться на любом языке. Если я неправильно понял возражение. Пожалуйста. Поправьте меня. Но эти основные факты должны быть ясны. Ворона Хоккайдо 20:31, 26 августа 2005 (UTC)


Я не думаю. Что это то. На что ссылался предыдущий плакат. В java вы не можете определить Ваш ответ работает только в том случае. Если вам нужно свойство чтения/записи. Но не работает ни для чего другого.

Для сравнения. В C# мы можем написать:

//... публичная строка ReadOnlyProperty { получить { публичная строка WriteOnlyProperty { набор { public string ReadWriteProperty { получить { вернуть кое-что; } набор { //.... 

что дает нам такой синтаксис как: string s = o.ReadOnly; // o.ReadOnly =

string s = o.ReadWrite; // Reading ok o.ReadWrite =

Я не уверен. Что Java 1.5 добавляет что-то подобное к языку Java. Это не кажется строго необходимым. Но очень полезно. Хотя иногда мне жаль. Что у меня нет публичного геттера и частного/защищенного сеттера. 🙁

OracleofTroy 01:34, 3 сентября 2005 (UTC)


Придешь еще? Во-первых, пример. Который вы показали выше. Кажется специфичным для C# и, возможно. Даже уникальным для C#. Я не думаю. Что определение Во-вторых. В Java легко можно иметь публичный геттер и частный/защищенный сеттер. Вот как это работает (далее следует тривиальный непроверенный код):

демонстрация публичного класса { // Частные переменные могут быть доступны только с помощью методов private static String readOnlyStuff = // Но только этот класс может писать в него. 

получение синтаксиса типа:

Демо d = новая демо(); String stuff = d.readStuff(); // нет проблем d.writeStuff(

Подход C# интересен и. По-видимому. Позволяет вам иметь ограничения безопасности. Не заставляя клиентов вызывать аксессоры. Но не обманывайтесь. Аксессоры все еще существуют и работают на основе соглашения об именах вуду. Для незначительного удобства. Позволяющего клиентам избегать вызова аксессоров. Вы получаете неудобство от удвоения числа аксессоров и введения шатких соглашений об именах. .

Я не думаю. Что уместно брать уникальную особенность C# и называть ее критикой Java. Особенно когда Java может выполнить то же самое намерение. Используя свой собственный набор функций. Но если бы большинство других языков обладало этой специфической особенностью. Или язык не обладал бы какой-либо способностью для осуществления этого намерения. То его отсутствие могло бы быть законным поводом для критики. Ворона Хоккайдо 21:43, 6 сентября 2005 (UTC)


Delphi и freepascal также имеют свойства. Которые выглядят как поля. Но на самом деле вызывают вызовы методов. C++ не имеет их изначально. Но я слышал. Что есть способы использовать перегрузку операторов для их добавления. Как только вы привыкли использовать свойства. Переходящие на язык. Где вы должны вручную вызывать геттеры и сеттеры. Все время становится настоящей питой. Plugwash 23:00, 22 апреля 2006 (UTC)

Примеры кода

Я думаю. Что в этой статье нужны примеры кода. Выходящие за рамки hello world (который в большинстве случаев мало что говорит о языке). Особенно для Java как объектно-ориентированного языка, кажется. Стоит иметь пример. Который каким-то образом показывает. Как реализуются классы.

По этой причине я повторно вставил пример. Удаленный Neilc. Конечно, мы можем обсудить. Какой более длинный пример включить. Поэтому это просто следует рассматривать как заполнитель для более длинного примера. Хирцель 07:37, 24 октября 2005 (UTC)

Но это действительно ужасный пример. Полный ошибок в терминологии и не демонстрирующий ничего полезного о языке или ОО в целом. С чего начать? —Найджел 19:00, 24 октября 2005 (UTC)
Если вы настаиваете на том. Чтобы оставить его себе. Не могли бы вы сделать так. Чтобы он меньше сосал? Потому что текущая версия довольно плоха. Neilc 04:15, 25 октября 2005 (UTC)
В этом обсуждении я снова удалил примеры. Если кто-то действительно хочет сохранить их. Пожалуйста. Улучшите их. Прежде чем просто слепо добавлять их на страницу (но я склонен согласиться с пользователем:MarkSweep, что пример действительно не нужен. По крайней мере. На главной странице статьи). Neilc 13:14, 26 октября 2005 (UTC)
Я согласен с Найджелом и Нейлком. Примеры кода. Которые были недавно вставлены. Удалены и повторно вставлены. Являются довольно дилетантскими (Я бы не возражал против программы Hello world program#Java, и мы уже об этом позаботились). Но настоящие примеры лучше подходят (после некоторой необходимой очистки) для Я бы предпочел свести примеры кода к минимуму, если только они не служат для иллюстрации конкретных языковых конструкций (например, обобщенного цикла for), а не для общих уроков объектной ориентации. —MarkSweep 04:49, 25 октября 2005 (UTC)

С++?

Я нахожу. Что все сравнения с C++ дают ошибочное объяснение работы последних.

Автоматическая сборка мусора

Одним из возможных аргументов против таких языков. Как C++, является бремя ручного управления памятью. В C++ память выделяется программистом для создания объекта. А затем освобождается для удаления объекта. Если программист забывает или не уверен. Когда освободить место . Это может привести к утечке памяти, когда программа потребляет все больше и больше памяти. Не очищая после себя. Еще хуже, если область памяти освобождается дважды. Программа может стать нестабильной и. Скорее всего. Потерпит крах.

В C++ есть два различных типа памяти. Память для автоматических объектов. Которая обрабатывается языком. И динамическая память. Которая обрабатывается программистом. Все это требует правильно написанного конструктора и метода деструктора для каждого класса. Который использует

  • И наоборот, программистов С++ можно спутать с Java. Потому что в Java примитивы всегда являются автоматическими переменными и объекты всегда находятся в куче. Тогда как программистам С++ явно предоставляется выбор в обоих случаях с помощью указателей.

Еще одна распространенная ошибка Java. Тип памяти и способ обращения к ней различны. В Java объекты действительно являются указателями. На которые автоматически ссылаются. А примитивные типы-ссылками. В C++ все типы обрабатываются точно так же. Вы можете иметь указатели. Указывающие на автоматическую или динамическую память. И то же самое для ссылок. Следовательно, указателейMarSch 14:21, 27 October 2005 (UTC)

Введение не очень хорошо

Резюме нужно больше информации о том. Что такое Java. А не все это об истории и о том. Кто ее делает. Что-то о том. Что делает Java speical, это популярность, использование commons, —Apoc2400 07:09, 9 декабря 2005 (UTC)

Я согласен. Знакомство просто ужасное. Я удалил некоторые из самых непонятных мелочи (Ли охотник 01:08, 18 декабря 2005 (мирового)

Изобретатели

Патрик Нотон утверждал в статье журнала Forbes. Которую он написал. Что начал проект Java (связанный с его биографией Wiki). Стоит ли об этом упоминать в этой статье?

Цитата:

 Я начал проект Java в Sun Microsystems 5 декабря 1990 года. 

Brianhe 07:46, 17 декабря 2005 (UTC)

Лицензия Java

Является ли Java открытым исходным кодом? По какой лицензии распространяется Java? Например, язык Си является международным стандартом. Поэтому каждый может разработать собственный компилятор/компоновщик/IDE языка Си. Как насчет Java в этом контексте? —Abdull 13:50, 17 декабря 2005 (UTC)

Если память работает. Стандарт Java открыт; имплиментация виртуальной машины Java Sun-нет. Raul654 16:28, 17 декабря 2005 (UTC)

Токлеф

Добавлено TOCleft (статья трудно читается иначе)

Я-анон выше. Не все бегают на 1280х1024. —DCrazy talk/contrib 17:11, 18 декабря 2005 (UTC)

Во введении говорится. Что Java — это вариант C++ с Насколько я знаю. C++ не имеет никакой среды выполнения. Кроме самой операционной системы. На которой также работает JVM. Мы можем исправить эту маленькую ошибку?

—Duke 71.198.170.40 21:26, 20 декабря 2005 (UTC)

Должны ли платформы быть перечислены в Infobox?

Должна ли Microsoft .NET, программная платформа. Быть указана под влиянием в информационном поле? Я добавил C#, который является реальным влиянием языка Java. .NET должен быть указан как программная платформа , на которую влияет платформа Java, а не язык. Я оставил .NET в информационном поле на данный момент, но если нет возражений, я намерен удалить его. — Doug Bell 18:40, 10 января 2006 (UTC)

.NET более сопоставим с J2EE (и конкурирует с ним). Я согласен с вашим удалением. Ohnoitsjamie 18:42, 10 января 2006 (UTC)
Flash 02:29, 11 Января 2006 (UTC)

Удалена .NET из под влияния, добавлена цель C под влиянием.— Doug Bell talk/contrib 19:21, 11 января 2006 (UTC)

Самоподдерживающееся управление сложностью?

Первая пуля под критикой-это:

  • Не все проекты или среды требуют сложности корпоративного уровня. Например автономные веб-сайты или индивидуальные программисты. Такие люди считают самоподдерживающееся управление сложностью Java излишним.

Что именно означает самоподдерживающееся управление сложностью? Если речь идет о Java EE, то это относится к другой статье. Я думаю. Что это утверждение нуждается в уточнении или устранении. – Дуг Белл (talk/contrib) 21:20, 17 января 2006 (UTC)

Организация контента

Я создал подстраницу User:Flash200/Programming-language outlineдля описания и обсуждения реорганизации контента. Которую я делал в последние пару недель для ряда статей на языке программирования. Недавно я попытался переместить историю Java гораздо дальше в этой статье. Но быстро вернул это изменение из-за обратной связи от пары пользователей.

Недавно кто-то изменил статью Python. Поместив философию в начале статьи с комментарием: До сих пор никто не возражал против этого конкретного изменения. И это имело смысл для меня. Будет ли кто-нибудь возражать против размещения истории сразу после философии для статьи Java или для других статей по программированию в целом? Пожалуйста, не стесняйтесь комментировать здесь , на подстраницеили на моей странице разговора (один пользователь уже прокомментировал мою страницу разговора). —Вспышка 23:38, 18 января 2006 (UTC)

Также смотрите Пользователь:Disprosia#location_of_the_history_section. —Ruud 23:44, 18 января 2006 (UTC)
Почти во всех случаях история должна быть прежде всего. Это важно для правильного оформления статьи. Диспрозия 04:08, 19 января 2006 (UTC)
Я начал писать ответ здесь в пользу того. Чтобы поставить философию на первое место. Основываясь на аргументе. Что история редко бывает краткой. В то время как философия должна быть. Однако изучение статьи на Java убедило меня. Что мой аргумент не выдержал. Философия, безусловно. Является более глубоким обсуждением Java и менее вероятно. Будет доступна непрофессиональному читателю. Так что теперь я пошел на 180°, прежде чем даже представить свое дело. – Doug Bell talkcontrib 05:24, 19 января 2006 (UTC)

Перемещение разделов по синтаксису и ресурсам в дочерние статьи

С текущей реорганизацией статьи разделы по синтаксису и ресурсам выделяются теперь как:

  • технические детали вряд ли заинтересуют непрограммистов; и
  • стилистически отличается от остальной части статьи. Являясь в основном повторением информации. Широко доступной в других местах.

Я думаю. Что эти разделы имеют достойное содержание. Но я думаю. Что включение резюме высокого уровня и ссылки на дочернюю статью для каждого из этих разделов затянет статью. – Doug Bell talkcontrib 05:24, 19 января 2006 (UTC)

Я работаю над разделением синтаксического раздела. Но я немного не уверен в том. Где именно провести линию и что оставить позади. Следует ли все. Кроме краткого изложения синтаксиса. Перенести в статью Для статей о синтаксисе C и C основная статья по-прежнему охватывает много вопросов о синтаксисе. И статья о синтаксисе делает гораздо больше. Чем просто перечисление правильных синтаксических выражений.
По крайней мере. Будет ли краткое резюме (перенесение всего остального в статью синтаксиса) адекватным решением? Не обязательно идеальное решение. Но адекватное. Я бы предпочел перенести как можно больше информации о синтаксисе (кроме краткого резюме) в сестринскую статью, чтобы, если кто-то хочет узнать о синтаксисе, он просто перешел к статье о синтаксисе, точка; им не нужно постоянно переходить между двумя статьями. —Flash 18:22, 22 января 2006 (UTC)
Я добавил краткое резюме в начало раздела синтаксиса. Теоретически это все, что останется после создания синтаксической статьи. —Flash 19:59, 22 января 2006 (UTC)
Я бы предпочел как можно больше перейти к детской статье. Однако я также мог видеть некоторую логику в том числе аннотированном примере Hello World в статье программирования Java. Чтобы дать читателю статьи Java вкус синтаксиса. В то время как я мог бы видеть расширение резюме несколько от того. Что вы включили, я бы не расширял его в той же степени. Как статья программирования C. – Doug Bell talkcontrib 21:33, 22 января 2006 (UTC)
Выполнено. Я переместил весь синтаксис. За исключением резюме и примера Hello World, в статью синтаксиса Java. У меня нет никаких планов отделять секцию ресурсов, но я бы не возражал, если бы это сделал кто-то другой. —Flash 00:48, 23 января 2006 (UTC)
Я понимаю. Что эта статья уже слишком длинная. И мы должны обсуждать разделение частей (см. #Moving sections on Syntax and Resources out to child articles), но тем не менее я думаю. Что статья Java 2 Platform. Standard Edition должна быть объединена здесь. Разница между языком Java и платформой Java безнадежно размыта. Вы не можете сколько-нибудь осмысленно обсуждать язык в отсутствие библиотек.
Учтите, что java.lang содержит классы. Которые являются центральными для языка. В статье о языке уже есть значительное обсуждение библиотек. Разделы в статье Java SE. В которых перечислены и обобщены пакеты. Лучше обслуживаются документацией Javadoc API. (Сравните Java SE 10 API Javadocs к списку пакетов в статье—статья является почти полным подмножеством.) Единственное. Что действительно необходимо обсудить в отношении платформы. — это описать различие между платформой и языком и объяснить. Что представляет собой платформа. Я подозреваю. Что это можно сделать в одном абзаце.Doug Bell talkcontrib 11:19, 20 января 2006 (UTC)

На самом деле, что имеет смысл, так это слиться с платформой Java 2, Standard Editionплатформой Java, поэтому я перенес обсуждение туда. – Doug Bell talkcontrib 18:34, 20 января 2006 (UTC)

Операторы и базовый синтаксис

Действительно ли полезно загромождать статью таким базовым синтаксисом? Мы здесь не для того. Чтобы инструктировать пользователя о том. Как написать basic Java. Dysprosia 09:16, 22 января 2006 (UTC)

  • См. Выше Обсуждение о разделении синтаксиса (и, возможно. Ресурсов) на отдельные дочерние статьи.
  • Эти небольшие различия в синтаксисе одного языка к другому имеют такое же отношение к определению того. Что такое язык и чем он отличается от других языков. Как и дискуссии высокого уровня о философии и истории.
  • Детали синтаксиса не пытаются научить кого-то использовать язык, и они не пытаются научить основные понятия программирования (разделы HTH —Flash 17:06, 22 января 2006 (UTC)
Базовый синтаксис почти идентичен синтаксису таких языков. Как Си или Си++. Абзац, отмечающий это сходство, я думаю. Был бы гораздо более плодотворным. Чем повторное объяснение. Что было бы захватывающим и интересным. Так это страница, возможно. Описывающая грамматику Java в формальных формах (EBNF или что-то в этом роде). Диспрозия 05:18, 23 января 2006 (UTC)

Формальную грамматику можно найти в главе синтаксис спецификации языка Java. Мы могли бы сослаться на это, но я не вижу смысла также иметь здесь формальную грамматику. —MarkSweep (call me collect) 06:00, 23 января 2006 (UTC)
Чем более похожи некоторые языки. Тем труднее получить четкое представление о том. Чем они отличаются. И тем более полезным я нахожу перечисление синтаксиса для каждого из них. Например, я изучил PHP. Perl и Bash скрипты примерно в одно и то же время. Все они имеют общую родословную и очень похожий. Но непоследовательный синтаксис. Я нашел неоценимым иметь шпаргалки (краткие списки синтаксиса). Чтобы не путать один язык с другим. То же самое относится к C++ и Java; они очень похожи синтаксически. Но во всем синтаксисе есть несоответствия.
Синтаксические детали имеют большую пользу для некоторых людей. Они энциклопедичны по своей природе (как и формальная грамматика). И они требуют очень мало усилий для создания и поддержания (большая часть из них может быть скопирована и вставлена из других языков. И синтаксис для языка имеет тенденцию меняться очень мало с течением времени). Кроме того, большая часть деталей может быть изолирована на родственных страницах. Не утяжеляя основные статьи. Другими словами. Потребность есть. Она уместна и не мешает ничему другому. Так что я действительно не вижу обратной стороны.
На той же ноте я бы не возражал против включения формальной грамматики. Пока есть хотя бы один человек. Который находит ее полезной. И пока она не отягощает основную статью. Я не думаю. Что легкодоступность информации из других источников или размер целевой аудитории являются достаточным аргументом. Чтобы избежать добавления чего-либо в Википедию. Одним из ключевых качеств Википедии является то что ее содержание есть и останется в свободном доступе. С большинством других источников информации такой гарантии нет. Независимо от того. Насколько они легкодоступны в настоящее время. Добавление энциклопедической информации в Википедию, по сути, гарантирует, что знания не будут потеряны, что они навсегда останутся в руках сообщества. —Flash 20:09, 23 января 2006 (UTC)

Reg Ex

Этот пункт уже не кажется мне очень обоснованным. Хотя упоминание регулярных выражений в J2SE 1.4 приятно. Правда в том. Что Java теперь поддерживает reg ex ничуть не хуже perl или php. Вышеприведенное предложение таково misleading…it кажется, говорят. Что регулярное выражение Java отсутствует. Имея в лучшем случае раннюю. Незначительную поддержку. Это не было моим опытом.

— Марк

Производительность сборки мусора

Пока кто-нибудь не накричал на мою правку…

В статье снова и снова указывается. Что автоматическая сборка мусора может повысить производительность при правильном использовании. Но я думаю. Что это немного вводит в заблуждение. Сама природа автоматической сборки мусора требует дополнительных операций. Чтобы проверить. Является ли данный объект безопасным для удаления, и никогда не может быть столь же эффективным. Как хорошо спланированная ручная сборка мусора. Аргумент состоит в том. Что ручная сборка мусора слишком подвержена ошибкам и трудна для программирования. Но притворяться. Что вы не принимаете удар по производительности для этого удобства,-это дезинформация.

Meekohi 18:30, 8 марта 2006 (UTC)

Возможно, вы захотите ознакомиться со статьей на этой странице обсуждения. Дело в том. Что при использовании поколенческой сборки мусора многие объекты в конечном итоге освобождаются как группа без каких-либо изменений. операции. Необходимые для конкретного объекта. Это контрастирует с ручным освобождением. Которое требует операций управления памятью. Специфичных для конкретного объекта. Чего вам не хватает. Так это того. Что сокращение времени. Затрачиваемого на выполнение освобождения, больше. Чем время, затрачиваемое на определение того, может ли объект быть освобожден. – Doug Bell talkcontrib 19:01, 8 марта 2006 (UTC)

FWIW, каждая JVM ведет себя по-разному. Но если вы хотите. Чтобы ваш Java-апплет реального времени работал на всех широко доступных JVM. Вы должны иметь в виду, что время. Необходимое для сбора мусора. Зависит от количества объектов (а не от их размера). Обычно у нас есть небольшие массивы больших объектов. А не большие массивы маленьких объектов. И это делает трюк. Стивен Би Стритер 10:16, 9 марта 2006 (UTC)

Re: Я не знаком с термином Если это так. Попробуйте провести такой эксперимент: в плотном цикле выделите и свободные объекты. То есть свободные(malloc(16)). Затем напишите эквивалентную Java-программу. Использующую GC. То есть Сравните скорость. Я получаю версию Java в 10 раз быстрее. Чем malloc/free. Поэтому я не уверен. Что слово Какие скорости вы получаете? Weregerbil 11:28, 9 марта 2006 (UTC)

Ладно, я, очевидно. Не собираюсь выигрывать эту битву. Но я хотел бы отметить. Что вышеприведенный тест несправедлив. Вы сравниваете Java GC. Который собирает данные на досуге. С наихудшей настройкой принудительного распределения/освобождения в C. Мне было бы любопытно посмотреть. Что происходит с этой java-программой. Если вы сравнили плотный цикл mallocs с освобождением. Сохраненным до конца программы, или. По крайней мере. Что-то более разумное. Очевидно, что Java побьет идиота-программиста в управлении памятью. Но я все еще считаю. Что это принципиально медленнее. Если оба работают в лучшем виде по причинам. Описанным выше. Meekohi 02:28, 13 марта 2006 (UTC)
Был проведен ряд реальных тестов с реальными приложениями. Не все работают лучше с поколенческим сборщиком мусора по сравнению с ручным освобождением. Но (возможно) удивительное число делает это. Это действительно зависит от того. Сколько недолговечных объектов создается-многие недолговечные объекты благоприятствуют поколенческому сборщику мусора. Поскольку все объекты распределяются в Это определенно не так просто надуманные приложения. Которые приносят пользу. Как выделение, так и освобождение этих недолговечных объектов-усреднение всего лишь пригоршни машинных инструкций каждый—обходятся в сборщике мусора поколений дешевле, чем соответствующие операции в традиционном динамическом управлении памятью, которое имеет дело с фрагментированной памятью. – Doug Bell talkcontrib 05:27, 13 марта 2006 (UTC)

Недавняя история

Я предлагаю внести некоторые улучшения в первый пункт этого раздела.

Ни здесь, ни в предыдущем разделе Интернета еще не упоминается. Что веб-браузеры могут запускать Java как Java-апплеты.

Кроме того, история Microsoft Java более интересна. Чем изображенная здесь. Microsoft назвала свое программное обеспечение Java и Microsoft нарушали торговую марку Sun. Называя ее Java. Первая версия Windows без Влияние этого решения на современную установленную базу уже давно в значительной степени угасло. На самом деле производители вмешались и в течение нескольких лет поставляли Java вместе со своими коробками Windows. Mac OS X и Linux. Как они поставляют, например. Жесткие диски — в течение некоторого времени доставка Java не имела ничего общего с Microsoft.

Flash работает хорошо. Но это, похоже. Не за счет Java. По крайней мере. В Великобритании люди использовали Flash для веб-сайтов еще в 2000 году и не проявляли склонности переключаться на Java для этой цели. Однако я сомневаюсь. Что Java сама по себе уменьшается. 90% людей. Которые ходят сюда можете посмотреть видео на Java. Эта цифра была довольно постоянной в течение многих лет. Большинство остальных предотвращаются корпоративными брандмауэрами и настройками безопасности (которые также могут предотвратить вспышку. Даже если она установлена). Гибкость Java позволяет обновлять программное обеспечение. Даже если базовая Java остается неизменной. Однако изощренность Java больше подходит для сложных апплетов. Таких как Clesh, чем для яркой графики на веб-странице.

Итак, в заключение производители решили поставлять свои компьютеры с Java. Большинство веб-браузеров могут запускать Java-апплеты. Не требуя последнего обновления. И Java не уменьшается. Stephen B Streater 21:49, 8 марта 2006 (UTC)

Я обновил этот раздел.

Видеоприложения-это самые требовательные веб-приложения Java. С которыми я сталкивался из-за требований к процессору hugh в сочетании с требованиями реального времени. Я не ссылался ни на одну из них в этой статье. Так как я немного близок к вовлеченным компаниям. Но вот несколько для проверки:

Есть еще много других. Включая Java MPEG-плееры. Стивен Би Стритер 11:03, 12 марта 2006 (UTC)