Открытость платформы Java 7 остается под вопросом

31.03.2009 00:17

В своём недавнем блог-комментарии Stephen Colebourne критично высказывается о Sun и Java Community Process (JCP), делая вывод, что Sun стоит на позиции "Java 7 больше не будет". Colebourne, член Apache Software Foundation и лидер JSR-310 (Java Date and Time), отмечает, что во всех анонсах в различных Sun-блогах, инженеры Sun говорят о JDK (Java Development Kit) 7 или об OpenJDK 7, но только не о Java SE (Standard Edition) 7. В настоящее время не существует "запроса на Спецификации Java" (JSR) для Java SE 7, и по его мнению, это признак того, что Sun, возможно, пытается перекрыть дорогу таким проектам, как Apache Harmony, реализующим свободно распространяемые и совместимые разработки Java 7.

Предыдущие релизы Java разрабатывались в контексте JCP, с JSR 176 для Java SE 5 и JSR 270 для Java SE 6. Colebourne также отмечает, что основные компоненты Java 7, такие, как Project Jigsaw, работающий с модульной Java, разрабатываются без JSR и с упором на OpenJDK.

Далее в своём сообщении Colebourne развивает аргументацию на основе протоколов заседаний JCP Executive 7, когда Sun, IBM, Red Hat и HP воздержались от голосования по резолюции BEA/Intel о создании JSR для Java SE 7, не содержащей пункта о требованиях использования, из-за которого представители Apache проголосовали против принятия спецификации Java EE 6. Colebourne делает вывод, что "не смотря не все усилия, решения пока нет. И поэтому всё ещё нет и спецификации для Java SE 7. И скорей всего у нас будет реализация JDK 7, но не будет открытой спецификации платформы Java SE 7."

Проблема с Apache заключалась в том, что хотя спецификации Java открыты и существуют её реализации под GPL, тестовый пакет для проверки Ява-совместимости содержит пункт "область применения". Это значит примерно то, что тестируемый с помощью тестового пакета код не может запускаться в ограниченной среде, соответственно тестируемый код можно запускать на настольном PC, но не в контент-киоске и не внутри промышленной системы.

Colebourne иллюстрирует проблему в отдельной заметке. Он уверен в том, что сохраняя OpenJDK 7 в виде открытой реализации, а не в виде спецификации, Sun пытается создать препятствие для сертификации Apache и любых других открытых проектов на Java 7, позволяя им быть только OpenJDK 7-совместимыми.

Ранее один из главных разработчиков, ответственных за Java SE and OpenJDK, указал, что не всё в проекте JDK 7 будет реализовано, и что спецификация Java SE 7 может сильно отличаться от того, что включено в проект OpenJDK 7.

исправить +3 +/–

Автор новости: JT

Лицензия: CC BY 3.0

Короткая ссылка: https://opennet.ru/21007-java

Ключевые слова: java

При перепечатке указание ссылки на opennet.ru обязательно

Обсуждение (9)

1.1, uZver (?), 10:04, 31/03/2009 [ответить] [﹢﹢﹢] [ · · · ]	+/–
к сожалению он близок к правде :( буду на дне сантехников - спрошу у их манагеров.

1.2, Аноним (-), 10:45, 31/03/2009 [ответить] [﹢﹢﹢] [ · · · ]	+/–
ну это уже через чур. Тогда java машин будет туча да и нельзя играться с апачами они в мире джава по весоммости не сильно меньше sun.

1.3, nim (?), 11:16, 31/03/2009 [ответить] [﹢﹢﹢] [ · · · ]	+/–
Flash и Java сливают, это факт. На поле проприетарщиков они не способны тягаться с майкрософт, которая к тому же сама начинает заигрывать с открытостью.

2.6, Ivan (??), 12:07, 31/03/2009 [^] [^^] [^^^] [ответить]	+/–
> Flash и Java сливают, это факт. Ну не знаю не знаю ... И то и другое стандарт де-факто в своей нише. Вероятность того, что на машине клиента стоит и рабоатет Flash близка к 100%, а насчёт Silverlight я не вкурсе, она уже впаривается автоматически через Windows Update? А для Маков версию реализовали? А Java на поле корпоративных информационных систем мне альтернатив вообще и в голову не приходит.

1.5, Ivan (??), 12:02, 31/03/2009 [ответить] [﹢﹢﹢] [ · · · ]	+/–
> инженеры Sun говорят о JDK (Java Development Kit) 7 или об OpenJDK 7, но только не о Java SE (Standard Edition) 7. Потому что делить Java на Edition-ы не меньшая тарабарщина чем было держать двойку, оставшуюся от старой версии системы, в названии технологии (J2SE 1.4). Давайте уже называть вещи своими именами и разделять ядро (виртуальную машину), стандартные библиотеки, аппсерверы, фрэймворки, архитектуры и методологии.

2.7, vitek (??), 12:49, 31/03/2009 [^] [^^] [^^^] [ответить]	+/–
а корпоративным клиентам будем впаривать сертифицированные и закрытые Edition-ы? ... хм.. а какая разница? или это для того, чтобы не пустить на этот рынок новых игроков? типа, самим места мало... ну так они и другие пути найдут.

2.9, uZver (?), 13:02, 31/03/2009 [^] [^^] [^^^] [ответить]

+/–

>> инженеры Sun говорят о JDK (Java Development Kit) 7 или об OpenJDK 7, но только не о Java SE (Standard Edition) 7.
>
>Потому что делить Java на Edition-ы не меньшая тарабарщина чем было держать
>двойку, оставшуюся от старой версии системы, в названии технологии (J2SE 1.4).
>Давайте уже называть вещи своими именами и разделять ядро (виртуальную машину),
>стандартные библиотеки, аппсерверы, фрэймворки, архитектуры и методологии.

Уже давно исправлено: Java SE 5, Java SE 6, Java EE 6 (сейчас над ним идет работа).

Под Java (tm) понимается среда которая прошла сертификацию и может выполнить приложение написанное на языке java. Java среда обязана включать в себя реализацию стандартных библиотек, на то это и стандартные библиотеки.

Так что все давно уже называется своими именами ;)

>Потому что делить Java на Edition-ы

А вот это вы зря :) Edition - это набор СТАНДАРТНЫХ библиотек и среды для реализации стандартных задач. Это намного удобнее чем каждый проект изучать новые библиотеки, делающие одно и тоже но чуть по разному, вместо глубокого изучения одной стандартной либы.

2.16, A (?), 02:00, 01/04/2009 [^] [^^] [^^^] [ответить]	+/–
Всегда раздражало, что одним словом Java названо слишком много разных вещей сразу. Вот какой смысл одинаково называть виртуальную машину и язык программирования? А Microsoft противопоставили этому независимость выбора языка программирования от виртуальной машины и удачно построили на этом рекламу .NET, хотя технически тут нет никакой разницы. А маркетологи Sun в обломе. В Sun вообще какие-то странные маркетологи. И менеджеры странные. Может пусть их правда лучше IBM купит. IBM в Java заинтерисованы, будут развивать.

1.15, drioptr (ok), 00:10, 01/04/2009 [ответить] [﹢﹢﹢] [ · · · ]

+/–

>пункта о требованиях использования, из-за которого представители Apache проголосовали против принятия спецификации Java EE 6

вот FAQ Open Letter to Sun Microsystems
http://www.apache.org/jcp/sunopenletterfaq.html

    Q : What is a "field of use" restriction?
    A : A "field of use" restriction is a restriction that limits how
        a user can use a given piece of software, either directly or
        indirectly.  To give a concrete example from the Sun / Apache
        dispute, if Apache accepted Sun's terms, then users of a
        standard, tested build of Apache Harmony for Linux on a
        standard general purpose x86-based computer (for example, a
        Dell desktop) would be prevented from freely using that
        software and that hardware in any application where the
        computer was placed in an enclosed cabinet, like an
        information kiosk at a shopping mall, or an X-ray machine at
        an airport.

    Q : Is a "field of use" restriction incompatible with both open
        source and free software principles?
    A : Yes, both.  See the Open Source Initiative's open source
        definition (http://www.opensource.org/docs/osd), most notably
        section 6 and 10 and the Free Software Foundation's free
        software definition
        (http://www.gnu.org/philosophy/free-sw.html) most notably
        freedom #0.

без перевода понятно

игнорирование участников | лог модерирования

Добавить комментарий

Текст: