JavaのMVC 1.0の仕様に対するパブリックレビューが公開に

JSR-371、これはModel-View-Controller (MVC) バージョン1.0の仕様であるが、パブリックレビューが公開されている。2017年4月にオラクルが所有権をIvar Grimstad氏へ移管して以来、これが最初のメジャーリリースである。移管のあとすぐにIngenit GmbHのシニアソフトウェア開発者であるChristian Kaltepoth氏が共同スペックリードとしてGrimstad氏に加わった。JSR-371は後にApache License 2.0ライセンスとなり、2017年10月にGrimstad氏は最終的なリリース後にMVC 1.0をEclipseファウンデーションへ移管する意向を公表した。

初期ドラフトレビュー2以降の新機能は以下のものである。

• 国際化 - I18Nのサポート。
• データバインディングの改善 - データバインディングとバリデーションに対して@MvcBindingアノテーションとBindingResultクラスを使ったMVC仕様のルールが可能に。

仕様ドキュメントに挙げられているように、MVC 1.0の目標は以下のものである。

• 既存のJava EE技術を活用する。
• CDI (JSR-346)とBean Validation (JSR-349)を統合する。
• MVCアプリケーションを構築するためのしっかりした核を定義する。最初のバージョンで必ずしも全機能をサポートするのではない。
• JAX-RSの上に重ねる方法を調査する。マッチングとバインディングのレイヤを再利用するため。
• JSPとFaceletsをビュー言語としてビルトインでのサポートを提供する。

EE4JのEclipse OzarkプロジェクトはJSR-371の完全な実装を提供する。これはRESTEasyとJersey、Apache CXFをサポートする。Ozarkのバージョン1.0はJSR-371の最終リリースとともに2018年の第2四半期にリリースされると思われる。

はじめの一歩

以下にあるように@ControllerアノテーションでMVC 1.0のコントローラを定義する。JSPファイルを表示するとても単純な例だ。

    
@Path("hello")
@Controller
public class HelloController {

    @GET
    public String view() {
        return "hello.jsp";
        }
    }
    

MVC 1.0のコントローラクラスのメソッドの戻り値の型はさまざまな方法で処理される。たとえば、

• void - @Viewアノテーションが付与されていなければならない(下の例を参照)。
• String - ビューへのパスを返す(上記の例を参照)。
• JAX-RS Response - ヘッダを含めHTTPレスポンスに完全にアクセスできる(下の例を参照)。

以下に示すのはMVC 1.0コントローラのよくある例である(Grimstad氏のGitHubリポジトリにあるhello-cdiのサンプルから)。

    
@Path("hello")
@Controller
public class HelloController {

    @Inject
    private BindingResult br;

    @Inject
    private Messages messages;

    @Inject
    private HelloBean helloBean;

    @GET
    @View("form.jsp")
    public void form() {
        }

    @POST
    public Response formPost(@Valid @BeanParam HelloForm form) {

        if (br.isFailed()) {
            messages.setErrors(
                    br.getAllValidationErrors().stream()
                    .collect(toList()));

            return Response.status(BAD_REQUEST).entity("form.jsp").build();
            }

        helloBean.setFirstName(form.getFirstName());
        helloBean.setLastName(form.getLastName());

        return Response.status(OK).entity("hello.jsp").build();
        }
    }
    

BindingResult(バリデーションのため)とモデルMessagesとHelloBeanのインスタンスが、@Injectアノテーションを使ってコントローラに自動的に設定される。ビューはform.jspを表示する。form()メソッドに@Viewアノテーションが付与されているからだ。メソッドformPost()は型Responseを返し、バリデーションを処理している。HelloFormクラスはユーザ入力のバリデーションとして文字列長を定義している。

    
public class HelloForm {

    @MvcBinding
    @NotNull
    @Size(min = 1, max = 16)
    @FormParam("firstName")
    private String firstName;

    @MvcBinding
    @NotNull
    @Size(min = 2, max = 24)
    @FormParam("lastName")
    private String lastName;

    public String getFirstName() {
        return firstName;
        }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
        }

    public String getLastName() {
        return lastName;
        }

    public void setLastName(String lastName) {
        this.lastName = lastName;
        }
    }
    

仕様ドキュメントではバインディングとバリデーションのプロセスをこう記述している。

@FormParamや@QueryParamのようなパラメータのバインディングには@MvcBindingのアノテーションがつくでしょう。MVC仕様のバインディングルールを可能にするためです。MVCのバインディングでは失敗したバリデーションはConstraintViolationExceptionをスローしません。代わりに、対応するConstraintViolationがリクエストスコープのBindingResultインスタンスに保存されます。これはコントローラにインジェクトできます。そのためExceptionMapperのようなグローバルなエラー処理メカニズムを当てにする代わりにコントローラがエラーを処理できます。

hello-cdiサンプルアプリケーションを実行すると、form.jspをレンダリングして以下のような画面でユーザ入力を表示する。

以下のようにユーザが入力すると、文字列長のバリデーションの条件を満たしておりhello.jspをレンダリングする。

以下はバリデーションエラーの結果だ。この例ではエラーになると入力をすべて消しエラーメッセージを表示している。

CybercomグループのプリンシパルコンサルタントであるGrimstad氏がInfoQにMVC 1.0の最新状況を話してくれた。

InfoQ「なぜオラクルはMVC 1.0のサポートをやめたのでしょうか？」

Grimstad氏「申し訳ないですが、このことについてはオラクルがコメントすべきことです。MVC 1.0をオラクルがJava EE 8のスコープから外す決定をした理由としては、MVCがクラウドアプリケーションには重要ではないと気づいたからと私は理解しています。彼らはたいてい指導者のいないものを出すからです。」

InfoQ「MVC 1.0がEE4Jへ統合されるのはいつだと思われますか？それまでに何をする必要があるのでしょうか？」

Grimstad氏「私たちはすでにOzark、MVC 1.0の参照実装のプロジェクト提案を作りました。プロジェクト提案はこちらです。https://projects.eclipse.org/proposals/eclipse-ozark

MVC 1.0の残りの部分がEE4Jに統合されるのは、JCPからバージョン1.0がリリースされてすぐあとだと思います。今年の第2四半期のどこかでそうできるはずと計画しています。この方法でやることを選んだ理由は、移行前にMVCを最終リリース状態までたどり着かせたかったからです。」

InfoQ「MicroProfile 1.3に統合されるRest Client 1.0やJAX-RS 2.0のようなAPIとともに、MVC 1.0のAPIはMicroProfileにうまく合うでしょうか？」

Grimstad氏「技術的には、MicroProfileの上でMVC 1.0のアプリケーションを実行できます。しかし、MicroProfileの目標はマイクロサービス向けにエンタープライズJavaを最適化することなので、MVCがMicroProfile傘下で実際に合うかどうかわかりません。これは補完する技術であり同じスタックで実行して以来ともにとてもうまく動作しています。MVCにとってよりよい場所はEE4J傘下となることでしょう。」

InfoQ「近々MVC 1.0には何がありますか？」

Grimstad氏「MVC 1.0の次の事柄として2月6日から12日まで行われるパブリックレビュー投票があります。そのあと私たちは仕様を確定させる作業を続ける予定です。現時点の計画では2018年の第2四半期に最終リリースをします。」

進捗とコントリビュートの方法は以下にあります。

• https://github.com/mvc-spec
• https://www.mvc-spec.org/
• https://twitter.com/mvc_spec

InfoQ「現在の責務は何ですか？つまり、日々どんな作業をしていますか？」

Grimstad氏「日々の作業としては、スウェーデンにあるCybercom Groupでのプリンシパルコンサルタントとして仕事をしています。日々コードを書き、オープンソースプロジェクトに参加して最新の技術にとどまり続け、カンファレンスで話しています。私はEE4JのPMCにいるだけではなく、JCPのExecutive Committeeにもいます。」

資料

• MVC 1.0の実例解説 Ivar Grimstad氏 (2017年5月22日)
• mvcのサンプル GitHubリポジトリ Ivar Grimstad氏