はてなキーワード: Servletとは
何年か前に、Vue.jsとReact.js比較して、Vue.jsを使うことに決めたんだけど、
最近の風潮として、React.js一強になりつつあるから、またReact.jsのことをちょっと調べ始めた。
正直、React.jsって何がいいんだかさっぱりわからない。
JavaScriptの中にHTMLタグが記述されるJSXって、ものすごく筋が悪いように思う。
大昔、Servletの中でちまちまHTMLタグ出力してた時代に戻ったみたい。
後、これってどういうワークフローで開発してくの？
@kis (id:nowokay) さんの以下の記事についてです。
https://nowokay.hatenablog.com/entry/2021/09/25/042831
ブコメにもあるようにちょっと内容が雑というかわかりにくいせいで賛否両論になってしまっていて、もしかしたら近いうちにアンサー記事が出るかもしれませんが、自分自身の理解を助けるためにも言わんとしていることを推測しつつ、自分の認識もまとめておこうと思い書くことにしました。明らかに誤読してそうな箇所があれば、指摘してください。
まずは前提を書いておかないと論点がぼやけると思うのでいちおう。
その他の前提:
2000年代に入って関数型プログラミングが脚光を浴び始めたのは、コンピュータ資源が潤沢になりパフォーマンスをそれほど気にしなくってよくなったことが大きな理由ではないか、という認識があります。
関数型プログラミング言語の内部実装を読んだことがないので推測ですが、データを不変にするということはその都度メモリ領域を新たに割り当てることになり、そのオーバーヘッドがプログラムのパフォーマンスに影響を与えるので、パフォーマンス要件がをシビアな場合、どうしてもメモリ割り当てや計算効率を考えるとミュータブルにせざるをえないと思います。が、ウェブアプリケーションに限っていえば、データベースアクセスやネットワークアクセスのレイテンシが大きいので、そうした相対的に細かいオーバーヘッドを無視しても（大抵の場合は）問題にならなくなった、というのが「時代」の流れなんだという認識です。
いっぽうで別の観点もあって、REST API や FaaS が一般化して、関数単位で処理を分割し、アプリケーション外部に配置することが当たり前になってきた現状があり、マイクロサービスのようにアプリケーション自体もモジュールの一単位として考えると、アプリケーション内部のモジュール同士でも関数ベースでやりとりする形になっても不自然ではないと考えられます。
元記事にもありますが、RPC の派生（実装？）として生まれた Java の CORBA や Microsoft の DCOM みたいな振る舞い付きのオブジェクト（コンポーネント）を共有しようという世界観は廃れ、REST API のような単一の振る舞い（エンドポイント）とそれにひもづく JSON のようなデータ構造のみを受け渡すやり方が一般的になったアプリケーション間通信の潮流と、計算機資源が潤沢になって再度脚光を浴びた関数型プログラミングが、レイヤーの違いを飛び越えてひとつになろうとしているのではないか、と。
つまり、元記事に書かれている「時代に合ってない」というのは、「データ構造と振る舞いが一体となったオブジェクト」のような「なにか」は、そうした背景があるために、どこにも存在する必要がなくなってきているのではないか、と解釈しました。
なので、以下のコメントはちょっと論点がずれてると思いました。
はあ？「再利用する方法としてはWeb APIが主流」って、その中身をオブジェクト指向で設計することは、全く矛盾しません。 部品化の単位は、慣習や柵などで大きく変わります。オブジェクト指向とはほぼ無関係です。
https://b.hatena.ne.jp/entry/4708813645995359202/comment/suikyojin
なんでサービスとして外とやり取りする話とサービスの内部設計の話をごっちゃにしてんだ。なんか理解度が怪しくない
https://b.hatena.ne.jp/entry/4708813645995359202/comment/ssssschang
たしかに、アプリケーション単位とアプリケーション内部のモジュール単位とでその表現形式を合わせる必要はないんですが、元記事の言わんとしていることはこの一文に端的に表れていると思います。
ソフトウェアの記述をまとめるという視点では主にステートレスな関数を分類できれば充分で、データと振る舞いをまとめたオブジェクトというのは大きすぎる、システムを分割して管理しやすくするという視点ではオブジェクトというのはライフサイクルやリソース管理の視点が足りず小さすぎる、ということで、オブジェクト指向の粒度でのソフトウェア管理は出番がなくなっているのではないか、と思います。
「オブジェクト指向でなぜつくるのか」という本がありますが、「え、いまどきオブジェクト指向でつくらなくない？」っていつも思います。内容的には、もうほとんどはオブジェクト指向関係ないソフトウェア工学の紹介になっていますね。
当該書籍は読んだので後半はまぁわかるんですが、前半は「え、いまでもオブジェクト指向でつくるのが主流じゃないの？」って思ってしまいます（オブジェクト指向の定義が「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」なのであれば）。
Joe Armstrong が "Why OO Sucks" を書いたのが2000年とのことなのですが、そろそろこうした議論は収束に向かってほしいと個人的には思います（とっくに収束していると感じている方もいらっしゃるでしょうけど）。
駄文なので最初にまとめておくと、知識ゼロ異業種から転職して何とかエンジニアとしての人生を始めました、という話。経歴がショボすぎて誰かの道標にすらならないだろうけど書き残しておく。実名で書く勇気はないので増田にて失礼。
PCを初めて触ったのは4歳の頃。
黒くてごついボディが幼心にぐっときたのを覚えている。この記憶があったためか、初めて自分で購入したPCはThinkPadだった。
我が家にインターネット開通。深夜に親が寝てからこっそり2chとニコニコ動画を見ていた。PS2でドラクエ8をやってグラフィックに感動する。まだプログラミングという言葉は知らない。母親のヒステリーと父親の拳骨に耐える日々だった。
地元の高校に進学。友人とﾎﾑﾍﾟ(死語)を作成。html/CSSで文字の色か変えられたりアニメーションをつけられることに気付く。この頃もまだプログラミングに目覚めない。プログラム？理系の人がやるお仕事なんでしょ？という雑な認識であった。
もちろん文系学部に進学。人の視線が怖かったので前を向いて歩けず会話もままならなかったが、制服が可愛いという理由だけでお洒落カフェでバイトを始める。私は阿呆だが、この阿呆さないしは無鉄砲さでエンジニアになったと言っても過言ではない。
新卒入社した会社を3ヶ月で退職。支えてくれる彼くんとかもいなかったので実家でお通夜してた。鬱も発症して薬漬けになった。対面で人と話すことが難しいため、テキストベースで仕事ができる職を探し始める。ここでやっとプログラミングに出会う。
何にせよ無職だから時間は腐るほどある。ヨドバシでカモ丸出しの顔をしてThinkPadを買い、Javaで簡単なアルゴリズムを実装することから始めた。フィボナッチ数列を生成するとかクイックソートを実装するとか。あと5日ぐらいかけてServlet/JSPとMySQLでTODOリストを作った。
2ヶ月ほどJavaをやった頃、無謀にも機械学習に手を出し始める。本を一冊買って隅々まで読み込んだ。この頃から鬱が寛解し始める。プログラミングに夢中になって、1日12時間以上はPCの前に座ってひたすらコードを書いていた。不思議と疲れはなかった。ゲーム用に買ったデスクトップPCにそこそこ良いGPUがついていることが判明したので、Tensorflowでモデルもどきを作り、AI（笑）を組み込んだポートフォリオ用webアプリを3ヶ月かけて作成した。サンプルコードを超える範囲はドキュメントを読む、適宜技術書で知識を補うなどしてなんとかオリジナルと言えるコードをひねり出すこともこの頃覚えたと思う。なお肝心のモデルはチューニングは一切していないわ当然精度も悪いわでその筋の人が見たら鼻で笑うレベルであるが、一人でアプリケーションを作り切ることができたのは大いに自信に繋がった。
ポートフォリオを持って5社ほど受け、うち1社の小さな受託系企業に内定を貰い、無事職にありつくことができた。文系未経験第二新卒を雇う勇気を出してくれた会社には感謝しかない。
会社規模が小さいからか、個人の裁量が大きく、設計から実装、テストまで何でも任せてもらえた。良き上司に恵まれ、主にUnityやスマホアプリの開発を担当し、技術の奥深さ面白さに触れさせてもらった。自身が実装を担当したアプリが世に出ていくことの喜びみたいなものも味わえた。この会社は昨年度退職し、現在は500人規模の自社開発系企業でiOSアプリエンジニアをやっている。スキルは未熟だし対人恐怖的なものも治ってはいないけど、私はプログラミングが好きで、エンジニアとして骨を埋めたいとか身の程知らずにも思っている。
ご覧の通り、私は幼い頃からプログラミングに触れたりモノづくりをしていたわけではない。むしろ目覚めは遅い方である。そういう人でも興味があるなら、ITエンジニア目指してもいいんじゃないか、そうであってくれ、という気持ちで書いた。読んでくれてありがとう。プログラミングはいいぞ。
支持している政党にも支持していない政党にも有権者として堂々と意見を送ろう
ネットをやらない世代は新聞の投書欄などに目を通している。サマータイムは良くないものだということを前提にした投稿が投書欄や川柳欄に載れば載るほど反対意見は浸透する。サマータイムによって悪影響を直接受ける業界にいるのなら、情報提供フォームを使って取材を促すのも良いだろう。
朝、昼、夜の情報番組の影響力は大きい。各情報番組で取り上げるよう要望を各局に送ろう。
ラジオは仕事をしながら個人で聞いたり、職場や食堂や各種待合室で流しっぱなしになっていたりするのでネットとは違う層に届く。情報番組の投稿コーナーにサマータイム反対の意見を送って幅広い層と認識を共有しよう。番組で取り上げるよう要望を送るのもいいだろう。
TwitterやFacebookで「いいね」をしたり、はてなブックマーク上でブックマークをしたりすると、それだけで対象の投稿が多くの人のトップページに表示されるようになる。サマータイム反対の投稿は片っ端から「いいね」してブックマークしよう。
change.orgで探してみたところ、現時点で2つキャンペーンが立ち上がっているようだ。
実家でテレビを見ていてサマータイムの話題が出るなどしたら、自分はサマータイムに反対だということを家族や周りの人に伝えよう。「なんとなく良さそう」くらいに思っている人を「なんとなく良くなさそう」にするくらいのことはできるだろう。デモなどがあれば参加しよう。
ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。
今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。
「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。
タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー
面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。
Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。
かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日にリリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。
今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。
Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日にオラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」（The Network is the Computer）というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。
当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。
1996年の時点にこんな言語が登場したのですから革新的でした。
いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。
プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロード、テンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。
Wikipediaからピックアップすると1.1での大きな機能追加は
といったところです。当初よりJavaの内部文字コードはUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ！というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。
なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。
当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。
JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアのフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。
Microsoft Visual J++ もこの時代ですよ。
Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。
当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。
この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。
strictfpキーワードは浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。
リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassをロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。
1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。
初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。
JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードにコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。
あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。
Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつがMicrosoftだったわけですね。
Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルはMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの！と喧嘩になったわけです。当時のMicrosoftはブラウザまわりでも独自拡張がやりたい放題、標準規格？なにそれ美味しいの？みたいなスタンスをあちこちで見せていたものです。
結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。
JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。
Java SE とは別にこの時代に Java EEがリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。
2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットのサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的なユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。
企業で用いられる社内システムにもServletは多く採用されました。
理由はいろいろ挙げれると思うのですが
というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャはある意味では便利で簡単でした。
もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。
2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホ、ガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。
そこにdocomoのiアプリ、Jフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ！というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリはちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。
iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。
docomoはiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。
この賭場が、将来にAppleのiPhone, GoogleのAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoはSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。
話を2001年に戻しましょう。
Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。
Java Appletがブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。
Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。
端的に言えば入力値が数字かどうか？みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。
また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。
こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい！という要望があったわけです。Webシステム使いにくい！という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。
Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。
RIAの代表とされるのは
あたりです。三つ巴の戦い、どこに軍配が上がるのか！？と注目されましたが、勝利したのはHTML / JavaScriptでした。
Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。
RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントのひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。
しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。
1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。
Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。
言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。
Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。
Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日にオラクルに吸収合併されました。
Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。
やや戻って2007年にAndroidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。
Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。
このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語も次世代へと移りつつあります。業界動向には注視していきましょう。
http://d.hatena.ne.jp/iad_otomamay/20130318/1363596244
この記事。本当に腹が立ちました。
まず質問自体が酷いのが多い。
省略したのは知らないと障害の危険があるので知っとくべきってことで同意なんですが、
これは使うときにググれば良い話。暗記しておくメリットがわからない。
結合テスト中のシステムで、OutOfMemoryErrorが発生しました。UT後ソースコードの変更はしていません。ヒープメモリは足りているようです。原因として何が考えられますか？（筆記解答）
「UT後ソースコードの変更はしていません」という一文が意図不明。単体テスト終わった後にソースコード変更したら、再度単体テスト必要だと思うのですが？この一文は何のヒントにも制限にもなっていないです。
なぜNGなのかというのは「文字列連結演算子(+)では速度が遅いから」であり、StringBufferかStringBuilderのような結合用クラスのappend()を使うことでパフォーマンスは向上する、というところまでが質問の狙いなのかと思いました。もう一歩踏み込むならば、+をしたときにコンパイラでどのようになるかを知っているかどうか、みたいな。しかし結合用クラスにはデメリットもありまして、append()は冗長過ぎて可読性が酷く低下するデメリットがあります。文字列の連結時にクラスをnewするタイミングを調節したほうが速くなることもあります。近年ではマシンのスペックもあがってますので、そんなに気にする部分ではないと思います。そもそも、このStringBufferの仕組みは絶望的に救いがないJava言語の汚点と言ってもよい部分です。なんで文字列の連結方法に複数のやり方を速度だけの理由で取捨選択させるというバッドノウハウなので、早くコンパイラが最適化して一元化くれることを望む部分です。
StringBufferかStringBuilderと書いていて、そういやスレッドに関しての質問がないのはどういうことなのかと感じました。JavaのWeb系ってスレッド重要だと思うのですが。
JavaScriptでHTML要素をid属性の指定により取得するメソッドは何ですか？（筆記解答）
もうjQueryやDojoも使われるようになってきたからこれも知らなくてもいいんじゃないかと。id指定で取れるということとを知っておけば答えにはたどり着けるはず。バッドノウハウです。どうしてJavascriptが最近になって流行ってきたかを思い出して欲しいです。
プログラマーはバッドノウハウの塊でなくてはならない、というのが見えてくる質問内容ですが、最近は覚えなければならないことが多く、技術の更新スピードも早いので、あの質問のような重箱の隅まで暗記するようなことをしていては、重要な部分が抜け落ちているし、暗記の苦手な人は辛いと思います。書籍もネットのような情報の蓄積と抽出する部分は充実してきたので、概念は知っておいて、実装手段はその都度調べるほうが効率的であるかと思います。質問は、応用の効く根本的な部分を問う方がよかったです。
「現実は、もっと凄惨な世界を経て時代が進んでいくようだ。」などと締めくくっていますが、この人は凄惨な世界が嫌なのでしょうか？不安を煽るだけで対策も講じていません。まず、質問の回答を書くだけでも、読んだ人の知識の底上げに貢献できると思うのが普通です。「これは基礎教育をやってれば当たり前」とか言ってドヤ顔して、できない人間を馬鹿にしているだけに見えます。本心では凄惨な世界を望んでいるのでは？としか思えてなりません。
この記事を読んだことで、またSI業界から優秀な人が遠のくことでしょう。こんな人間が居る業界には居たくないと。
どうして悲しみを減らす方向に動いてくれないのかと…
※追記
頭沸騰しててスルーしてしまったのですが「淘汰」って書いてあったので、業界の底上げは望んでないんだなあと、見当はずれなこと書いてしまったなあ、と、後悔した。
UserAgentなしでアクセスすると。。
http://marj.jp/
HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception javax.servlet.ServletException at org.apache.struts.action.RequestProcessor.processException(RequestProcessor.java:545) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:486) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482) at com.hmsystems.common.struts.extension.HmsActionServlet.process(HmsActionServlet.java:28) ...
http://pkga.jp/
HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception java.lang.NullPointerException at com.hmsystems.sns.presentation.struts.RequestProcessor.processForwardConfig(RequestProcessor.java:91) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:279) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482) at com.hmsystems.common.struts.extension.HmsActionServlet.process(HmsActionServlet.java:28) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:507) at javax.servlet.http.HttpServlet.service(HttpServlet.java:696) at javax.servlet.http.HttpServlet.service(HttpServlet.java:809)
両方ともHM SYSTEMSさんが作っていたんですね。
http://www.youtube.com/watch?v=k6_1P2EKKYo&feature=PlayList&p=56E3E51E650A4CE7&index=0
ちまたじゃ、みんなフレームワークのことを当たり前のように論じててすごいなーと思うんだ。尊敬するぜ。だから、ミーハーなオレもフレームワークが気になって仕方ない！
だから、30歳近いプログラマのオレがプライドを捨てて優秀なハテナ住人に聞くが、
だが、そこまでだ。
Javaだと、Struts、Spring、Seasar、Wicket等をよく目にするけどよぉ、ドキュメントの量どんだけだよ。
入門ドキュメントだけ見ると簡単そうに思えるけど、仕事で使えるレベルまで理解が深まるまでどんだけ時間かかんだよ。
起動遅い、動き遅い、定型パターンを外れたら、やる方法が見つかんねー。
で、苦労して作ってもよぉ、結局は、HTMLがピロッって出力されるだけで、見てくれが変わるわけでもなく、全然努力が報われん。
これって、どゆこと？
Servlet+JSP+簡単なライブラリ 程度で十分じゃね？
PHPだと、Zend Framework、CakePHP、symfony等をよく目にするけどよぉ、ドキュメントの量どんだけだよ。
入門ドキュメントだけ見ると簡単そうに思えるけど、仕事で使えるレベルまで理解が深まるまでどんだけ時間かかんだよ。
デバッガの使い方分かってねーオレが悪いとは思うんだが、開発効率悪いぞ。(フレームワーク以前の話だが…)
統合開発環境何使えばいいの？わざわざクラス名や関数名覚えてられんぞ。(フレームワーク以前の話だが…)
何で、拡張子変えたがる。何で、変なテンプレートエンジン使う。エディタで認識されねーから開発効率悪いじゃねーか。デザイナがコーディングした分かりくいHTMLコードをよ、何で編集してるわけ？
ついでに聞くけどよぉ、ORマッピングライブラリって使えるの？
確かに書くコード量は少なくなっていいんだがよぉ、目に見えて遅いと思うのはオレだけか？
ディスクアクセスは明らかにボトルネックになるのに、巨大なライブラリのコードを毎回走らせるんだよ。普通のサーバじゃ余裕なの？
話題がそれたが、
実は、みんな、上司や先輩に言われて使ってるだけなんじゃないの？
ハテナ住人の優秀なエンジニアは、どんな目的でフレームワーク使ってんだ？教えて偉い人！
ま、誰も見ないんだろうけど。
芸術性って・・・。
だったら言語から作れよ。
芸術性は見る人に訴求するものがあり、人によって解釈が違う。そういう定義の言葉だろ。
素敵すぎるだろそんなソース。
芸術をも感じさせるソースを見て、どうやったらこんな独自進化を遂げられるんだよと何度ヒザをついたことか…。
人を満足させるために作るのか、自分が満足するためにつくるのか。
自分を満足させるために作り出したものが結果的に人を満足させるということは殆どない。
だって最初のスタート方向が違うんだもの。
コーディングにポリシーはもっていてもいいとおもうけど、そのポリシーがアクションの枷になっているのだったら本末転倒だとおもうな。
どんな立派な機能があるクラスだろうが最初で弾かれて落ちてこないだったら意味ないじゃーん。
というかApp Engineってなに？
つかって何かやりたいとまだ思えてこない以前にApp Engineがまだ未チェック。
PythonはGMOの証券会社が外部APIを公開したのがPythonだった。うんこだった。
勉強するには至らなかったが、そんな特殊だったという印象はもってないな。
plのcgiがあって、そっからasp,jsp,cfmという時代をえて、
php5,RonR,Pythonとかになってきているわけだが、時代は違えどひとつ覚えておけば学習コストっていう意味は殆どかわらないと思うよ。Oracleを覚えてからSQL-serverにいこうがpostgresqlにいこうがmysqlにいこうが一緒みたいなもの。
後継に位置するものであれば必ず似た機能はある。
むしろiis-ocxとかtomcat-Servletとか、ns-ldapとかそういう周辺が違うのであって、
基本的な部分に収まっているあいだは殆ど一緒じゃない？
今の時代みたいに殆どがApacheごにょごにょしただけで動く時代ならphpもRonRも殆ど変わらないと思うな。
所詮LL。
いまだってデータ処理はDBに任せたり、画面だってjavaなりFlashにまかせるじゃん。
LLがクラスに対応したときはおお！！と思ったし、どんどん進化しているのは感じる。
そんな感じで、どんどん面白いのがでてくればいいとおもう。
言語なんてこだわりもって選らんだところで変遷は激しいよ。
コールドフュージョンがどれだけすばらしいかについてプレゼンしてた坊を思い出すたびに涙を禁じえない。
いい音楽が売れるんじゃない。
話題になる音楽が売れるんだ。