64bitPC上で32bitEclipse
ひさびさにEclipse RCP(SWT)アプリを作ってみたら、新規プロジェクト作成後の雛型プログラムの実行さえ動かない。
java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on 64-bit JVM
開発PCは64ビットで、Eclipseは32ビット(実行環境が32ビットPC含むSWTアプリなので)。
あれ〜?変だな〜?と10分ぐらい思考停止してたけど、
Eclipse(32ビット)がデフォルトでチョイスしてるJavaが64ビットのやつだった。EclipseのJDKの設定で、JDKを32ビットのに変更したら動いた。
開発PCにEclipse、Javaそれぞれ64ビット、32ビット両方入ってて、何ヶ月も前に入れたやつだし、このあたりの設定たまにしか気にしないから完全に失念してた。多分、何ヶ月後かに同じトラブルに見舞われそうなのでメモしとく。
Rを解決
Eclipse KelperでADTをインストールして、Hello World的プログラムを作ろうとしたら、Androidプロジェクトを作成した時点で、エラーになる。
Rを解決できません (android r cannot be resolved into a variable)
なにこれー、Junoのときはなかったのにー?
で、ぐぐったら、Android SDK Build-toolsをインストールしてないかららしい。
Android SDK Rev.22で、Build-toolsが分離されて、別途インストールが必要になったとか。Android SDKマネージャーから、Build-toolsをインストールすると直った。必須なものなら、ADTのインストール時に強制的に入れてくれてもいいのに・・・
参考
http://stackoverflow.com/questions/16608524/eclipse-giving-error-missing-r-java-file-after-recent-update?lq=1
http://creadorgranoeste.blogspot.jp/2013/05/android-sdk-22-build-tools.html
JavaSoft/Prefsがないとか何かエラー
新しくPCにWindows7とJavaを入れてちょっとプログラムを動かしてたらば、こんなエラーに出くわした。なにこれ初体験。
WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.
ぐぐってみると、こんなのがありました。
Preference APIがレジストリに書き込もうとして失敗しているらしい。
とりあえず解決法のとおり、regeditでJavaSoftの下にPrefsキーを作ったら、エラーはでなくなった。
Running clemb in Windows 7 will produce the following error: Windows RegCreateKeyEx(...) returned error code 5
http://www-01.ibm.com/support/docview.wss?uid=swg21496098
Resolving the problem
The work around is to login as the administrator and create the key HKEY_LOCAL_MACHINE\Software\JavaSoft\Prefs.
しかし、原因が謎だ・・・Javaのインストールでこんな失敗とかあるのか?
参考
Preferences API→データはどこに
http://www.javainthebox.net/laboratory/JDK1.4/MiscAPI/Preferences/Preferences.html
Oracle Java JDK 7 Source Files
http://sourceforge.jp/projects/sfnet_jdk7src/
OracleのJDKのsrz.zipはsun.xxxなどのソースが入ってない
これはOpenJDK projectから生成した全部入りソースらしい
Java7にしたらHTTPS通信でエラーになる
Caused by: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
at sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(SSLContextImpl.java:946)
at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:872)
at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:814)
...
昔作ったJava6ベースのアプリでX509TrustManagerをカスタマイズして実装している場合、ちょっとうまくないみたい。
7113275 : compatibility issue with MD2 trust anchor and old X509TrustManager
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7113275
とりあえずの対処(セキュリティーには目をつぶって、とりあえず動けばいい的な)としては、
java.secureityファイルの以下をコメントにする
jdk.certpath.disabledAlgorithms=MD2
か、同様のことをコード中でも可能
Security.setProperty("jdk.certpath.disabledAlgorithms", "");
参考
Arrrggh! java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
http://www.richardnichols.net/2012/08/arrrggh-java-security-cert-certificateexception-certificates-does-not-conform-to-algorithm-constraints/
プログラムの中でアルゴリズム制限を指定する
http://blog.livedoor.jp/k_urushima/archives/1615933.html
Java7では"・"が使えない
テストケースなどのメソッド名で使ってるとエラーになる
http://johtani.jugem.jp/?eid=73
Java6ではUnicodeのバージョンが4.0です。Java7ではUnicodeのバージョンが6.0に変更されています。
今回の問題は「・」(0x30FB)の文字列のCharacter.getType()がCONNECTOR_PUNCTUATIONからOTHER_PUNCTUATIONに変更されたのが原因です。(この変更自体はUnicode 4.1で変更されたみたい)
カタカナ文字種の判別をlucene-gosenのnet.java.sen.tokenizers.ja.JapaneseTokenizerのgetCharClass(char c)メソッドで行なっています。