why File#lastModified() returns zero ?

because  it's mistake  "p->p.getFileName().toFile().lastModified() ".

The correct Answer is "p->p.toAbsolutePath().toFile().lastModified()".

o......rz

lastModified() returns 0 means I/O Error occured  ってstackoverflowとかで見たのに、

ファイルシステムキャッシュか？とか仮想マシンのキャッシュか？とか迷走した結果、

このバグ発見に2日かかりました。

getFileName()だと文字どおりファイル名しか帰ってこないので、Servlet実行時のカレント相対で探しに行くから

そりゃファイルあるわけないんだよ。(´・ω・｀)

自戒を込めて備忘録しとこ。

IBMJREでの7.0と7R1（いわゆる7.1）の区別について

なんでこんなめんどくさい表記なのかわからないけど、普通にjava -version ってやっても７．１とはでてくれない。

7.0か7.1かを判別するにはJ9のバージョンを確認する。

7.0であればbuild 2.6

7.1であればbuild 2.7

(´・ω・｀)こんなん役に立つかどうかわからんけど、

fix適用時とかにバージョンワカンネってなったときはどうぞ。

https://www.ibm.com/support/knowledgecenter/ja/SSYKE2_7.1.0/com.ibm.java.win.71.doc/user/java_jvm.html

他のバージョンはちゃんと1.5とか1.8とか出るので、気にしなくていいんですが。

system uptime の取得方法（JVMのuptimeではない）

/proc/uptime を読むとか、PurocessBuilderでuptime叩くとかではなく、

nanotimeの計算式を逆手にとった方法があるみたい。

当然OSに依存すると思うので、テストしてから使用を推奨。

System.out.println("System.nanoTime " + System.nanoTime() / 1e9);

どういう状況で必要になるかはわからんけど。(´・ω・｀)

How to get UNIX uptime in Java?

https://stackoverflow.com/questions/8209096/how-to-get-unix-uptime-in-java

文字列の結合の細かい話

ご存知のように、Javaで文字列を結合する時には　”＋”演算子でできる。

こんな風に書ける、ということね。

        String s3=s1+s2;

これはコンパイル時に、StringBuilder.appendに書き換えられるわけなんだが、

こんな風に。

   4:    astore_2
   5:    new    #3; //class java/lang/StringBuilder
   8:    dup
   9:    invokespecial    #4; //Method java/lang/StringBuilder."<init>":()V
   12:    aload_1
   13:    invokevirtual    #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   16:    aload_2
   17:    invokevirtual    #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   20:    invokevirtual    #6; //Method java/lang/StringBuilder.toString:()Ljava/lang/String;
   23:    astore_3

これはJDK1.5以上での話で、もーっと化石なバージョンだと、これは

StringBuffer.appendになる。

StringBufferはMTセーフであるが、Builderはセーフじゃない。

まぁ、こんなテンポラリな短命オブジェクトがMTセーフである必要はないやな。

Aixでのjava.util.prefs.Preferences

Preferencesの使い方などはいろいろな記事があるので割愛するとして、
保存先はどこなんだYO!ってところだけ備忘録。
Aixで使う状況と需要があるのかよくわからないですが( ´∀｀)

１．systemNodeForPackage　
/usr/java7/jre/.systemPrefs　以下
バイナリの場所に…(；´Д｀)ファイルセットアップデートとか注意やぞ。
また、複数のJREが入っている場合は実行したJREでしか効かない。

２．userNodeForPackage
これはlinuxとかと同じ
$HOME/.java/.userPrefs 以下

つまり、複数のJREで実行された場合、同じユーザーであれば、userNodeは引き継げるが
systemNodeは独立しているんだよ！　

ΩΩΩ＜ﾅﾝﾀﾞｯﾃｰ！

/etc/.java に入るlinuxとは違うみたいやね。

ThreadPool JDK5

メモしとこ。

JDK5から使えるスレッドプールの実装。

スレッド管理のわずらわしさから開放される。

以下のサンプルはMachineクラスがたまにアホになり無限ループする。

たぶんjextractとjdmpviewの勉強用に作ったサンプルだったと思う。

import java.util.*;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;

public class test
{
    public static void main(String[] argv)
    {
        ExecutorService threadPool = Executors.newFixedThreadPool(5);
        
        Collection<Callable<Void>> processes = new LinkedList<Callable<Void>>();
        for(int i=0 ; i < 5; i++)
        {
            final Machine m = new Machine(i);
                processes.add(new Callable<Void>() {
                    @Override
                    public Void call() {
                        m.exec();
                        return null;
                    }
                });
        }
        
        try {
            threadPool.invokeAll(processes);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        } finally {
            threadPool.shutdown();
        }
    }
}

続きを読む

[java]多重ループからの脱出

大昔のJDKでもできたっぽい。(;´Д｀･･･

いままで多重ﾙｰﾌﾟの内側から一気に脱出しなければならないようなロジックを書く必要が無いぐらい
ちゃんとオブジェクト指向して書いていたからだ！！！！　

とでも思って慰めておくことにする。
Gotoみたいなもんじゃん・・。例外エラーロジックだとtry〜catchでいいやん。

書き方は分岐先頭or末尾にラベルを書く。（for、while、ifなどなど）

HOGE: for(int i = 0; i< max; i++)
{

}

とか

if(hoge > 0) {　HAGA:

}
とか。

脱出には　

break HOGE;

とか

continue HAGA;

とか書く。

まぁ、知らなくてもおｋ。
３つも４つもループするなら普通はprivateメソッドになるやろ。(　´Д｀)

[java]Dolphin!(4)

どこまで書いたかな・・。

//(3)String Switch
String str1="abcde";
switch(str1)
{
    case "hoge":break;
    case "huga":break;
    case "abcde":System.out.println(str1);break;
}

ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
もうこれでしょーもない　private static final int　とか　Enumを作らなくてよいし、
ソース分析時に、このswitchの数字の意味はなんなんだ・・・、43だけスルーとかなんなんだ・・・。
コメントねーし、ぐぬぬぬぬ(`皿´;)とかも解決！

よし、まぁ待て。落ち着け。
内部ではEnumに自動変換してそうな予感がしてしょうがない。

でゅわ、jdの出番だ。

String str = "abcde";

Object localObject1 = str; 
int k = -1; 
switch (((String)localObject1).hashCode()) 
{ 
    case 3208229:
      if (((String)localObject1).equals("hoge")) k = 0; break;
    case 3213991:
      if (((String)localObject1).equals("huga")) k = 1; break;
    case 92599395:
      if (((String)localObject1).equals("abcde")) k = 2; break; 
} 

switch (k) {
    case 0:
      break;
    case 1:
      break;
    case 2:
      System.out.println(str);
}

文字列ハッシュでswitchかーって感想だけだと、味気ないので、もうちょっと|дﾟ)ｶﾝｻﾂ

if(localObject1.equals("hoge")){
}else if(localObject1.equals("hoge")){
}else if(localObject1.equals("abcde")){
}
でも良さそうな気がせんでもないし、実際昔はこう書くしかなかった。
でも、先にハッシュだけ比較するほうが計算コストが低くなるので
こういう実装なんだと思う。コンパイル時に対象のハッシュも確定できるし。

つまり、String#equals() の実装見てくれればわかるんだが
比較は大きくわけて５ステップある。

（１）自分自身か？
（２）文字列のインスタンス？
（３）文字数一致？
（４）ハッシュ一致？
（５）文字列のコンペア

（４）の処理は初回のみ実行時計算＠インスタンスなので、
JDK7の実装だとハッシュ一致時のみしかラベル文字のハッシュ計算は走らないが、
旧の実装だと必ず走ってしまう。また、（２）の処理は意外にコストが要る計算である。
文字列以外が来る可能性が�_でもあるなら、しょうがないけど。

ということで涙ぐましいコスト最適化がかかっているために、こういった表記なんだと思うんだね。

[java]Dolphin!(3)

新しいコードスタイル（３）

これも細かいなぁ。(´-ω-`)

　　//(3)ダイヤモンド演算子
　　List list = new ArrayList<>();

Genericsの面倒なあの表記を宣言時は省略できます。
当たり前だよね、宣言してんだから、その型に決まってるわけで。

[java]仮想マシンの制限値

メソッド１クラス６５５３５！
フィールド１クラス６５５３５！
インターフェース６５５３５！
メソッドサイズ６４ＫＢ！

王将のＣＭのノリで覚えら・・・れるわけないわな。
まぁ、こんな制限に引っかかるClassがあるわけないのでしらんでも困らないがね。
もっと詳しく知りたい貴方は仮想マシン仕様の「4.10 java仮想マシンの制限」のところ参照。

[java]Dolphin!(2)

新しいコードスタイルその２。
その１も大した変更じゃなかったが、その２も大したものじゃない。
でも、便利。

(2)バイナリアン大歓喜

　　　int a2 = 0b00000111;

２進数表記ができます。
これで、ビット操作も直感的に書けます。

ビット操作要る局面が業務アプリであるかどうかは別として
ゲームとかだと結構使うと思うけど。

[java]Dolphin!(1)

まぁJDK7のコードネームなんだけどな。
5がtiger、6がMustang。虎、野生馬、ときてイルカ。( ′∇ｿ ﾖｰﾜｶﾗﾝ　このｾﾝｽ。

project Coin　、ﾌﾟﾛｼﾞｪｸﾄ小銭でコードの規約が若干変わってズボラ仕様が追加された。
なかなかいい感じのもあるしビミョーなのもあるけど、概ね好感触。
Javaが流行りだしたころに鳴り物入りで作ったシステムもそろそろライフサイクルを終えはじめ、
システム刷新や更新を考え出す企業さんとかもそこそこあるんではなかろうか。
まぁ、参考になればいいかなって程度で何回かに分けて紹介します。
小出しにして記事数稼ぐともいう。

（１）数値リテラルにアンダースコアが使えるようになった！
　　　これで桁数数えるのも楽だね！　(*´д`;）

　　　　　　　　int a1 = 1234_5678_9;

　　　もちろん浮動小数でもおｋなので、

　　　　　　　　float f1 = 1.23_45E5f;
　　　　　　　　double d1 = 0x1234_567P-2;

　　　こんなんでもよい。
　　　またいくつ重ねてもいいので、極端な話

　　　　　　　　int inoki = 0x1_____2______3______daaaa;

　　　ボンバイエも可能。業務コードで書いたらしばかれるから注意な。
　　　マジックナンバーとして使えなくもないが、まぁやめとくがよいでしょ。

[Java]keepalive

java でHTTPアクセスをするとき、まさかsocketから書くようなﾒﾝﾄﾞｲことはしまい。
HttpURLConnectionなり、HttpClientなりを使うと思う。
（Rawソケットを触りたいなら、すでに言語選定が間違っているしね）

このHTTPURLConnectionは結局はHTTPClientを内部で呼ぶんだけど
こいつにはkeepaliveがかかる。

制御するパラメータは以下のシステムプロパティ
---------------------------------------------

キープアライブの動作を制御するシステムプロパティーは次のとおりです。

http.keepAlive=
デフォルト: true

キープアライブ (持続) 接続をサポートすべきかどうかを示します。

http.maxConnections=
デフォルト: 5

任意の時点で接続先ごとにキープアライブを実行できる最大接続数を示します。

http://docs.oracle.com/javase/jp/6/technotes/guides/net/http-keepalive.html
---------------------------------------------
grepcode （http://grepcode.com/)からHTTP処理時の流れを追いかけてみると
URLスキーマから、処理すべきクラスを決定して適切なクラスをリフレクションしているようだ。
コード読んでいて気がついたんだけど
keepaliveの破棄はリアルタイムではなく、5秒固定のポーリングを行い、
その時点でタイムアウトしていれば破棄する、という処理だった。
よって、サーバー側から5秒以下のkeepalive要求が来たとしても
java側は最低５秒まではsocketを維持している。
（維持しているだけで使用はできないのでご安心を）

著作権的に該当箇所を引用していいかわからない（sunパッケージ内だから）ので
気になる人は上のサイトから自分で確認してくだしあ。

openJDKは原則GPLだけど一部例外アリとかそんなんだった気がするんだよな。
OSSはこういうライセンスがフリーなようでフリーじゃないような罠が結構あるんだよなぁ。

[java][python] singpath

これはなかなかクイズというか、初級学習の確認によいかもしれん。

singpath
https://itunes.apple.com/app/singpath-mobile/id567470737

英語なのがネックだけど。

java-DeCompiler

javaの逆コンパイラと言えば標準のjavapとかjadが有名ですが、
ジェネリックスとかがあるとうまく整形されないとか手に入りにくいとかいろいろあるですな。

http://java.decompiler.free.fr/?q=jdgui

このサイトから入手できる　jd-gui.exe　がなかなかGoodでして
jarファイルをそのまま逆コンパイルできるわ、階層的に辿れるわ
丸ごとjavaファイルを作れるわ、などといままでシェルとかでチマチマやってたのが
馬鹿らしくなるです。
おまけにジェネリックスとか列挙型もちゃんと理解するし、いい感じですよ。

※classやjarファイルを解析することははリバースエンジニアリングに相当するため、
　製品などのjarやclassの場合は禁止する旨がライセンスに記載されていることもあるので
　取り扱いは慎重に実施ください。
　何かあっても当方は一切関知しませんし責任も負いませんよ。

[java]sun.reflect.GeneratedSerializationConstructorAccessor の正体

sun.reflect.Generatedほげほげ　などの解説

-これは何？

　reflectionを行うときの　ByteCode　Accessor

-は？

　アクセッサーには2種類あり、JNI　AccessorとByteCode　Accessor
　ご存知のようにJNI操作はコストが高いので、頻繁に呼び出されるとJNIからByteCodeへ昇格される
　そうすることで、reflectの動作を高速化させている。
　これが導入されたのはJRE1.4x以降

-このクラスをロードしたとか消したとかでまくるんだが、ぉぃい

reflectAPIの呼び出し単位で作成されてしまうので、フレームワークなんかを
使っているともう吐き気するぐらい作成される。
ClassオブジェクトなのでJVMのﾊﾞｰｼﾞｮﾝによってはHeapの中では厄介ものである
（フラグメント要因になる）。
だが安心してほしい。弱参照状態で作成され、参照は親のClassLoaderだけなので、
「使用中」でなければ破棄できる。
破棄されたものは、再びJNI　Accessorからの出直しになる。

-それって、パフォーマンス元に戻るんじゃね？意味なくない？

パレートの法則。８０：２０の法則。

　GC対象になるようなAccessor　＝　未使用　＝２０％部分じゃない　＝パフォーマンスに影響を与えない

　パフォーマンスチューニングにおける大前提である。

-制御したいんだが

　　-D sun.reflect.noInflation = false （default value is　false)
　　-D sun.reflect.inflationThreshold = 15 (default value is 15)

　　noInfration　=true　は進化をやめよ、となり、デフォルトでbyteCodeAccessorが作成される
　　よって、マッハになるかもしれないがsun.reflect.Generatedほげほげの数は増える

　　inflationThreshold は進化までの回数。デフォルトでは１５回呼ばれるとHot判定になりbyteCodeAccessorが作成される

　　普通はこんなコアな設定はさわらんでよろしい。
　　その前に直すべき箇所があるはずである。

参考リンク
https://www.ibm.com/developerworks/mydeveloperworks/blogs/738b7897-cd38-4f24-9f05-48dd69116837/entry/reflection_a_memory_viewpoint3?lang=ja
http://anshuiitk.blogspot.com/2010/11/excessive-full-garbage-collection.html
http://stackoverflow.com/questions/2971019/how-to-avoid-generatedserializationconstructoraccessor-problems

[java]備忘録2012 JDK1.4.2の（以下略

ダークマターによるGCの誘発について
http://www-01.ibm.com/support/docview.wss?uid=swg21214654

IBMJDKにおけるIC（Incremental　Compaction）について
http://www.ibm.com/developerworks/ibm/library/i-incrcomp/

IBMJDKが巨大オブジェクトをどのように扱うのか（LOAの説明）
http://www-01.ibm.com/support/docview.wss?uid=swg21236509

その他GCの動きの説明
http://www.nminoru.jp/~nminoru/java/cms/concurrent_mark_sweep.html#45


ヒープ圧縮（shrink）について
http://www-01.ibm.com/support/docview.wss?uid=jpn1J1004853

IBMJDK1.4.2におけるComapction発生要因
http://publib.boulder.ibm.com/infocenter/javasdk/v1r4m2/topic/com.ibm.java.doc.diagnostics.142/html/id1156.html?path=0_5_7_2_5#id1156

※Reason8　transient　heap云々Compactionは　ｚOSのみでAIX/Linux/Win　では発生
しない

[Java]備忘録2012 JDK1.4.2のこまごま

kCluster と　pCluster の説明
http://www.ibm.com/developerworks/jp/lotus/library/dm-0802tessarek/index.html#AS_4
http://publib.boulder.ibm.com/infocenter/javasdk/v1r4m2/index.jsp?topic=%2Fcom.ibm.java.doc.diagnostics.142%2Fhtml%2Fpinnedclusters.html
http://www.atmarkit.co.jp/fjava/rensai4/websphere03/websphere03_4.html
http://www-01.ibm.com/support/docview.wss?uid=swg21196072

JDK1.5からはこのkCluster枯渇によるヒープフラグメンテーションは発生しない。

巨大なメモリ要求を確認するには、ALLOCATION_THRESHOLD変数を設定する
（1.3.1SR10?、1.4.2SR4?）
1.5、1.6は別の変数（-Xdumpの設定で行う）
設定すると、少し負荷が上がる。

http://www-01.ibm.com/support/docview.wss?uid=swg21236523

[Java]-jar オプション

-jar　オプションて便利じゃないですか、いちいちクラス名とかも
書かなくていいし、パッケージについても説明しなくていいし。

でもね、罠がありましてな。（今回これに気付くまでだいぶかかった(;´Д｀)）

CLASSPATHが効かない。

-cpとかが無効になる。
ｱｯﾊｯﾊ。

一応マニフェストファイルのClass-Path:　エントリに書くことで回避はできるのだが、
そのjarファイルからの相対パスでかかなくてはならず、実行環境に依存してしまう。

いけてねーなぁ･･･。

http://java.sun.com/javase/ja/6/docs/ja/technotes/tools/windows/java.html#-jar

このオプションを使用すると、指定した JAR ファイルがすべてのユーザークラスのソースになり、ユーザークラスパスのほかの設定は無視されます。

[java]Excella -Core Tips(2)

@Objects 方式でパースする時に
プロパティのタグを打つとおもうわけよ。

サンプルのページでいうところのworkStartHour やworkContentsね。

これを「頭大文字で長め（８文字ぐらい）」にするとなぜかparse結果がnull。

こんなんわからんｗこれも一個前のと同じくバグくさいが。
java beansの規約とかだったかなぁ。

setter/getterの名前は頭大文字でもOK（Eclipseとかだと自動で付くと思う）

まとめる。


・プロパティ名がABCDefgh とかは危険
・プロパティ名abcdefgなら、setter/getterは　setAbcdefg()/getAbcdefg()

としておくと無難。Eclipseを怒らせ泣けばおｋということだな。

これも半日なやんだんだぜ。