もはや馴染みとなった感もあるが，Oracle は Java EE 7 の開発スケジュールを維持するために，PaaS とマルチテナンシを Java EE 8 まで延期して，開発範囲を縮小することを検討中だという。Java EE 7 の仕様リーダである Linda DeMichiel 氏が，ブログ記事で次のように 発表した。
私たちは最善を尽くしていますが，開発予定のクラウドに関する部分の進行は捗々しくありません。その理由のひとつは，プロビジョニング，マルチテナンシ，柔軟性，およびクラウドへのアプリケーションのデプロイといった領域での完成度不足にあります。また，この作業を開始したときに，クラウド領域における私たちの業界経験が十分でないという観点から，すべての事を "適確" に行おうとした，保守的なアプローチも原因です。このような状況で，標準化された PaaS ベースのプログラミングとマルチテナンシの充実したサポートを提供しようとすれば，Java EE 7 のリリースが 2014 年春 – つまり今から２年後，計画より１年後 – まで遅れることになるだろう，と考えています。これではあまりに長すぎる，と私たちは思うのです。
そこで私たちは，Java EE Expert Group に対して行動計画の修正を提案しました – すなわち，目標とするリリース日程を遵守するために，PaaS 実現とマルチテナンシのサポートに関する課題を Java EE 8 まで先延ばしする，というものです。
DeMichiel 氏は，Red Hat や CloudBees など多数のベンダが，自社のクラウド環境で Java EE 仕様の少なくとも１部のサポートをすでに提供している，という点を指摘している。彼らがこの領域で経験を積み重ねれば，標準化作業への援助が期待できるに違いない，と言うのだ。氏の提案は Expert Group からも強い支援と賛同を受けている。
Red Hat の CDI リーダ である Pete Muir 氏は，次のように 答えている。
Java EE の実装者としての立場からは，私たち (Red Hat) は今回の提案を強く支持します。私たちは長い間，Java EE コミュニティはクラウドの標準化を行う段階にまで達していない，と主張してきました。そのことは，私たちの Java EE クラウドサービスである OpenShift によって証明されたと思っています。OpenShift は Java EE 6 でも問題なく動作します。
仕様リーダの立場からも，同じように支持します。今回の提案が私たちの手がける仕様 (CDI と Bean Validator) に対して持つ意味は理解していますし，同意もできるからです。
ZeroTurnaround の創設者で CEO の Jevgeni Kabanov 氏は，次のように 書いている。
強く支持します。私は以前から，クラウド標準は時期尚早だ，市場とコミュニティがどの方向に動くのかを理解するにはもっと時間が必要だ，と常々考えてきました。現在，クラウドに向けて多数のアクティビティが存在しています。しかし，どの技術，どの方法論，どの原理が勝者になるのか，まだ明らかではありません。あと２，３年待てば，もっと明確になるのではないでしょうか。
Apache TomEE, OpenEJB, Geronimo プロジェクトの創設者である David Blevin 氏は，次のように コメントしている。
他の方の意見の繰り返しになりますが，私も今回の決定を支持します。これによって救われる部分がかなりあると思うのです。
明快なパッケージング，デプロイ，そして移植性に重点を置いたことで，Java EE はすでに 90% クラウドに対応しています – これらの概念は，私たちが過去において堪え忍んできた部分であって，今その見返りを受けているところなのです。名誉挽回，といったところですね。残る 10% のクラウド要件については，これらは明らかに実験段階であって，標準化を語る段階ではありません。
標準仕様が市場において担っている意味を理解できない人たちにとっては，これがある種の失敗に見えるであろうことは間違いありません。しかし実はこれが，標準仕様によって得られる優れた長期的意思決定と価値の最たるものなのです。
ベンダが技術革新をします。私たちはそれらを総括して標準化するのです。私たちが革新を行うのではありません。
クラウドサポートが排除されたことで，Java EE 7 は売り物となる大きな機能をひとつ失うことになる。それでもまだ，JAX-RS 2.0 や JMS API のアップデート，EL(Expression Language / 式言語) のバージョン 3.0，HTML5 のサポート，さらには JPA と CDI のアップデートなど，歓迎すべき変更や追加は数多い。
政略的に見れば，Jigsaw が２度目の延期によって Java 9 での提供となった直後の決定であり，Oracle にとっては不本意な変更だ。あまりにも野心的なプロジェクト計画の結果としての後戻りは，Oracle が Java を管理する上でのテーマのようになりつつある。ただし決定の内容自体は明らかに妥当なものであり，その点では DeMichael 氏と Oracle は信頼に値する。