JSR 227 ページを確認したところ、ステータスが「撤回」と表示されています。この状態はどういう意味ですか? それは廃止されたということですか？この仕様を置き換えた新しいバージョンはありますか?
2 に答える
5
プログラマーとしてのあなたにとって、それは何の意味もありません。
Oracle は、JSF アプリケーションのユーザー インターフェイスを基礎となるデータ サービスに接続するための宣言的な方法を発明しました。これが Oracle のアプリケーション開発フレームワーク (ADF) の中核です。彼らはそれを構築し、ADF で広く使用しており、巨大な新しい ERP スイート (Fusion Applications) に ADF を使用しているため、非常に長い間存続します。
オラクルは「標準ベース」と言えるようにしたかったので、JSR として提出しました。別の方法を使用している IBM は、競合他社に公式の JSR を付与するメリットがないと判断したため、それをブロックしました。
撤回されたという事実は、単なるハウスキーピングです。
于 2013-07-10T13:00:48.420 に答える
2
JCP Process documentのセクション 2.1から:
PMO への要求に応じて、JSR 承認投票が完了する前に、提出者は説明なしに JSR 提案を撤回することができます。
つまり、承認前に取り下げられたことを意味するだけで、それ以上のことはありません。作品に代替品があるかどうかは不明です。その特定の仕様は、「仕様リードの要求で撤回された」ことを示しているだけなので、詳細を取得するには、Oracle の John Smiljanic に連絡する必要があります。
完全を期すために以下にコピーされているJSR Review Ballotのコメントを読むと、役立つ場合があります。IBM と BEA が提起した懸念により、Oracle は現在の形で追求する価値がないと確信したのかもしれませんが、それは (十分な情報に基づいていると思いたいのですが) 私の推測です。
2003 年 6 月 25 日、Sun Microsystems, Inc. はノーコメントで賛成票を投じました。
2003 年 6 月 30 日、オラクルは次のコメントで賛成票を投じました。オラクルは IBM の問題を理解していますが、この JSR の詳細に関して誤解があるかもしれないと考えています。この JSR のスコープは実際にはかなり小さく、バインディングを取得して標準サーバーに移植できるようにするために必要なインターフェースとフォーマットに限定されています。この機能の最小要件は、宣言的バインディングとデータ コントロールです。それぞれがお互いのために存在しています。この JSR の範囲は、これらのオブジェクトへのインターフェースのみをカバーし、特定の実装はカバーしません。それはベンダー固有のものです。オラクルは、他の多くの EC メンバーと同様に、この提案の不明確な点を喜んで明確にします。
2003 年 6 月 27 日、Cisco Systems はノーコメントで賛成票を投じました。
2003 年 6 月 30 日、IBM は次のコメントで反対票を投じました。この JSR には興味深いアイデアがいくつか含まれています。ただし、範囲が広く、この JSR の重要な側面が明確でないことを懸念しています。特に、この JSR は、ビジネス サービス、データ アクセス、およびユーザー インターフェイス バインディングの要素を含め、範囲が広すぎると考えています。提案された仕様は、これらの側面を組み合わせて、ビジネス サービスのデータ コントロールの設計とユーザー インターフェイス表示のニーズとの間に望ましくない結合を作成します。この作業は、ビジネス サービスとこれらのサービスのデータ コントロールを定義するアクティビティと、宣言型ユーザー インターフェイス バインディングを定義するアクティビティの 2 つの別個のアクティビティに分割する必要があります。これにより、焦点が改善され、これらの異なる分野のニーズにより適切に対応する仕様につながるでしょう。
2003 年 6 月 30 日、BEA Systems は次のコメントで反対票を投じました。具体的には、Data Controls で具現化された機能は、Declarative Bindings 仕様とは別の JSR にある必要があると考えています。これは、Data Controls は通常、規定されたデータ バインディングのユース ケース以外でも使用できるからです。したがって、これらの概念を JSR で結合することは望ましくありません。また、提案されているデータ コントロール アーキテクチャは、さまざまなデータ ソース タイプとサービス タイプの正規化レイヤーであるため、これは独立した JSR を保証する十分に複雑なトピックであると考えています。
2003 年 7 月 2 日、Apple Computer, Inc. はノーコメントで賛成票を投じました。
2003 年 7 月 2 日の Lea で、Doug は次のコメントで賛成票を投じました。
2003 年 7 月 3 日に、SAP AG は次のコメントとともに賛成票を投じました。Declarative Bindings の概念により、プログラミングの労力がさらに削減され、アプリケーション開発者がシステム レベルの詳細ではなく、ビジネス上の問題の解決に集中しやすくなります。それでもなお、この JSR は、形成され次第、専門家グループによってさらに調査される必要があると考えています。さまざまなデータ ソースのトランザクション動作の正規化や、複雑なビジネス サービスの具体的なメタデータの定義などの問題は、焦点を維持するために別の JSR で議論する必要があります。さらに、宣言的バインディングの意味のあるユース ケースを選択するには、他の JSR との重要な調整が必要であり、仕様リードは J2EE プラットフォームのアーキテクチャの整合性を確保する必要があります。プラットフォームへの影響が大きいため、開発作業全体の透明性が不可欠です。それにもかかわらず、SAP は、この JSR が Java コミュニティに良い機会を提供するだけでなく、他の JSR に革新の余地をもたらすと考えているため、この JSR に「YES」を投票します。
2003 年 7 月 6 日、Nokia Networks は、次のコメントとともに賛成票を投じました。スコーピングに関する限り、EG の最初のタスクとして実施する必要があります。さらに、JSR の提案自体が、トピックに関する議論の懸念事項の一部が対処されてきた詳細レベルを示すことができないことは非常に理解できます。したがって、IBM と BEA によって表明された懸念は、スコーピング後、JSR の初期段階で EG で対処する必要があります。さらに、EG が関与する前に、JSR 内で重要な技術的決定が行われることが期待されることは望ましくありません。したがって、詳細な技術設計は、EG が議論して承認するまで確定すべきではありません。
2003 年 7 月 7 日、Caldera Systems は次のコメントで棄権しました: 私たちは、この JSR が J2EE のアーキテクチャの完全性に与える影響についての SAP の懸念を共有しています。このJSRで提供されています。
2003 年 7 月 7 日、Macromedia, Inc. は次のコメントで賛成票を投じました: 主流の Web 開発者にとってのこのテクノロジの価値と、怠惰に取り組むことの危険性を考慮すると、JCP 実行委員会と JSR 専門家がグループは、今後この JSR の範囲を絞り込むことができ、NO 投票が引き起こす遅延なしに、コントロールと契約の詳細に関する議論を専門家グループに移すことを熱心に望んでいます。
2003 年 7 月 7 日、Progress Software はコメントなしで賛成票を投じました。
2003 年 7 月 7 日、Hewlett-Packard はノーコメントで賛成票を投じました。
2003 年 7 月 7 日、富士通株式会社はコメントなしで賛成票を投じました。
2003 年 7 月 7 日、Borland Software Corporation はノーコメントで賛成票を投じました。
2003 年 7 月 7 日、Apache Software Foundation はコメントなしで賛成票を投じました。
于 2013-05-14T06:36:21.187 に答える