JavaのWebアプリケーションを保守・カスタマイズしていく中で失念していたこと

結論から言うと、

Servlet ContainerのサポートするServlet APIのバージョンがどんどん上がっていくので、

それに伴って自アプリの使用するServlet APIのバージョンが非推奨やサポート外になっていくこと。

で、そのことを顧客に計画的に伝えて提案し続けること。

上記のことを忘れがちだったなぁ。

なぜ、そんなことを考えたかというところを順を追って整理してみる。

[前提] Tapestry 4.0で作成したWebアプリケーションを細々と保守したり、カスタマイズしたりして8年くらいになります。

1. 今年またある程度まとまった規模のカスタマイズが発生。
2. 今までJetty 6系のServlelt Containerを使っていたけどそろそろ古いので変えよう。
3. Jettyの8や9だとWindows Serviceにするexeが同梱されていない。
4. じゃぁTomcatにするか。
5. Tomcat7.0だけどServlet API 3対応なんだ。ふーん。
6. あれ？Tapestry 4.0はServlet API 2.3推奨だったけど随分バージョンあいちゃった！
7. むむ？調べると非推奨なメソッドも増えているしもしかして微妙？

という経緯がありました。

ほかにもJava VMのバージョンも考慮しなきゃいけないし、細々と保守やカスタムが続く案件だと機能の改修とかだけではなく、環境面の更新も必要なのだなと思った次第です。

付け加えると、環境面からの更新はほとんどお客さんの意識に上がってこないので開発する側が先を読んで提案していく形でないと予算の確保やスケジューリングで後手を踏むことになってしまんですね。

という教訓でした。