2017年12月01日

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実行時のカレント相対で探しに行くから
そりゃファイルあるわけないんだよ。(´・ω・`)

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



posted by koteitan at 10:55| Comment(0) | Java | このブログの読者になる | 更新情報をチェックする

2017年09月19日

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

なんでこんなめんどくさい表記なのかわからないけど、普通にjava -version ってやっても7.1とはでてくれない。
7.0か7.1かを判別するにはJ9のバージョンを確認する。

7.0であればbuild 2.6
7.1であればbuild 2.7

(´・ω・`)こんなん役に立つかどうかわからんけど、
fix適用時とかにバージョンワカンネってなったときはどうぞ。


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

posted by koteitan at 14:39| Comment(0) | Java | このブログの読者になる | 更新情報をチェックする

2017年08月22日

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?
posted by koteitan at 14:34| Comment(0) | Java | このブログの読者になる | 更新情報をチェックする

2017年05月29日

文字列の結合の細かい話

ご存知のように、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セーフである必要はないやな。

posted by koteitan at 17:37| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2017年05月17日

Aixでのjava.util.prefs.Preferences

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

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

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

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

ΩΩΩ<ナンダッテー!

/etc/.java に入るlinuxとは違うみたいやね。
posted by koteitan at 11:56| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2016年10月02日

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();
        }
    }
}
続きを読む
posted by koteitan at 17:05| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2013年02月07日

[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;

とか書く。

まぁ、知らなくてもおk。
3つも4つもループするなら普通はprivateメソッドになるやろ。( ´Д`)
posted by koteitan at 17:47| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2013年01月30日

[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() の実装見てくれればわかるんだが
比較は大きくわけて5ステップある。

(1)自分自身か?
(2)文字列のインスタンス?
(3)文字数一致?
(4)ハッシュ一致?
(5)文字列のコンペア

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

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


posted by koteitan at 11:07| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2013年01月22日

[java]Dolphin!(3)

新しいコードスタイル(3)

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

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

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

posted by koteitan at 10:37| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2013年01月21日

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

メソッド1クラス65535!
フィールド1クラス65535!
インターフェース65535!
メソッドサイズ64KB!

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



posted by koteitan at 18:36| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2013年01月18日

[java]Dolphin!(2)

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

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

   int a2 = 0b00000111;

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

ビット操作要る局面が業務アプリであるかどうかは別として
ゲームとかだと結構使うと思うけど。
posted by koteitan at 13:27| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2013年01月17日

[java]Dolphin!(1)

まぁJDK7のコードネームなんだけどな。
5がtiger、6がMustang。虎、野生馬、ときてイルカ。( ′∇ソ ヨーワカラン このセンス。

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

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

        int a1 = 1234_5678_9;

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

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

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

        int inoki = 0x1_____2______3______daaaa;

   ボンバイエも可能。業務コードで書いたらしばかれるから注意な。
   マジックナンバーとして使えなくもないが、まぁやめとくがよいでしょ。
posted by koteitan at 14:39| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2013年01月11日

[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側は最低5秒まではsocketを維持している。
(維持しているだけで使用はできないのでご安心を)

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

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

posted by koteitan at 15:12| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2013年01月08日

[java][python] singpath

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

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

英語なのがネックだけど。
posted by koteitan at 17:27| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2012年10月26日

java-DeCompiler

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

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

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

※classやjarファイルを解析することははリバースエンジニアリングに相当するため、
 製品などのjarやclassの場合は禁止する旨がライセンスに記載されていることもあるので
 取り扱いは慎重に実施ください。
 何かあっても当方は一切関知しませんし責任も負いませんよ。
posted by koteitan at 18:27| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2012年02月08日

[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からの出直しになる。



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


パレートの法則。80:20の法則。

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

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



-制御したいんだが



  -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 は進化までの回数。デフォルトでは15回呼ばれると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
posted by koteitan at 11:23| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

[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は zOSのみでAIX/Linux/Win では発生
しない

posted by koteitan at 11:12| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

[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
posted by koteitan at 11:10| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2012年01月30日

[Java]-jar オプション

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

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

CLASSPATHが効かない。

-cpとかが無効になる。
アッハッハ。

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

いけてねーなぁ・・・。

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

このオプションを使用すると、指定した JAR ファイルがすべてのユーザークラスのソースになり、ユーザークラスパスのほかの設定は無視されます。
posted by koteitan at 17:36| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2011年04月28日

[java]Excella -Core Tips(2)

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

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

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

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

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

まとめる。


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

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

これも半日なやんだんだぜ。
posted by koteitan at 14:34| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする