プログラムは「コード」とも言い、そのコードを記述することを「コーディング」と言う。

「プログラム」はリソースファイルや設定ファイル、画像といった「アプリケーションに必要なもの全部」を指す場合がある。そのため、「プログラミング」はそれらも含めた「アプリケーション全体を作成する」という行為を指すことになる。

逆に、「コード」はJava言語で記述された部分のみを指すことが多い。そのため、「コーディング」は「Java言語での記述のみを行う」という行為を指す。

イメージとしては、一心不乱にただコードを打ち込むこと、それが「コーディング」である。

また、そのようなことを行う者、またはそれを職業とする者を「コーダー」と呼ぶ。

ただし、実際には「プログラミング」と「コーディング」に大きな違いはない。

「プログラミング」をする際にコードしか打ち込まない場合もあれば、「コーディング」をする時に必要なファイルも作成することもある。

「コーディング」という言葉をポジティブに捉える場合、それは「自分は高い技術を持つのでコード打ち込み以外の雑事はやりたくありません」という意味になる。

「コーディング」という言葉をネガティブに捉える場合、それは「コードの打ち込みしかできないただの下働き」という意味になる。

もしこのふたつを明確に区別して使用する場合には、上記のような意味合いを含んでいると考えた方がいいだろう。

たとえば「System.out.println( 100 );」と書かれていた場合、この「100」がマジックナンバーである。

このようなリテラルは、プログラムを書いた者以外にとって「謎の数字」である。よく分からないが、とにかくちゃんと機能している重要な数字、という意味で「マジックナンバー」と呼ばれる。

マジックナンバーは極力避けた方がよい。

前述したように、マジックナンバーは一見、その数字がどういう意味を持つのかわかりにくい。そのため、記述者以外がプログラムを修正するのが難しくなる。

また、同じマジックナンバーがプログラム中に含まれている際に、同じ意味の値なのか分からないという問題がある。「System.out.println( 100 );」という行がある場合、前述の「100」とこの「100」が同じ意味の「100」か分からず、一方を変更した際にもう一方も変更すべきかわかりにくい。

以上の問題から、マジックナンバーを書いてはならない。

できる限りstatic finalフィールドを用いることが望ましい。詳しくは「static final」の項目を参照。

「ハードコーディング」もほぼ同じ意味。

「マジックナンバー」を書く「行為」が「ハードコーディング」と言える。

インスタンスの内部に格納されたデータも含めて文字列化し、Stringクラスの戻り値として返すメソッド。

引数なし、戻り値の型はStringクラス。

この戻り値の文字列にはインスタンスの「概要」が書かれていることになり、インスタンスについて簡単に情報を得ることができる、便利なメソッドである。

toString()メソッドは多くの場面で呼び出される。

たとえば、println()メソッドは渡されたインスタンスのtoString()メソッドを呼び出し、返された文字列を出力する。

また、Eclipse等の開発環境でデバッグ時に変数を見ようとすると、その変数がクラスの参照型変数の場合にはtoString()メソッドが呼び出され、返された文字列がウィンドウに表示される。

toString()メソッドのおかげでインスタンス内の状態を簡単に知ることができ、デバッグ時には非常に役立つメソッドである。

toString()メソッドはObjectクラスのメソッドである。すべてのクラスはObjectクラスのサブクラスだから、すべてのクラスがtoString()メソッドを持つことになる。

ただし、ObjectクラスのtoString()メソッドは、「クラス名@ハッシュ値」というあまり役に立たない情報しか返さない。

J2SEの多くのクラスは、ObjectクラスのtoString()メソッドをオーバーライドし、内部情報を出力する。

自分で作成したクラスに「toString()メソッドで内部情報を出力する」機能を持たせる場合、ObjectクラスのtoString()メソッドをオーバーライドし、フィールド等の「インスタンスの情報」を文字列化し、戻り値として返せばよい。

その際、返す文字列の書式は決まっていない。自由に決めてよい。

それは逆に言えば、返される文字列の書式がバージョンアップ等で変更される可能性が高いということである。書式が決まってない以上、たとえば「toString()メソッドの戻り値をパースして、見ることができないフィールドの情報を取得する」といった使い方は避けた方がいい。

toString()メソッドの戻り値はあくまで人間が目視で確認するためのものである。IntegerクラスのtoString()メソッドのような「出力書式が仕様で決められている」ものは別として、通常はデバッグ時の参考くらいにとどめておいた方がいいだろう。

Comparableインターフェイスのメソッドを実装したもの。

Integerクラス等のラッパークラスや、Stringクラス等が実装している。

compareTo()メソッドは「A.compareTo( B )」の形式で使用する。

この戻り値は、「A」が「B」より小さいとマイナス、一致は0、それ以外はプラスとなる。

これは「A - B」の結果と一致する。

一般に比較を行うためのメソッドとして使用する。

また、Arraysクラスのsort()メソッド等、比較を行う場合には、compareTo()メソッドの実装が必要となる場合がある。

その場合、まずComparableインターフェイスを実装し、そのcompareTo()メソッドを実装する。その戻り値は、比較結果としてマイナス、0、プラスのいずれかを返す。

この時、compareTo()メソッドの中では、上記の例で言えば「this」が「A」に、「第1引数」が「B」に該当する。

そのため、「this」が「第1引数」より小さいとマイナス、一致は0、それ以外はプラスを戻り値として返すように実装しなければならない。

これは前述のように「this - 第1引数」と同じである。また、比較対象にcompareTo()メソッドを使用できるのであればその結果を返してもよい。それ以外であれば、ifやswitchを使用して比較を行えばよい。

他のクラスや変数をフィールドとして持ち、隠蔽し管理し操作するためのクラスを「ラッパークラス」「ラップクラス」と呼ぶ。

言語仕様的な決まりはなく、明確な定義もない。

通常ラッパークラスは、クラスもしくは変数ひとつを「包み込む対象」として選び、それをフィールドとして持つ。そのフィールドへは直接外からアクセスできないようにし、間接的にアクセスするためのメソッドを用意する。そのメソッドは「包み込む対象」を安全かつ十分に使用できるものを用意する。

このような条件に当てはまるクラスを一般的にそう呼ぶ、ということである。

ラッパークラスとする目的は様々である。

目的のひとつに、隠す対象のクラスが使いにくいため、使いやすいメソッドを提供するため、というものがある。引数が複雑だったり、複数のメソッドを順番に呼ぶ必要があったりする場合に、これらを使用せず簡易な方法を用意する目的で、包み込みメソッドを用意するわけである。

また、隠す対象が直接操作されるのを避けるためだったり、隠す対象が持つ機能とは別の形での機能を提供するためだったり、といったことがラッパークラスを作る目的となる。

いずれも、「使う側」と「隠す対象」の間に「ラッパークラスのメソッド」を挟んでいる。このメソッドを仲介役とすることで、「隠す対象」への直接のアクセスを避けつつ、付加価値を加えている。

ラッパークラスの具体例のひとつに、int型に対するIntegerクラスが挙げられる。

Integerクラスはint型のラッパークラスとして機能し、int型が持たない「クラスとしての機能」を提供する。APIリファレンスには「The Integer class wraps a value of the primitive type int in an object.」と書かれており、この「wraps」が「覆い隠す」という意味になる。

プリミティブ型は、全ての型に対応するラッパークラスが存在する。

プリミティブ型に対応するラッパークラスは、以下の通り。

・byte → Byte

・short → Short

・int → Integer

・long → Long

・float → Float

・double → Double

・char → Character

・boolean → Boolean

これらのラッパークラスは「インスタンスは不変」なため、インスタンス内の値を変更することはできない。

この機能によって、ラッパークラスはよりプリミティブ型に近い扱いが可能となっている。

詳しくは「インスタンスは不変」の項目を参照。

また、オートボクシングによってプリミティブ型との変換が簡単にできるようになっている。詳しくは「ボクシング変換」「アンボクシング変換」の項目を参照。

これらはプリミティブ型にはない便利なメソッドを持ち、かつプリミティブ型が持たない「参照」を用いた処理を行うことができる。

特にこれはArrayListクラス等のコレクションを使用する場合に必要となる。コレクションクラスの要素はObjectクラスとなっているため、プリミティブ型を格納することができない。また、ジェネリッククラスやジェネリックメソッドの型パラメーター（「」のこと）にもプリミティブ型を使用することができない。

そのため、コレクションの要素にプリミティブ型を使用したい場合には、その代わりに対応するラッパークラスを使用することになる。

また、ラッパークラスを使用することでプリミティブ型にはない「null」という状態を持つことができる。それにより、数値の入力を受け取る際に「入力なし」という状態を「null」で表現することができる。

「ラッパー」と言っても「Yo!」とか言う人達とは関係ないので注意。

意味的には「クレラップ」「サランラップ」の方が近い。

J2SEに含まれるクラスのひとつ。パッケージも含めたクラス名はjava.lang.System。

「実行中のアプリケーションに関する処理」を行うためのクラス。つまり「アプリ自分自身」を示すクラスである。

世界一有名なフィールド、outフィールド（System.outフィールド）を持つ。

また、「実行中のアプリケーションに関する処理」を行うための様々なstaticメソッドを備えている。

Systemクラスはインスタンスを作ることができない。

コンストラクタがprivateメソッドのため「new System()」ができない。これはSystemクラスが「アプリ自分自身」を示すため、インスタンスが複数あってはならないためである。

その代わり、フィールドとメソッドはすべてstaticとなっている。

日時を格納するためのクラス。

ただし、現在は使用が「推奨されていません」。

日時を格納するためのクラスとして代わりにCalendarクラスの使用が推奨されている。

DateクラスからCalendarクラスへ変換する場合には、CalendarクラスのsetTime()メソッドにDateクラスの参照を渡せばよい。

逆に、CalendarクラスからDateクラスに変換する場合には、CalendarクラスのgetTime()メソッドを呼び出せばよい。このメソッドの戻り値がDateクラスとなっている。

このように相互変換が可能なため、基本的にはCalendarクラスを使用し、必要なときだけDateクラスに変換するのがよいだろう。

同名のクラスにjava.sql.Dateクラスがある。

SQLのDATE型に対応するのはjava.sql.Dateクラスである。しばしばの混乱の元となるため注意すること。

世界標準時の「1970/01/01 00:00:00.000」である。

多くのコンピューターは、内部時計による時間を、世界標準時の「1970/01/01 00:00:00.000」からの経過ミリ秒で管理する。

この、経過時間を数える「開始時点」となる「1970/01/01 00:00:00.000」を「エポック」と呼ぶ。

現在日時等、日時の管理は多くの場合このエポックからの「のべミリ秒」で行う。

エポックからのミリ秒で日時を管理することで、秒から分への繰り上がり等を気にする必要がなくなり、整数値ひとつで管理することができる。

また、日時の表現は時代、宗教、文化によって異なるため、ミリ秒で管理することでそれらの差を吸収することができる。

そのため、古くから慣例的に、コンピューターでの時間管理はエポックからのミリ秒で行われてきた。

エポックからのミリ秒は、SystemクラスのcurrentTimeMillis()メソッドで取得できる。

また、CalendarクラスのgetTimeInMillis()メソッドや、DateクラスのgetTime()メソッドでも取得できる。

これらのメソッドで取得するミリ秒は、long型で返される。int型ではない理由は、ミリ秒という細かい数え方のため、int型の最大値を超えてしまうからである。

エポックからのミリ秒で日時を取得すると、日時の大小比較や、差の計算や増減、日時を扱うクラス間の変換を行うことができる。ただ、通常はCalendarクラスを用いれば問題ないだろう。

「エポック」とは「時代」という意味である。

つまり「1970/01/01 00:00:00.000」時点以降が「コンピューターの時代」となるわけである。

日時を格納するためのクラス。日時を格納し、基本的な処理がひととおり行えるメソッドを持つ。

コンストラクタはprotectedのため直接呼び出すことはできない。getInstance()メソッドがstaticメソッドとして用意されており、このメソッドを呼ぶことでCalendarクラスのインスタンスを作成できる。また、このインスタンスには現在日時が格納されている。

ただし、正確に言うと「Calendarクラスのインスタンス」ではなく「Calendarクラスのサブクラスのインスタンス」である。詳しくは「GregorianCalendar」の項目を参照。

特定日時のセットにはset()メソッドを使用する。あらかじめclear()メソッドを呼び出しておくとエポックつまり「1970/01/01 00:00:00.000」にリセットしてくれるため、その後に希望の日時をセットするといいだろう。

年、月、日等を個別に取得する場合にはget()メソッドを使用する。

いずれも、項目を指定する場合には「Calendar.YEAR」等のstatic finalなフィールドを用いる。

また、月は-1された値となることに注意。これはプログラミングにおける慣習のようなもので、1月が0、12月が11となる。月を指定する際は、「Calendar.JANUARY」等のstatic finalなフィールドが用意されているためこれらの使用を勧める。

Calendarクラスの日時は「年、月、日、時、分、秒、ミリ秒」と7つの整数値によって表現されている。そして、これらは相関関係を持つ。「秒」が59の場合に1を加えれば、0になると同時に「分」に1が加わる。また、日時の比較を行う場合、この7つすべての比較を行わなければならない。

こういった「日時の処理」は非常にバグを生みやすいため、add()メソッドやbefore()メソッド、after()メソッドの使用を強く勧める。

add()メソッドは「年、月、日、時、分、秒、ミリ秒」のいずれかを任意の量だけ増減できる。繰り上がり及び繰り下がりを計算してくれるため大変便利である。

before()メソッドおよびafter()メソッドは、他の「Calendarクラスのインスタンス」との比較を行う。「A.before( B )」は「A < B」、「A.after( B )」は「A > B」という比較を行う。

また大小の比較を行う場合にはcompareTo()メソッドを使用する。こちらは「compareTo」の項目を参照。

内部的には「1970/01/01 00:00:00.000」つまり「エポック」からのミリ秒という形式で日時を格納している。詳しくは「エポック」の項目を参照。

エポックからのミリ秒はgetTimeInMillis()メソッドで取得できる。

出力にはSimpleDateFormatクラスが向いているのでこのクラスを使用した方がよいだろう。

詳しくは「SimpleDateFormat」の項目を参照。

同じく日時を格納するクラスとしてDateクラスが存在するが、Dateクラスは現在「推奨されていない」ため、Calendarクラスを使用する方がよい。

Dateクラスとの相互変換の方法は「Date」の項目を参照。

ちなみに「Calender」ではなく「Calendar」なので注意。

&&演算子と||演算子は、左オペランドを先に評価する。

その際左オペランドが、&&演算子はfalse、||演算子はtrueの場合には、右オペランドを評価しない。

つまり「右オペランドの評価を省略する」ため、これを「ショートサーキット」「短絡評価」と言う。また&&演算子と||演算子を「ショートサーキット演算子」「短絡演算子」とも言う。

&&演算子の場合、左オペランドを評価した結果がfalseの場合に右オペランドを評価しない。

これは、右オペランドの結果に関わらず結果はfalseとなり、右オペランドの評価が「必要ない」ためである。

||演算子の場合、左オペランドを評価した結果がtrueの場合に右オペランドを評価しない。

これは、右オペランドの結果に関わらず結果はtrueとなり、右オペランドの評価が「必要ない」ためである。

右オペランドで何らかの処理を行っている場合、その処理そのものが行われない。

ショートサーキットを使用することでプログラムを簡略化することができる場合がある。

ただし、この2つの演算子がショートサーキットを行うことを知らない場合、処理されるはずなのに処理されない、といったバグを生む可能性ががあるため注意すること。