それは置いておき、先週の火曜日から、帰宅後にビールを飲みつつ1〜2時間/日のスローペースでJavaの勉強を始めました.
以前もJavaの勉強をしようとした事があるのですが、何故かクライアントアプリケーションから取りかかってしまい、敢え無く挫折 orz
苦い経験(?)から、今回はWebアプリケーションから取りかかってみる事に.
結果から言えば「最初からWebアプリケーションで始めていれば良かった」と激しく後悔中です orz
これなら何とか勉強できそう.
今はStruts/Struts2を使って
勉強する環境にしても、
・WindowsまたはLinuxまたはMacOS
・J2SE(JDK/J2 SDKとも呼ばれる…名前が変わりすぎw)
・Eclipse
・WTP(Web Tools Platform)
・Tomcat
が整っていればOK.
lightmaterialの場合Eclipse+WTPは既に入れていたので、J2SEとTomcatを入れるだけでした.
今までWebアプリケーションはJ2EEを導入してないと開発出来ないものだと思っていましたが、そう言う訳では無く、本当にEnterpriseな環境を構築する際に必要(と言うか便利)なだけの様です.
私がJavaを今まで敬遠してきた理由は、「なんか複雑そう」「EJBとかJavaBeansとかDIとか意味不明」等々、専門用語やら色々な要素が関連しあって動く複雑な物、と思っていたからです.
ASP/ASP.NetにしろPHPにしろ、(PHP用のFrameworkは別として)ほとんど言語環境単体で動く事を考えると、どうしても敬遠しがちになります(あくまで個人的な感想).
が、実際に触ってみると「初歩的な事は」意外とそうでもありません.
初歩的な事を勉強するのに、EJBもDIも気にする必要はありませんでしたから.
今の所Java(Webアプリケーション限定)について把握したのは、
1. 完全にオブジェクト指向言語(あたりまえ)
2. メモリの管理がちょっとだけ特殊?
3. パッケージという概念がある
4. 現状の標準的構成として、ページを描画するJSPとコードを担当するServletで構成するのが一般的
5. Frameworkを使わないと死亡
6. 描画を担当するJSPも初回アクセス時にビルド(?)される
7. ファイル構成が少し特殊、各種設定がXML
と言った所でしょうか(間違えてる可能性大).
[1]は最初から分かっていた事なので、特に戸惑いはありません.
.Netにしろ、正しくコードを書いていればオブジェクト指向な記述になりますし、PHPにしてもオブジェクト指向な記述の仕方が現状の標準的なコーディングかと思います.
[2]のメモリ管理ですが、基本的にはオブジェクトが参照されなくなった段階で、メモリから破棄される様です(正確に言えば、ガベージコレクションの対象になるのかな?).
その為、通常はC/C++の様に明示的に破棄する必要はありませんが、参照サイトによってはnullで参照されなくなった事を明示すべきだ、との記述が見受けられました.
まぁ、この辺はVB/ASP.NetでもNothing指定すべきだ、とする傾向がありますので、これも戸惑いはありません.
[3]のパッケージ.
これはクラスライブラリの様なもの、と私はとらえてます(あってるかは不明).
今まで「org.apache.xxxx.....」などと言うファイルを見かけた事がありましたが、何の事やらさっぱり不明でした.
この「org.apache.xxxx.....」の部分がパッケージ名(?)にあたる様です.
また、パッケージ名は配布や流用等を行う事が多いので、他のパッケージ名とかぶらないように、開発元のドメインを逆さにした名称を付けるのが一般的との事.
それで「org.apache」だの「org.eclipse」だのと言うファイルがある訳ですね.
すごく納得しました.
[4]のJSPとServlet.
これもASP.Netをやっていれば何も戸惑う事はありません.
ASP.Netで言う所の、「xxx.aspx」ファイルと「xxx.vb」ファイルの関係と考えればあまり大きく間違える事は無いと思います(厳密には違いますが. JSPの場合Servletが無くても動きますので).
現状のコーディング方法として、「JSPには極力コードは書くな」「コードはServletに書け」と言う傾向がある様です.
[5]のFrameworkについては、PHPも結構同じ事が言えると思いますが、Javaの方がよりFrameworkに依存している様に思います.
そのため、Frameworkを使わずにプログラムを書こうと思うと、非常に雑多なコーディングになりそうです.
画面遷移ひとつとっても、ServletからJSPに渡す変数を一々setAttribute/getAttributeしたりDispatcher作ってページ呼び出したり…単に私が簡単な方法に気付いてないだけかもしれませんがw
これらJavaの代表的なFrameworkとしてStruts/Struts2、JSF(JavaServer Faces)があります.
それ以外にもあるのかもしれませんが、今の所勉強の対象にするつもりなのは、この2つのFrameworkです.
特にJSFは標準機能としての提供がされる予定らしく(?)、今後のJava開発環境では必須になるのかもしれません(StrutsはApacheプロジェクト).
ただ、StrutsとJSFでは重点部分が異なる様で、StrutsはController部分、JSFはView部分(?)に重点を置かれたFrameworkらしく、今ではStruts+JSFで動作させる方向にも行きつつある様です(Struts2から?)ので、両方勉強しておいて損は無いだろう、と思ってます.
[6]はよく分かりません.
よく分かりませんが、初回アクセス時にビルドする事で、その後の処理を高速化する様です.
この辺は後々触っていれば分かってくるだろうと勝手に妄想中.
[7]のファイル構成については、どちらかと言うとTomcatの構成なのかもしれませんが、まだその辺は良く分かっていません.
少し特殊と言うのは、「WEB-INF」や「META-INF」と言った設定用のディレクトリが最初から定義されていて、そこに設定ファイルやらライブラリやらビルドしたServletやらが設置される様に半分強制されている事です.
これらのディレクトリには、ブラウザ経由で直接アクセス出来ない様になっています.
まあ、まとめて放りこめるから便利と言えば便利ですが、WTPで作ったプロジェクトの標準ディレクトリ構成と少々あってないんですよね…これどうにかならないんだろうか orz
また、基本的に各種設定はXMLファイルに記述する事になります.
Frameworkの設定もXML.
あれもこれもXMLです.
その他JavaBeansなんてのもありますが、この正体が分からない.
JavaBeansで検索すると、GUIなビルダーとの連携により云々と書かれているものもあれば、単純にProperty/Getter/Setterを持ったクラスファイルだよ、と言った書き方のサイトもありました.
更にはStrutsのActionForm部分をBeanと書いている所もあり、現在かなり混乱中ですw
取り敢えずひとしきり触ったら、Javaについてのメモを順次記述予定.
※下の画像は単にJSPのみでの動作例です. ServletもStrutsも何も使ってません.
3 件のコメント:
お邪魔いたします。Confirm-Addressを開発しているkenmazです。
バグ報告の件ではお世話になりました。ブログコメントでご報告いただいた内容から、怪しい箇所を修正してみましたので、以下から.xpiファイルをダウンロードして、お試しいただけませんでしょうか?
http://kenmaz.is-a-geek.com/confirm_address/confirm_address_103.xpi
アップデート手順などご不明な点がありましたら、またご連絡ください。
申し訳ありません。リンクが途切れてしまったようですので、再投稿いたします。
ダウンロード
連絡有難う御座いました.
アップデートした結果、kenmazさんのblogに書かせて頂いた通り正常に動作する様になりました.
少しでもお役に立ったのであれば幸いです.
コメントを投稿