OSに依存する。
Windowsでは区別されないが、大抵のUnix系OSでは区別される。
MySQL :: MySQL 5.1 リファレンスマニュアル :: 8.2.2 識別子の大文字/小文字区別
MySQL において、データベースはデータディレクトリ内のディレクトリに対応しています。データベース内の各テーブルも、データベースディレクトリ内の少なくとも１つ（記憶エンジンによってはそれ以上）のファイルに対応しています。そのため、ベースとなっているオペレーティングシステムで大文字と小文字が区別される場合、データベース名とテーブル名でも大文字と小文字が区別されます。つまり、Windows ではデータベース名とテーブル名で大文字と小文字は区別されず、ほとんどの種類の Unix では大文字と小文字が区別されることになります。
一般的な慣習とは異なるので分かりにくい。。
PostgreSQLのメジャーバージョンは、例えば8.4のようにバージョン番号の最初の二つの数字の組で表されます。 PostgreSQLのマイナーバージョンは、バージョン番号の3番目の数字の組で表されます。例えば8.4.2は8.4の2番目のマイナーリリースです。 マイナーリリースでは内部データ保存形式は決して変更されず、同じメジャーバージョン番号の以前と以降のマイナーリリースと常に互換性があります。例えば8.4.2は8.4、8.4.1、8.4.6と互換性があります。 互換性のあるバージョン間での更新は、サーバが停止している間に実行ファイルを置き換えサーバを再起動するだけです。 データディレクトリはそのままです。マイナーアップグレードはそのように簡単です。
PostgreSQLのメジャーリリースでは、内部データ保存形式は変更されることがあります。そのため、アップグレードは複雑になります。 新しいメジャーバージョンへデータを移行する伝統的な方法はダンプしてリロードすることです。 他に、以下に記すように、それほどテストされていませんが実行可能な方法があります。
新しいメジャーバージョンは概してユーザから見える非互換性を導入します。そのためアプリケーションプログラムの変更が要求されます。 注意深いユーザは、完全に切り替える前に自分のクライアントアプリケーションを新しいバージョン上でテストしたいでしょう。そのため、旧バージョンと新バージョンのインストールを同時に設定するのは良い考えであることが多いです。 PostgreSQLのメジャーアップグレードをテストするとき、以下に考えられる変更の範疇を検討してください。
らしい。
要するに定数の値を変更しても、それを参照してる側も再コンパイルしないと値が反映されない。
共通ライブラリに定数を定義し、他のプログラムで参照している場合などがヤバイ。
finalなフィールド変数は、値を変更しても、その値を参照している既存バイナリは再コンパイルしない限り新しい値が適用されない。private staticな変数のgetterのみ宣言する方が良い。static finalなフィールドはデフォルト初期値を持つように宣言してはならない。必ず定数式で初期化する。
static final int a;static final int a = 0;ブランクfinalはインライン展開されない模様。
言語仕様では明確な記述は発見できなかった。
バグ？
Checkstyle4.3.2で確認。
Checkstyle設定画面にてOther＞TreeWalker＞tabWidthを4にする。
SizeViolations＞MaximumLineLength＞tabWidthはバグにより4文字指定不可
設定ファイルをテキストエディタで開き、TreeWalkerモジュールか、LineLengthモジュールに以下のプロパティを設定する。
TreeWalkerモジュールに設定した場合は解決策1と同様の設定になる。