Я проверял JSR 227 page и смотрел его статус как "снято". Что означает этот статус? Означает ли это, что это устарело? есть ли более новая версия, заменившая эту спецификацию?Что означает «снятый» статус для JSR?
Из JCP Process document, раздел 2.1:
По желанию к ОУП любое предложение JSR может быть отменено подателем (ов) без объяснения до завершения бюллетеня утверждения JSR.
Таким образом, это означает, что оно было отозвано до одобрения, не более того. Есть ли замена в работах или нет, неясно. Эта конкретная спецификация просто показывает, что она была «отозвана по запросу руководства по спецификации», поэтому вам нужно будет связаться с Джоном Смильяничем в Oracle, чтобы получить подробную информацию.
Это может быть полезно прочитать JSR Review Ballot comments, скопировано ниже для полноты. Вполне возможно, что проблемы, поднятые IBM и BEA, убедили Oracle, что ее не стоит преследовать в ее нынешнем виде, но это (я бы хотел, чтобы думать об этом) спекуляции с моей стороны.
В 2003-06-25 Sun Microsystems, Inc. голосовали Да без комментариев.
В 2003-06-30 Oracle проголосовал «Да» со следующим комментарием: Oracle понимает проблемы IBM, но считает, что может возникнуть недоразумение относительно деталей этого JSR. Объем этого JSR на самом деле довольно мал и ограничен интерфейсами и форматами, необходимыми для того, чтобы иметь возможность привязки и быть переносимым на любой стандартный сервер. Минимальным требованием для этой функции является декларативное связывание и управление данными. Каждый из них существует друг для друга. Объем этого JSR будет охватывать только интерфейсы этих объектов, а не конкретные реализации. Это будет специфичным для поставщика. Oracle будет рада прояснить любые неясные моменты в этом предложении, как и у многих других членов ЕС.
В 2003-06-27 Cisco Systems голосовала Да без комментариев.
В 2003-06-30 IBM проголосовала «Нет» со следующим комментарием: В этом JSR есть интересные идеи. Однако мы обеспокоены широтой охвата и отсутствием ясности в отношении важных аспектов этой JSR. В частности, мы считаем, что этот JSR слишком широк по объему, включая элементы бизнес-сервисов, доступа к данным и привязок пользовательского интерфейса. Предлагаемая спецификация объединила бы эти аспекты, создавая нежелательную связь между дизайном элементов управления данными для бизнес-сервисов и потребностями представления пользовательского интерфейса. Эта работа должна быть разделена на две отдельные операции: одна для определения бизнес-служб и управления данными для этих служб, а другая - для определения декларативных привязок пользовательского интерфейса. Это привело бы к большей концентрации внимания и привело бы к спецификациям, которые лучше отвечали бы потребностям этих отдельных областей. В дополнение к этой важной проблеме у нас есть озабоченность по поводу отсутствия подробных сведений об элементах управления данными, предлагаемых этим JSR, некоторых аспектах декларативных привязок и взаимосвязи с JSR 114 и 127. Мы отправляем электронное письмо в SE/EE EC, детализируя эти проблемы.
В 2003-06-30 BEA Systems проголосовало No со следующим комментарием: BEA также вызывает серьезную озабоченность по поводу объема и факторинга JSR 227 и, таким образом, голосует «Нет». В частности, мы полагаем, что функциональность, воплощенная в Data Controls, должна быть в отдельном JSR из спецификации Declarative Bindings, поскольку Data Controls обычно можно использовать за пределами заявленных случаев привязки данных. Таким образом, объединение этих понятий в JSR нежелательно.Кроме того, поскольку предлагаемая архитектура Data Controls является уровнем нормализации для различных типов источников данных и типов услуг, мы считаем, что это достаточно сложная тема, которая гарантирует независимую JSR.
В 2003-07-02 Apple Computer, Inc. проголосовали «Да» без комментариев.
В 2003-07-02 Lea, Doug проголосовали «Да» со следующим комментарием: Я уверен, что проблемы, выраженные IBM и BEA , могут быть рассмотрены в группе экспертов.
В 2003-07-03 SAP AG проголосовали «Да» со следующим комментарием: SAP считает, что этот JSR имеет хороший потенциал для упрощения разработки бизнес-приложений на Java, связывая отдельные технологии Java вместе и устанавливая общие шаблоны проектирования, которые повышение производительности труда. Концепция Declarative Bindings еще больше сократит усилия по программированию, что упростит разработчикам приложений сосредоточиться на решении бизнес-задач, а не на системных деталях. Тем не менее мы считаем, что эта JSR должна быть дополнительно расширена Группой экспертов, как только она будет сформирована. Проблемы, такие как нормализация транзакционного поведения разных источников данных или определение конкретных метаданных для сложных бизнес-сервисов, должны обсуждаться в отдельных JSR для поддержания фокуса. Кроме того, выбор значимых вариантов использования для декларативных привязок потребует значительной координации с другими JSR, а Lead Lead должен обеспечить архитектурную целостность платформы J2EE. Из-за его широкого воздействия на платформу важна прозрачность общих усилий в области развития. Тем не менее, SAP считает, что это JSR представляет хорошие возможности для сообщества Java, а также место для инноваций в других JSR и поэтому голосует «YES» для этого JSR.
В 2003-07-06 Nokia Networks проголосовала «Да» со следующим комментарием: На основе информации, доступной по предложению JSR, выпущенных IBM и BEA и разъяснений, данных Oracle, этот JSR должен продолжаться. По мере того, как речь идет о области обзора, она должна выполняться в качестве первой задачи ЭГ. Кроме того, вполне понятно, что предложение JSR как таковое не может дать уровень детализации, который затрагивает некоторые из проблем в обсуждении темы. Поэтому проблемы, выраженные IBM и BEA, должны быть рассмотрены в EG на ранней стадии JSR после обзора. Кроме того, нежелательно, чтобы значимые технические решения в рамках JSR, как ожидается, были сделаны ранее при участии EG. Таким образом, подробные технические проекты не должны быть вырезаны на камне до тех пор, пока EG не обсудит и не одобрит их.
На 2003-07-07 Caldera Systems проголосовали Воздержитесь со следующим комментарием: Мы разделяем озабоченность SAP, о влиянии этого JSR на архитектурной целостности J2EE и не уверены, можно ли ЭГ быть успешным в следуя всем (несколько противоречивым) директивам, которые он дает на этом JSR.
В 2003-07-07 Macromedia, Inc. проголосовали «Да» со следующим комментарием: Учитывая ценность этой технологии для основного веб-разработчика и опасности ее решения с помощью лени, мы должны призвать оптимизм к тому, что исполнительный директор JCP Комитет и Экспертная группа JSR могут усовершенствовать сферу охвата этого JSR в будущем и с энтузиазмом желают перенести дебаты о контрольной и контрактной специфике в группу экспертов без задержки, вызванной голосованием НЕТ.
В 2003-07-07 Прогресс Проголосовало Да без комментариев.
В 2003-07-07 Hewlett-Packard проголосовали «Да» без комментариев.
В 2003-07-07 Fujitsu Limited голосовала Да без комментариев.
В 2003-07-07 Borland Software Corporation проголосовала «Да» без комментариев.
В 2003-07-07 Фонд Apache Software проголосовал «Да» без комментариев.
Для вас, как программиста, это ничего не значит.
Oracle изобрел декларативный способ подключения пользовательского интерфейса приложения JSF к базовым службам данных, и это ядро их рамок разработки приложений (ADF). Поскольку они построили его и широко используют в ADF, и поскольку они используют ADF для своего огромного нового пакета ERP (Fusion Applications), он будет оставаться в течение долгого времени.
Oracle захотела сказать «основанные на стандартах», поэтому они представили свой путь как JSR. IBM, использующая другой метод, не видит преимуществ в предоставлении своему конкуренту официального JSR, поэтому они заблокировали его.
Тот факт, что он был отозван, является просто домашним хозяйством.