  |
はてなキーワード: ガベージコレクションとは
開発環境がエラー出してるものは少なくとも完成品じゃないぞ！提出してくるな！
ググってコピペするのやめろォ！いや百歩譲って、理解してないのにコピペするのやめろ！動いてない！
パターンマッチング的にコード書くのやめろ！なんで新人なのに手癖が無茶苦茶ついてんの？これググってコピペしてない？いやしてんのかい
動くには動くけど作っただけですぐ捨てられたメモリが意味もなくジャブジャブとガベージコレクションの餌になってるのだが！だが！石油王か大富豪なの？
独特すぎるアクロバットやめろ！研修担当はたくさんの新人を相手にしててあんまり暇じゃないんだからお前の一見動かないように見えて実は正解してるコードとか読み解くの大変なの！なんなのマーベリックなの？研修担当はコードゴルフのフェアウェイじゃありません！もう開発現場行けよお前
つまり、物語にガベージコレクションの機能があれば、自然と伏線は回収されるのではないか
参照をカウントしてゼロになったときにデストラクタが発動するだけでも構わない
つまり、スコープから外れるとスタックなどに確保された変数の領域が開放されるように、
物語のある地点のスコープに含まれるもの、近くてどうでもいいものは記憶からも消えていく
しかし、グローバルではないが、どれだけ広範囲なのか分からない伏線のようなものがあり、
物語が如何に進行しようとも、そのポインタだけはキープしている
ときどき登場人物が思い出したかのように伏線を語るとき、参照カウントが追加される
そうやってカウントが増えたり減ったりして、
最後は大団円でauto release poolの中に登録された伏線がドバーッと開放されていく
だから伏線にはポインタのように誰が所有しているとか責任を取るべきみたいな概念が当てはまるのかもしれない
つまるところ、メモリにゴミを置いたままプロセスが終了するということであり、
それでも問題ないのはOSのように周囲が尻拭いしてくれるからである
作者はコアダンプを吐くべきだ
「後藤さんのこと」を読んでめちゃくちゃ面白いと思ったのがおよそ１０年前。大学生の頃だった。
この短編集は今でもかなりの名作だと思っているし、ハードカバーを買って大事に持っている。（小説は絶対に文庫版で買うという決意を持っているこの俺が、だ）
どの短編もこれまでに読んだことのない新鮮な後味で、何度でも読み返した。
そこで読書メーターやレビューサイトを見ると、「数学や物理を使って書かれた純文学」みたいな書評が目についた（ちゃんとした表現は覚えていない）。
そうかな。と思った。
なるほど。確かに、「さかしま」「考速」「ガベージコレクション」あたりには、理系的なモチーフがふんだんに埋め込まれていたし、その中には確かに数学や物理の単語もあった。
どちらかというと情報系分野の香りの方が強く感じたけど。まあ情報も数学の一部だしな。
でもなんか、「数学や物理を使って書かれた純文学」みたいな批評にはなんとなく頷けない感覚があった。
言い忘れてたけど、自分は一応ちゃんとした大学の数学科出身であるので、数学や物理の単語を言われたらそれが何のことかはわかるし、学問においてどういう立ち位置だったりどう使われるか、はおよそ知ってる（あんまり高度なのは無理だけど）。
だからこれらの話はすごく面白く感じた。理系用語が雑に使われてたから引っ掛かったとか、そういうことじゃない。むしろ日本語としてこれ以上ない適切な位置にそれらの単語は置かれていたのではと思う。
次に「バナナ剥きには最適の日々」を買った。これも素直に面白いと思った。
「equal」には妙な居心地の悪さを感じたけど、「捧ぐ緑」は今考えても円城塔の最高傑作なのではと思えるくらいだ。
なので最初に違和感がはっきりと形になったのは、その次に買って読んだ、「Self-Reference ENGINE」ということになる。
しかしとても残念なことながら、あなたの望む本がその中に見つかると言う保証は全くのところ存在しない。これがあなたの望んだ本です、という活字の並びは存在しうる。今こうして存在しているように。そして勿論、それはあなたの望んだ本ではない。
皆はこの小説をどのように楽しむのだろう。
言っていることは理解できるし、示唆的ではある。人に何かを「考えさせる」文章でもある。しかしそれは「考えさせる」だけで、後に何も残さない文章でしかなかった。
ストーリーもあってないような状態。各章の繋がりもバラバラだし、場面は突然切り替わるし、急に新キャラが出てきて急に退場するし、何もかも説明が不十分で、衒学的な、鼻につく文章だけが延々と続く。
端的に言って、「最初から最後まで何も言っていない」。文字を無駄に消費しているだけの、中途半端な文字列らしき何かだと思った。
そして「エピローグ」を買った。
何故って彼はエージェントで、エージェントとは人間よりも器用にチューリング・テストをクリアすることのできるスマート・クリーチャにしてオーバー・チューリング・クリーチャだからだ。
人間に理解できるのはせいぜい、N文字を利用して作成可能な全ての文章であるにすぎない。Nはある程度の大きさのところに留まり、そこには有限個の文章しかない。
「敵艦影、三。天頂方向より接近。ダミー放出。並列存在を開始。複雑性迷彩が起動しました。オーバー・チューリング・テスト実行。成功。成功。失敗。失敗。失敗。当該宙域には、法則69805f9944ed4298311d0cdaa75da2629d6f3bb3756455d504243fla6c565f75が適用されていません。」
はあ。これでやっとわかった。
彼は詩を書いているんであって、小説なんか最初から書く気が無いのだ。
円城塔の紡ぐ文字列の並びは確かになんとなく美しいと思う。なんか感性に訴えかけてくる。なんか良いこと言われているような気にさせられる。
しかしその実、中身が全くない。その点に限って言えば詩としても程度が低いように思う。詩にも訴えたい内容とかあるからね。
そしてそれに「ていよく」使われているのが、SFだったり、数学や物理の言葉だったりする。
数学やSFが、詩を美しく紡ぐための新しい言語の代わりにさせられている。これがなんとなく違和感を覚えた原因だったのだ。
つまりこれを「詩集」ですと言われて手に取ったら、「おお、面白い詩だね」といえるんだけど、「小説です」と言われたから、「小説か？？」となってしまう。
軒並み、「なんだかわからないけどすごい」「深淵」「自分には理解できない新境地と感じる」「文系殺し」といった単語が並ぶ。
端的に口をそろえて「理解できませんでした」と言ってるだけだろうが。理解できないものを、適当に高評価するんじゃないよ。ボーッと生きてるにもほどがあるでしょ。
詩の材料にされている数学や物理の言葉がわからないものだから、その意味不明さに脳が酩酊させられてるだけだよ、それ。酒飲みみたいにその酩酊を楽しみたいなら、いいんだけどさ。
自分は文系だから、知識がないから、それらの語彙が入ってこないだけで、ちゃんと語彙力があったらそこに何か深い意味が込められているんじゃないかと思った？
なかったよ、なんにも！！
さらに頭にくるのはそのやり口で芥川賞なんか取っちまったところだよ！
選考委員も、軒並み騙されてんじゃないか。誰か一人でも意味わかってたんか？「道化師の蝶」のモチーフとなっているという、自己言及プログラムを一人でも書いてみたんか？？
俺は、この世に理系人間と文系人間とやらがいるとはあんまり思ってないけど、もし芥川賞の選考委員がそういったSFや数学物理に疎い人で構成されているんなら、円城塔作品はまさしくその脆弱性を突いたクラッキングだよ。
以下が「道化師の蝶」受賞時に高評価をつけていた選考委員のコメントだ。高評価だぞ？低評価じゃない。よく読んでほしい。
- 今回の「道化師の蝶」で初めて私は、「死んでいてかつ生きている猫」が、閉じられた青酸発生装置入りの箱の中で、にゃあ、と鳴いている、その声を聞いたように思ったのです。
- 小片たちがつなぎ合わされ、一枚のパッチワークが縫い上がり、さてどんな模様が浮き出してきたかと楽しみに見つめてみれば、そこには模様など何も現れていなかった。/もし自分の使っている言葉が、世界中で自分一人にしか通じないとしても、私はやはり小説を書くだろうか。結局、私に見えてきた模様とは、この一つの重大な自問であった。
- それ自体が言語論であり、フィクション論であり、発想というアクションそのものをテーマにした小説だ。/この作品は夢で得たヒントのようにはかなく忘れられてゆく無数の発想へのレクイエムといってもいい/こういう「やり過ぎ」を歓迎する度量がなければ、日本文学には身辺雑記とエンタメしか残らない。いや、この作品だって、コストパフォーマンスの高いエンタメに仕上がっている。二回読んで、二回とも眠くなるなら、睡眠薬の代わりにもなる。
『二回読んで、二回とも眠くなるなら、睡眠薬の代わりにもなる。』
完全に酔っぱらってるじゃねえか。
あと、円城塔は、いい加減に繋がっているようで繋がっていない短編の寄せ集めを長編と言い張るのをやめて、最初から最後まで一貫して繋がった長編を書くべきだ。詩集だから無理か。
imageの発音は/ˈɪmɪdʒ/ カタカナで書くならイミッジといった辺りだ
できないが，それにしたって/ˈɪmɪdʒ/をイメージは乖離しすぎだ
このイメージ問題は，「lrがどっちもラ行」や「thがサ行になっちゃう」とは根本的に異なる部分がある
lrやthは純粋に発音の問題だ 原因は日本語にはそういう音がないからだ
にもかかわらず「イメージ」になったのはimageという綴りが原因だろう
-ageという語尾はいかにも/eɪdʒ/（エイジ／エージ）と読みそうだが，実際そうなるのは1音節のage,stage,page等々とengageぐらいで，多くは/ɪdʒ/になる
ただでさえ例外的なうえにaを/ɪ/（イ）と読むのはかなり「不自然」なのでエージが定着したのだろう
-ageで終わる単語は多いので，イメージ問題も広範囲に波及する
ランゲージ，メッセージ，ダメージ，パッケージ，アベレージ，コテージ，アドバンテージ，ストレージ，マネージャー，……
特筆すべきはガベージコレクションのガベージ(garbage)だ
発音/ˈɡɑrbɪdʒ/から考えるとむしろガの方を伸ばすべきだが，ガーベージだとおさまりが悪いからかこのようになっている
一方-age語尾の（私の思想に基づく）「優等生」はキャリッジ(carriage)とマリッジ(marriage)だ
直前のiに引っ張られた結果と思うが，「キャリエージ」「マリエージ」となってもよさそうなのにイッジに落ち着いている
中間的なものとしてビレッジ(village)，レバレッジ(leverage)というパターンもある
ガレージ(garage)はまた別の話でむしろマッサージの仲間だったりする
繰り返しになるが英語の発音をカタカナで正確に表すことはできないわけで，イミッジも十分/ˈɪmɪdʒ/からは「かけ離れて」いる
コンピュータ言語って世の中に山ほどあるけれど、それぞれの言語ごとに特徴がある（特徴のない言語は廃れていく）。
あまり言語に詳しくない人相手に、俺の考えるそれぞれの言語の特徴を書いてみようと思う。
なお、取り上げるのはある程度広く使われている言語に限りたいと思う。
| 言語名 | 概要 |
|---|---|
| C言語 | 高速動作するバイナリ生成を目的としたコンパイル言語。だいたいどんな環境でも使えるがバグ出やすい |
| C++ | マニアック言語、高速、習得大変 |
| Java | サーバで高速かつ安定に動作するコンパイル言語、大規模でよく使われる |
| C# | 主にWindowsクライアント用のバイナリ生成に使われるコンパイル言語 |
| Perl | 広く使われていたが今は若干時代遅れのスプリクト言語。汚い |
| Python | Perlにかわって主流になりつつあるスクリプト言語。綺麗 |
| PHP | Web開発にフォーカスされたスクリプト言語。一世を風靡した。 |
| Ruby | とても綺麗なスクリプト言語 |
| JavaScript | ブラウザで実行出来る唯一の言語。言語自体はいまいちだが、ブラウザの事情で需要あり |
| Go | サーバサイドで安全かつ高速動作するバイナリ生成を目的としたコンパイル言語 |
メモリに直接アクセスして書き換えるといったコンピュータの機械語に近い言語構文を持つため、高速な処理が可能な言語。
コンパイラの歴史も古く環境も整っており、組み込み系などを含むほぼ全ての環境で利用可能な万能言語。
一方で、メモリの確保や解放といった基本的なことも自前で処理する必要があるため、コーディングの効率が良くなく、多種多様のバグを生みやすい側面も持つ。
ある程度以上のエンジニアであれば常識として知っておきたい言語だが、初めて覚える言語としてはあまり適当ではない。
C言語にオブジェクト指向を導入した言語。C++言語とはあまり呼ばれず、しーぷらすぷらす、もしくは略してしーぷらぷら、しーたすたす、などと呼ばれる。
C言語の速度を維持したままオブジェクト指向やテンプレートなどの効率的な記述を可能にしようとした意気は真っ当だったのだが、
当時最先端だった色々な技術や思想を叩き込んだおかげで、あり得ないほど複雑化した言語としても有名。
「C++を理解しています」という人はほぼ初級者で、本当に理解していくほど「C++には自信がありません」となっていく。
速度を追求する分野では良く使われている。完全に理解するのは難しいとしても、テンプレートくらいまでは理解しておくと仕事上なんとかなる…かもしれない。
サーバサイドで安全にコードを実行する目的でよく使われる言語。長い歴史を持っており、比較的高速に動作する。
当時は画期的だった「バーチャルマシン」や「ガベージコレクション」という機構を備え、CやC++でよく問題になるメモリの解放忘れというバグを生まず、
サーバサイドなどで何千時間と動作するソフトウェアに適した言語として受け入れられた。
必然的にエンタープライズ用途で利用されることが多く、各種ツールなども豊富。人海戦術がしやすい言語という側面も出てきた。
一方でブラウザにHello Worldを出すだけでも大変な労力を必要とするので、スタートアップなどではあまり使われない。
ガラケーのアプリや（ちょっと違うが）Androidなど、クライアントサイドでも使われることがある。
プログラミング言語で最初にJavaを覚えるという人は結構多いが、仕事としてJavaを使うのは大抵SI系の業務になり、なかなか辛い労働を強いられる可能性が高い。
クライアントサイドで安全にコードを実行する目的でよく使われる言語。こちらも比較的高速に動作する。
元々はWindowsのクライアント用の言語であり、Javaとは違ってクライアント向きのAPIが多数ある。
マイクロソフトが開発した言語ということもあり、マイクロソフトの優れた開発環境が利用出来るので開発効率は非常に高い。
Unityなどでも利用可能であるが、基本的にはクライアントの実行形式ファイルを生成する目的が大きく、サーバサイドではあまり使われない。
自作のゲーム開発をしたいのであればうってつけの言語。初めて覚える言語としても十分に良いだろうが、C#を使う仕事は近年無くなりつつある。
ほぼ全てのLinux系ディストリビューションに含まれており、ツールや様々な用途で使われていた。
上に紹介したC、C++、Java、C#のようなコンパイル言語とは違い、（少し語弊はあるが）1行ずつ実行してエラーがあれば止まるスクリプト言語である。
ちょっと開発してすぐに実行ということが出来るのと、コマンドラインでワンラインのコードを読み込ませてちょっとした処理が出来るなど応用範囲の広い言語である。
20年近く前にWebでCGIが普及した時には、ほぼどのようなサーバ環境でも実行可能だったこともあり、Perlを使うことが極めて多かった。
しかし、主に読みづらい言語仕様のせいで、近年新規ではほとんど使われなくなった。既存のコードもどんどん別の言語に置き換えられていることが多い。
日本の大手Web企業の一部が使っているので、そこに就職するために覚えるのもアリっちゃアリだけど、今からPerlをわざわざ覚えるのは強くオススメしない。
後発のスプリクト言語。こちらもほぼ全てのLinux系ディストリビューションに含まれており、それゆえに広く使われている。
インデントまで言語仕様で規定することで、誰が書いても読みやすいコードになるように考えられている言語である。
Perlの代わりに使われることが増えていて、周辺ツールなども充実しており、小規模から大規模までカバーする勢いがある。
ただ、Python2とPython3のバージョン間での非互換性があまり綺麗に設計されていなかったため、そこで混乱を招いていたこともあった。
最近だとマシンラーニング系のライブラリでPythonが使われていたり、海外ではPerlに代わる言語として受け入れられつつある。
Web開発に特化したスクリプト言語。CGIの代わりに使われ始め、一世を風靡した。
以前CGIでWebに何かを表示するには比較的大変な労力を割かなければいけなかったのが、PHPを使うと誰でも即座にWeb開発が出来たので爆発的に普及した。
またphp.netの豊富なドキュメント＆スニペットのおかげもあり、開発初期の効率が大変に良い言語である。
残念なことに、言語やAPIの設計がいけていない点が多く、一部の人からは蛇蝎の如く嫌われている。
今でも根強い人気があり、海外でも小規模プロジェクトの最初の開発にPHPを選ぶのは比較的よくある選択肢であるようだ。
Webアプリを開発をしたいという明確な目的を持つ人が、最初に学ぶ言語としてPHPを選ぶのは理にかなっていると思う。
なおこの言語を本気でディスってる人は大体視野の狭いエンジニアであることが多いので、地雷エンジニアを見分けるのにも役立つ。
綺麗なスクリプト言語。日本発で世界的に普及している数少ないIT技術の一つ。
言語仕様が美しく、それゆえにファンが多い。Ruby on RailsというWeb用フレームワークの登場で、Webアプリでの採用例も一気に増えている。
基本的には他のスクリプト言語と同じくサーバサイドでのプログラミングに用いられることがほとんどである。
スクリプト言語で何かを作成するのであれば、Rubyを選んでおけばそう失敗することはない万能言語。
サーバサイドで何かすることに興味を持っているならば、最初に覚える言語としてはとてもオススメ出来る。
一方で、なぜかRubyが採用するWeb側のフレームワーク（具体的にはprototype.jsやCoffeeScript）はいつもクソなので、そちらは深入りしないのが吉。
ブラウザで動くスプリクト言語。ブラウザ戦争が勃発していた18年前、奇跡のようなめぐり合わせでベンダー間の合意が取れ実装された言語。
言語としてはプロトタイプベースのオブジェクト指向という少しめずらしい形式を取っているが、実際にはあまりその特徴は利用されていない。
言語仕様がイマイチで、大変バグを生みやすい言語であり、また関数のスタックが深くなる特性もあり、あまり積極的に使うべき言語ではないが
ブラウザで動く言語が現在これしかないので、大きなシェアを持っている。
一部の物好きがサーバサイドでこの言語を使おうと（主にnode.jsで）四苦八苦している（とはいえ、1つの言語でWebとサーバが完結するのは大きなメリットだ）。
ブラウザで動く唯一の言語のくせにとにかく書くのが面倒ということもあり、多数のAltJSと呼ばれるJavaScriptに変換される別言語を生み出されている。
まあJavaScript本体人が手で書く言語ではない…というのがECMAScript5までの印象だったが、新しい規格が順次導入されており、今後に期待。
Web業界で生きていくならば、好むと好まざるとにかかわらず覚えなければいけない言語である。
最初に覚える言語としては、ブラウザ上でゲームなども作れるし、node.jsでサーバサイドもできるしで、意外とオススメだったりする。
C、C++やJavaと同じでコンパイル言語。サーバサイドで高速かつ安定なバイナリを出力することを目的とされ設計されたGoogle発の言語。
その目的においてはかなり高性能を誇るので、特に速度を要求されるサーバサイドでのプロジェクトでは導入が進んでいる。
それ以外の目的ではあまりこの言語を採用するメリットはないが、ニッチな用途をピンポイントで抑えており、これから広く利用されることも期待される。
コミュニティも活発であり、初めて言語を覚える人が参入すれば喜ばれるだろう。言語としても美しい言語なので、サーバ系のプログラムに興味があればオススメである。
繰り返しだけれど、それぞれの言語ごとに特徴があり、特徴のない言語は廃れていく。
ここに挙げた言語は何らかの特徴があり、何らかの用途で必要なので生き残っている。
その背景を知った上で、ここにある言語は全部ある程度読み書きが出来るようになると素晴らしいと思う。
ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。
今調べたらホッテントリメーカー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を学べばゴールというわけではありません。プログラム言語も次世代へと移りつつあります。業界動向には注視していきましょう。
付加価値の低い理由をぼやかしているから、なんか良く分からん文章になっている。
機能的に大したことが無いからという顧客視点なのかよくわからない。
技術者視点から言うと、枯れた技術であろうと最新の技術であろうと、
むしろ、新旧に関わりなく、基本を捉え、貪欲に吸収していくことが、技術向上の鉄則である。
メモリの概念を知らずにガベージコレクションを扱うことは、技術者としては好ましくない。
大規模なシステムになればなるほど、その影響は多大なものとなる。
トレンドのjsフレームワークを使って、レスポンシブルUIにするより、
少しボタンの位置を変えるだけで、利便性は向上する場合だってある。
むしろ、最新技術は色々な基本をすっ飛ばして機能だけ提供しているから、
似たようなことがあってさ
おれ、学校ではガーベジコレクションって習ったんだけど、ガベージコレクションという言い方もするらしいのさ
garbage collection ってどっちの読みが正しいんかね
