Это неделя с открытым исходным кодом в SitePoint! Всю неделю мы публикуем статьи, посвященные всему, что связано с открытым исходным кодом, свободным программным обеспечением и сообществом, поэтому постоянно проверяйте тег OSW на наличие последних обновлений.
Java более двадцати лет и неизменно считается одним из самых популярных языков программирования на планете. Частично то, что делает Java настолько привлекательной для разработчиков, — это то, что функции развиваются контролируемым образом, что редко влияет на обратную совместимость. У развития Java была несколько иная история, особенно в отношении открытого исходного кода. В этой статье мы рассмотрим, как стандартизируется платформа Java при одновременном поддержании участия сообщества посредством процесса сообщества Java (JCP). Мы также увидим некоторые проблемы, с которыми этот процесс столкнулся и сталкивается сегодня.
Перед ОКП
После запуска Java быстро приобрела популярность, и многочисленные корпорации, как большие, так и маленькие, хотели стать частью этой захватывающей новой программной платформы. В первые дни IBM быстро стала участвовать через Taligent — совместное предприятие IBM и Apple, которое начало разработку объектно-ориентированной среды приложений. Taligent также имеет сильные стороны в интернационализации и внес ряд классов в JDK 1.1 (например, пакет java.textjava.util.Calendar
Microsoft также стала лицензиатом Java, интегрировав ее в ранние версии Internet Explorer. Реализация Microsoft вызвала много неприятностей, что привело к длительному и длительному судебному процессу по поводу того, как Microsoft нарушила условия их лицензионного соглашения. В конечном итоге это было решено в пользу Sun, но по сути это и послужило причиной развития C #.
Примерно в 1997 году Sun Microsystems оказала большое давление, чтобы передать стандартизацию Java хорошо известному международному органу стандартизации, такому как ANSI или ECMA. Сунь не хотел этого делать по двум причинам. Прежде всего, это дало бы контроль над платформой Java другим людям, и Sun осознала ценность Java для них, безусловно, с точки зрения маркетинга, если не с точки зрения чистого дохода.
Вторая причина заключалась в том, как быстро Java может развиваться со временем. Процессы стандартизации можно классифицировать по спектру, где один конец — это одна компания с полным контролем, а другой — полностью открытый процесс, в котором все вовлеченные стороны имеют равное право голоса. У каждого из них есть свои сильные и слабые стороны. Если бы Sun продолжала контролировать разработку Java, разработчики просто должны были бы принять то, что управление продуктами Sun считало лучшими функциями. Если бы Sun передала Java кому-то, подобному ANSI, это повлияло бы на скорость разработки. Открытые международные органы по стандартизации, как известно, медленнее разрабатывают и ратифицируют стандарты (ANSI удалось подготовить только три пересмотра стандарта C за последние 26 лет!)
Процесс сообщества Java
Руководство Sun решило, что наилучшим способом разработки спецификаций для Java является создание нового органа по стандартизации, процессы которого будут находиться где-то между двумя концами спектра. Выпустив первоначальное предложение в октябре, Sun официально запустила Java Community Process (JCP) 8 декабря 1998 года, в тот же день, когда выпустила JDK 1.2. Он также воспользовался этой возможностью для ребрендинга Java как Java 2 и представил концепцию различных «выпусков», в частности:
- Java 2 Micro Edition (J2ME) для мобильных и встраиваемых устройств
- Java 2 Standard Edition (J2SE), охватывающий язык, основные библиотеки и JVM
- Java 2 Enterprise Edition (J2EE) для корпоративных приложений, использующих такие компоненты, как сервлеты и Enterprise Java Beans (EJB), в контейнере сервера приложений (кто говорит, что микросервисы являются новыми?)
Структура ОКП
JCP будет состоять из сторон, заинтересованных в разработке идей по разработке Java. Первоначально членство ограничивалось только корпорациями, но позже оно было изменено, чтобы включать группы пользователей Java, ученых и даже отдельных лиц.
К счастью, Sun поняла, что ключевым словом в названии JCP было Сообщество .
Первоначальная структура JCP имела два исполнительных комитета (EC), роль которых заключалась в том, чтобы одобрить прохождение спецификаций через ключевые моменты процесса. Один EC отвечал за J2ME, а другой за J2SE и J2EE. В августе 2012 года они были объединены в единый EC для всех мероприятий по стандартизации Java.
На сегодняшний день в соответствии с правилами JCP версии 2.10 ЕС формируется из следующего:
- 16 ратифицированных мест
- 6 избранных мест
- 2 сопутствующих места
- 1 постоянное место для Oracle America
Члены отбывают двухлетний срок в шахматном порядке, так что 12 из 24 мест обычно подлежат ратификации или выборам каждый год. Последняя версия устава JCP также отменила требование о членских взносах. Текущая цель явно состоит в том, чтобы увеличить членство и, следовательно, участие сообщества.
Изменение Java через JCP
Любой полноправный член процесса сообщества Java может отправить запрос спецификации Java (JSR), который состоит из разнообразной информации о предлагаемой спецификации, включая описание того, что она будет стандартизировать, приблизительные сроки разработки и почему это требуется. ЕС голосует за JSR, и, если он будет принят, начинается процесс разработки стандарта.
Для этого формируется экспертная группа (EG) из полноправных членов JCP или представителей-членов, которые заинтересованы в помощи в разработке спецификации. Специалист по спецификации (обычно тот, кто представил JSR, но со временем это может измениться) решает, кого принять для EG. После того, как EG создаст спецификацию, она будет опубликована для публичного просмотра, прежде чем члены JCP проголосуют за ее утверждение.
Результаты JSR состоят из трех частей и составляют «золотой треугольник» JCP:
- Формальная спецификация
- Эталонная реализация (RI) спецификации
- Комплект для тестирования совместимости (TCK)
Диаграмма ниже показывает взаимосвязь этих трех частей.
Первоначально JCP пережил бурную деятельность со многими поданными JSR, созданными группами экспертов и определенными спецификациями. На момент написания, на веб-сайте JCP было указано 380 JSR, а еще 27 JSR для обслуживания соответствуют существующим спецификациям.
Существует также другой механизм принятия и отслеживания изменений в платформе Java: механизм предложений JDK (JEP). В 2006 году Sun наконец-то выпустила исходный код своего Java Development Kit (JDK) под лицензией с открытым исходным кодом и запустила проект OpenJDK для управления этим. Спецификация Java SE, определенная через JCP, охватывает только язык Java, виртуальную машину и библиотеки классов. JEP охватывает любую модификацию JDK, которая может привести к передаче изменений в соответствующие JSR. Как мы увидим позже, в последнее время они стали предметом некоторых дискуссий.
Соглашение об участии в спецификации Java
Другой важной частью JCP, о которой я не упомянул до сих пор, является Соглашение об участии в спецификации Java (JSPA, pdf ). Это важно, поскольку охватывает права интеллектуальной собственности (IP), связанные со спецификациями JSR. Первоначально JCP не предоставлял никакого способа для независимых реализаций JSR, поэтому не было возможности создавать версии с открытым исходным кодом.
На JavaOne в 2002 году было объявлено, что Apache Software Foundation (ASF) присоединился к Java SE / EE EC. Также было объявлено, что все текущие и будущие JSR, возглавляемые Sun, будут доступны по лицензии, которая допускает реализацию с открытым исходным кодом.
Раздел 5 нового JSPA охватывал исходящий IP и гарантировал, что руководитель спецификации предоставил бессрочную, без лицензионных отчислений, безотзывную лицензию на авторские права и патенты, охватывающие спецификацию, любому, кто хотел бы создать независимую реализацию спецификации. Для того, чтобы претендовать на это, реализация должна будет полностью реализовать спецификацию, а не модифицировать, устанавливать или изменять спецификацию и передавать TCK.
Гармония ударяет по неверному аккорду
В течение нескольких лет JCP работал без проблем с широким спектром представленных JSR, написанными спецификациями и созданными как коммерческими, так и открытыми реализациями.
30 сентября 2004 года была запущена Java 2 SE 5.0. Это включало значительные изменения в синтаксисе языка Java, а также изменило схему нумерации Java еще раз. Чтобы указать уровень изменения платформы, номер релиза был перенесен на 5.0. Через JCP содержимое релиза было указано в JSR 176 , который был «зонтичным» JSR. В этой спецификации определено содержимое, которое также включает элементы, указанные другими JSR, например, универсальные типы из JSR 14 , аннотации из JSR 175 и т. Д.
Тогда все стало сложнее.
Войти в проект Гармония
В мае следующего года ASF создал новый проект инкубатора, целью которого была «разработка и внедрение J2SE 5». Это было известно как Проект Гармония . В течение некоторого времени до этого объявления сторонники свободного и открытого программного обеспечения (FOSS) хотели, чтобы исходный код Java был свободно доступен с лицензией с открытым исходным кодом. Sun сопротивлялась этому призыву по разным причинам; не в последнюю очередь это был огромный объем работы, который потребовался бы для должной осмотрительности, чтобы позволить им выпускать исходный код под лицензией с открытым исходным кодом, но также, как мы увидим, из-за того, как Sun заработала на Java.
Поскольку спецификации Java были свободно доступны в JCP, теоретически можно было бы создать реализацию «чистой комнаты», которая могла бы распространяться без условий двоичного лицензирования Sun. Наиболее значимым из них было ограничение области использования (FoU). По сути, FoU заявил, что Java можно использовать свободно (т.е. без уплаты лицензионного сбора Sun), если она используется на «Настольных компьютерах и серверах общего назначения».
Солнце сопротивляется
В то время единственным местом, где Sun получала доход напрямую от Java, было лицензирование Java Card (небольшого подмножества Java, занимающего всего несколько килобайт оперативной памяти) и Java 2 ME, который использовался производителями мобильных телефонов. Sun хотела защитить этот (немаловажный) поток доходов.
Работа над версией Java с открытым исходным кодом началась еще в 1998 году в форме проекта GNU Classpath, но она была сосредоточена только на стандартных библиотеках классов Java, а не на виртуальной машине. Проект Harmony предназначен для создания полной среды выполнения Java с открытым исходным кодом.
К сожалению, именно здесь начались проблемы. Чтобы реализации JSR 176 было предоставлено бесплатное использование всех необходимых IP и чтобы она называлась Java, эта реализация должна пройти все тесты в TCK. В августе 2006 года ASF обратилась к Sun, чтобы получить доступ к TCK для JSR 176 (чтобы немного запутать TCK, в этом случае его также называют Java Compatibility Kit (JCK)). Несмотря на объявления, сделанные на JavaOne в 2002 году, Sun предоставит Apache TCK / JCK только при определенных лицензионных ограничениях. Эти ограничения означали, что любая протестированная реализация все еще будет ограничена FoU, очень похожим на двоичное распределение Sun.
тупик
Apache явно почувствовал, что это противоречит JSPA, и 10 апреля 2007 года написал открытое письмо Sun Microsystems, в котором, по существу, требовалось, чтобы Sun соблюдала условия JSPA и предоставила им TCK по соответствующей лицензии. Солнце отказалось это сделать.
Тупик был окончательно разрешен после того, как Oracle приобрела Sun Microsystems и поставила предложенную Java SE 7 JSR на голосование Java SE / EE EC. Фактически это было голосование о том, будут ли изменены условия лицензирования TCK для Java SE, чтобы обеспечить ASF доступ так, как они хотели. Однако, несмотря на возражения нескольких членов ЕС, голосование было проведено, что дало возможность JCP вернуться к разработке стандартов в обычном режиме.
Тим Пайерлс и Даг Ли, оба отдельные члены СЕ / ЕЕ, подали в отставку в знак протеста. ASF еще раз попыталась заставить Oracle выполнить обязательства JSPA, но в конце концов вышла из состава JCP SE / EE EC в декабре 2010 года.
Состояние дел
Со времени выхода ASF из JCP было предложено более сорока JSR, охватывающих все аспекты Java. Означает ли это, что с JCP все в порядке? В некотором смысле, да, но у него все еще есть свои проблемы.
Java ME
За последние несколько лет только два JSR относились к Java ME, включая выпуск 8 Конфигурации подключенного ограниченного устройства (CLDC) и встроенный профиль Java ME . Теперь, когда мобильные телефоны отошли от Java ME, а многие встроенные устройства достаточно мощные, чтобы запустить полноценную реализацию Java SE, трудно понять, куда Java ME пойдет в будущем.
Начиная с Java SE 8, план от Oracle состоял в том, чтобы выпуски Java ME шли в ногу с Java SE. Прямо сейчас кажется маловероятным, что в следующем году будет Java ME 9.
Java SE
Компоненты JSR были представлены для различных основных функций платформы. Наиболее значительным в последнее время стала модульная система платформы Java (Project Jigsaw, JSR 376 ), которая должна быть включена в Java SE 9 ( JSR 379 ).
Руководство Oracle Engineering Group недавно обратилось к JCP EC с вопросом о JSR для Java SE. Проблема, с которой они сталкиваются, заключается в том, что разработка программного обеспечения сильно изменилась за последние двадцать лет, и требуется более гибкий подход к разработке базовой платформы Java. JSR используют структурированный процесс для разработки, который не подходит для этой методологии.
Предложения по расширению JDK (JEP) были введены в проект OpenJDK для удовлетворения этой потребности. JEP охватывают меньшие части работы, чем полный JSR, и их можно быстро и легко включить или исключить из выпуска JDK (JDK 9 уже демонстрирует это).
Несмотря на использование JEP, для Java SE будут оставаться JSR, но они будут собирать все изменения, когда релиз будет готов к отправке, а не определять их в начале процесса разработки. Это хорошо, потому что обеспечивает доступность IP для Java SE на тех же условиях, что и раньше. Тем не менее, есть некоторые опасения от людей, желающих сделать коммерческие реализации «чистой комнаты» JDK, поскольку единственной ссылкой на спецификацию будет проект OpenJDK, пока Java SE JSR не будет в конечном итоге опубликована.
Java EE
Многочисленные JSR были представлены для различных аспектов Java EE, таких как EJB, сервлеты, веб-службы, MVC и т. Д., Все они предназначались для того, чтобы стать частью Java EE 8. Однако в последнее время в сообществе Java возникла серьезная обеспокоенность тем, что большинство эти JSR не имели никакой активности, связанной с ними, и Oracle больше не активно разрабатывал Java EE. Недавние анонсы на JavaOne этого года обещали вернуть Java EE 8 и 9 в нужное русло, так что ожидайте гораздо большего прогресса в этих JSR в ближайшем будущем.
В конце концов, это все о сообществе
JCP, безусловно, сталкивается с проблемами в будущем. Чтобы гарантировать, что стандарты остаются открытыми, важно, чтобы членство в JCP продолжало расти. Недавние изменения в соглашении о членстве в JCP — явный шаг в правильном направлении для этого.
Совсем недавно в ОКП состоялись выборы членов ЕС. Поскольку выборы стали первыми по новым правилам версии 2.10, все места были переизбраны. В настоящее время ЕС состоит из шестнадцати ратифицированных, шести избранных и двух ассоциированных мест, а также одного постоянного места для Oracle America. Я рад сообщить, что компания, в которой я работаю, Azul Systems , была переизбрана на двухлетний срок, и мы продолжим помогать в разработке платформы Java посредством этого участия.
Java отличается от большинства других платформ разработки из-за одного ключевого фактора. Надеемся, что JCP будет использовать это, чтобы обеспечить постоянное развитие Java для удовлетворения постоянно меняющихся потребностей разработчиков и оставаться самой популярной платформой на планете. Ключевой фактор? Это в названии: Сообщество.