JSP上でスクリプトレットを使用することは悪？

Question

スクリプトレットは悪？

数年前に、javaによるweb開発の外部研修に出席した際に**「JSPでスクリプトレットを使用するのは禁止します。カスタムタグもしくはEL式で記述してください。」**と言われたのをふと思い出しました。

現在、社内で開発しているアプリケーションでは、かなり古いシステムなので仕方ないのでしょうがスクリプトレットをバリバリ使用しています。。。
そのせいでスクリプトレットに慣れてしまっているので、何故禁止にされたのか...理由が思い出せません。

スクリプトレット禁止の理由ももちろんですが、「むしろ使ったほうがいい」「EL式より（カスタムタグより）○○を使ったほうがいい」などのご意見があればお聞かせいただければと思います。

質問の意図

先日、私が全く別の新しいプロジェクトに携わるようになることが決まり、新規にサーブレットでwebアプリケーションを作成することになりました。
その時に、新しく作るならどのような構成で作っていこうか考えているうちに思い出し、今後の開発の参考に出来ればと思っております。

また、頂いたご意見は開発の参考にはさせて頂きますが、どちらかというと個人的な疑問の方が強いので有意義にディスかション等して頂けると良いかと思います。

私自身、まだまだ未熟な一開発者ですので、ご教授いただければと思います。

環境・条件

• java
• JDK8
• servletを使用したMVCモデルのWebアプリケーション
• 社内独自のフレームワーク（←この開発も行っています。)

Answer 1

JSP内でスクリプトレットを使用してロジックを記述すると、MVCモデルにおけるViewとModelあるいはControllerとの適切な分離が困難になります。結果として、とりわけ長期に渡る大きなプロジェクトほど、以下2つの問題を抱え込むことになるでしょう。

• 保守性の低下
• 再利用性の低下

さらに上記に付随する問題点として「コードの可読性の低下」や「開発作業の分離性の低下」なども挙げられるでしょう。

保守性の低下
開発では「ビジネス･ロジックのコードを修正･変更することなく表示だけを修正･変更したい」、もしくはその反対に「表示のコードを修正･変更することなくビジネス･ロジックだけを修正･変更したい」という状況は頻繁に発生します。その際に両者の修正･変更がお互いに影響を及ぼさないことが理想ですが、JSPでスクリプトレットを記述していると、修正･変更の影響範囲や依存関係を特定することが困難になります。特定が困難になれば、当然、修正･変更によって想定していなかった問題が発生する可能性が高くなります。

再利用性の低下
スクリプトレットで記述したロジックは基本的にそのJSP内でのみ利用可能であり、他のプログラムから利用するための「再利用性」や「汎用性」が著しく低下します。

したがって、表示と強く関連するロジックには「カスタム･タグ」を、純粋なビジネス･ロジックに関しては「JavaBeans(POJO)」や「EJB」を使用することで、それらのロジックをコンポーネント化し、再利用性や汎用性（結果として保守性や可読性、作業分離性も）を向上させることができます（またWebサービスであればJAX-RSを使用することが可能）。JSPではこれらのコンポーネントと共にELを併用することでメリットを補完することができます。

Comments

[jakelizzI]

amadablamさん、ご解答ありがとうございます！
また、初心者にも分かりやすく丁寧にご説明いただきありがとうございます！

* 保守性の低下に関しては、現在のプロジェクトにおいて身をもって感じておりますが、今までと同じ方法を取ろうと思っている人も中にはいるとは思います。「保守性の低下」という言葉自体はすぐに思い浮かぶのですが、具体的に記述して頂き、はっとさせられました。また、今後のことを考えるとその点を留意したほうが良いと思いました！

* 再利用性の低下に関してはあまり頭にはありませんでした。自分のなかで、JSPにおける再利用＝コピペというイメージだったので。。。考えてみればすぐなのに何故その思いが無かったのか。。。慣習とは怖いですね(TT)今一度勉強いたします！

Answer 2

100%禁止というわけではないですが、非推奨です。

Webサーバは性質上、マルチスレッドで処理されるのに、
スクリプトレットがスレッドセーフでないのがその理由だったかと。

JSPスクリプトレット メモ(Hishidama's JSP-scriptlet,directive Memo)

私的には、危険性を理解した上で使うならば、自己責任で・・と思います。

Comments

[jakelizzI]

スレッドセーフかどうかの観点は欠如しておりました。確かにそうですね。。。スレッドに関する知識も無いので使用を禁止したほうが吉な気がします！ご教授いただき、ありがとうございます！

[amadablam]

スクリプトレットがスレッドセーフではないというのは意味がよくわかりません。単純にスクリプトレットがスレッドセーフでないと言ってしまうと、サーブレットのserviceメソッドおよびそのオーバーライドメソッド（doXxx）すべてがスレッドセーフでないと言っていることになります。

[akio221]

全てがスレッドセーフではないと述べているつもりはなかったのですが、そう取れる回答になっているので、以下追記します。

マルチスレッドで処理されることを考慮せずにstaticな変数やメンバー変数をソースを書くと、変数の内容がスレッドで共有され、結果、スレッドセーフではありません。（サーバ側のjavaコード）

スクリプトレットの場合、特に意図せずに書くと、同様のコードを量産できるため、そこを理解せずに安易にスクリプトレットを使用することはお勧めできません。

しかし、未だにJSP処理系がスクリプトレットを処理してくれる以上、許容されるべきだと思います。ゆえに、個人的には、理解した上で使用するならば、自己責任で利用すればよいと考えます。

[amadablam]

「マルチスレッドで処理されることを考慮せずにstaticな変数やメンバー変数をソースを書くと」とコメントされていますが、スクリプトレット内にstatic変数やメンバー変数を書くことはできません。したがってスクリプトレットを使用してそのような「同様のコードを量産」することもできません。
基本的にスクリプトレットを使用することと、アプリケーションをスレッドセーフな設計にすることは別問題だと思います。スクリプトレットを使用してもスレッドセーフな設計はできますし、逆にスクリプトレットを使用しなくてもスレッドセーフではないアプリケーションを作ってしまう可能性はあります。
また、「未だにJSP処理系がスクリプトレットを処理してくれる以上、許容されるべき」と書かれていますが、処理系が古い仕様との互換性を保つためだけに、その処理機能を残していることはよくあり、そのことをもって「許容されるべき」と考えるのは安直です。カスタム･タグやELがスクリプトレットのデメリットを解消する目的で導入された以上、明確で不可避な理由がない限りスクリプトレットを使用する合理性はないと考えられます。

[akio221]

どうにも、気になって調べてきましたが、長い間、スクリプトレットとJSP宣言を混同していたようでした。
http://www.asahi-net.or.jp/~gq4r-msm/html/k-age63/jsp/html/java-web300-jsp-script.html

前半部分について、私の誤解が含まれておりましたので、スクリプトレット、と記載した部分はJSP宣言、と読み替えてください。で、スクリプトレット自体はスレッドセーフでした。ごめんなさい。

あと、蛇足的ですが、私の書いた「許容されるべき」は、あくまでも、あなたのいう「明確で不可避な理由」があれば「許容されるべき」であって、「安易に使用すべきではない」という立場には代わりがありません。

[amadablam]

「許容されるべき」に関しては、やや言葉の上げ足取りになってしまっていたようですが、いずれにしてもスクリプトレットとJSP宣言の混同やスレッドセーフに関する誤解がクリアになったようなのでよかったです。

[jakelizzI]

恥ずかしながら、私はJSP宣言とスクリプトレットに関する区別がついておりませんでした。分かりやすいURLまで添付して頂き、ありがとうございます。