この日記は私的なものであり所属会社の見解とは無関係です。 GitHub: takahashikzn

Struts1.xがEOL



2014-04-23追記
昨今の状況を鑑みるに、新規案件でのStruts2の採用は余りお勧めできないと言わざるを得ません。
僕はStruts2およびOGNLのソースコードを実際に読み込んだ上で、自分で危険と判断したところは独自でパッチを当てているため、報告されているような脆弱性に対して、最初から耐えられるようになっています。
そもそも、OSSを採用するというのは、そういうことですし。
ただし、新規案件でそのような運用を最初から織り込むのは正しい判断とは言えないでしょう。




Struts1.xがEOLになりました。お疲れ様でした。
5年ほど更新が無かったので、やっと正式にEOLかという思いです。


さて、国内における一定規模以上のWebシステム構築では、ベンダーお抱えの『フルスタック型Webアプリケーションフレームワーク』を使うことが前提になります。NTTデータ系列ならTerasolunaとか。


で、その手のフレームワークは大抵、作られた時代がちょうどStruts1.xの旬であったことから、Sturts1.xがベースになっています。
それからおよそ10年弱、Struts1.xはそれこそ骨の髄までしゃぶる勢いで魔改造が加えられていった結果、ソースコードの隅々まで研究され尽くしてきたわけです。
RequestProcessorのソースを解析して激しく拡張するとか、昔よくやったわーという懐かしさを覚える方も多いでしょう。

さて、どうすんの?

これから各ベンダーが取りうる作戦は以下の2つかと。

  1. Struts1.xの保守を自前で行う
    • 応用編: Struts1.xの保守を、国内の業界全体の取り組みとしてオープンソースで行う
  2. 他のWebアプリケーションフレームワークに乗り換える


おそらく現実的なのは、以下の理由により1.でしょう。

  • そもそも2008年以来ずっとそうしてきたのだし、これからも現状維持すれば良い
  • Struts1.xで動く業務システムは星の数ほどあり、そいつらの保守を切れるわけが無い
  • 隅々まで研究され尽くしたStruts1.xの保守はぶっちゃけカンタン
  • 国内のコーダーは、JavaでWeb開発を経験した人の大半はStruts1.xの経験しか無い上、そもそもStruts1.xで何ら困ってはいない
    • (少なくとも、僕が活動している領域ではそういう話ばっかりです)


しかしEOLになった製品をこれからも新規案件で使い続けるのはヤダ!という方もいるでしょう。
じゃあ乗り換えるとしたら選択肢は何なのか…?という話になるわけですが、僕はStruts2をオススメします。
洗練された最高のフレームワークだ!と言うつもりはありませんが、

  • Struts1.xの正統な後継製品である
    • スーツたちを説得する際、こういうのはバカにならない
  • 開発のワークフローが概ね同じ
    • 「アクションフォームを作って、アクションクラスを作って、JSPを書いて…」という流れを変えなくて良い
  • convention pluginを使えば設定ファイルをほとんど書く必要が無い
  • 国内では比較的少数だが、世界的に見ればユーザー数は多い
    • すなわち、長期間のサポートが期待できると考えて良い

という特徴があります。Web上での評価は少々芳しくないようですが、Struts1.xの移行先として捉えるなら悪くない選択肢のはずです。
各種Webフレームワーク比較は色々とありますので、詳しくはググってください。


なお、いくら正統な後継とは言え、Struts1.xに依存しているコードは全部捨てる覚悟が必要です。

今ならPlay (Scala)でしょ〜!!

...という声も聞こえてきますが、それはハイスペックエンジニアを集められるベンチャーが自社サービスで使う場合の話です。


現実的に揃えられる要員のスペックはお察し下さい的な、有りがちなエンタープライズ案件でScalaを適用するのは無茶です。オススメしません。
そういう現場で求められているのは、Ceylonみたいなアプローチだと思います。


アナウンスページによると、Struts2の他には

などがオススメされているようですが、この中ではSpringMVCが適用事例を割と耳にします。

最後に

Struts2への乗り換えを検討されている担当者様へ。
当方、国内ではまだ少数であると思われるStruts2の適用案件を多数こなし、ソースコードもかなり読み込んできました。
もしお手伝いが必要でしたら、お声がけ下さいませ。