1 :chinkasu:02/10/05 14:27
このすれ立てても一人としてレスはいるとはおもっちゃ
ねーけどさ
2ちゃんのアフォにはこのレス荒らすことぐらいしかできないと
思ってるぜ
お前らに期待を裏切るような書き込みをリクエストする


20 :デフォルトの名無しさん:02/10/07 23:02
Windows + Java でクライアントアプリケーション開発してるけど、
JNI経由でWin32APIを適当に利用すると便利だね。
javaではスクリーンサイズしか取得できないけど、
JNI使えばタスクバーを除いたスクリーンのサイズを取得できるとか。
ファイルチューザーなんぞもWindowsの呼び出す方が楽だし。

みんなは、JNIでどんなことしてる?

26 :デフォルトの名無しさん:02/10/08 23:20
>Windows + Java でクライアントアプリケーション開発してるけど、
>JNI経由でWin32APIを適当に利用すると便利だね。
うちの会社ではwindows上のクライアントアプリを作るために、
GUIとかAPIをJNIでラップしてるやつ買ったよ。
便利だね。
C#のライブラリーはなんであんなに糞なの?

27 :デフォルトの名無しさん:02/10/08 23:25
>>26
> GUIとかAPIをJNIでラップしてるやつ買ったよ。

Javaって write once run anywhere がウリなのにそんなことしたら
意味ネーじゃん。馬鹿?

37 :20:02/10/09 01:02
>>26
へー、売り物でそんなラッパーがあるですか?
良かったら製品名とか教えてもらえませんか?

>>27
write once run anywhere なんて言ってる人がまだいたんだ…
今、javaに魅力を感じてる開発者って「どこでも動く」ということより
言語仕様、充実してきたクラスライブラリに惹かれてるのではないかと。

80 :Java軍曹:02/12/27 04:18
まず普通に一本Javaアプリこしらえて、それをその後、ガッツンガッツンのキッリキリに
JNIに置き換えて...というか全て中身DLLに挿げ替えて、最終的に static void mainと、
そこから連なる一連のメソッドのインタフェースだけをJavaとして残す。
つーか、エントリ以外ほぼ全てnative宣言。
....っていう強○まがいのコードが書きたい。いや、むしろ一度書いてみたい。

write once , run here only.

85 :デフォルトの名無しさん:02/12/27 05:17
>>80
それだったら C言語 のソースをJavaのバイトコードに落とせるコンパイラとか書いた方が面白そう。

101 :デフォルトの名無しさん:02/12/28 01:31
>>85
CをJavaに変換するなんてとても容易にできることだとは思えないぞ。
ポインタ、アドレス操作も大変だし、
メモリリーク、配列のバッファーオーバーフロー起こすことができるCソースをそのまま
Javaに変換しても動かないし。

Cの構造体をJavaに変換するとフィールドがすべてpublic、だが値型。
構造体への構造体も値型であるから、
それをクラスの中にあるクラス(クラスの集約)として変換しても
どう考えたってそのまんまではエラー。
Javaではクラス(オブジェクト)はすべて参照型と決まっているからね。
変換したいCソースにC++コードいれたらとんでもないことになりそうだね。

ほかにも容易でない理由はまだまだあるんだけど、きりがないからこれくらいにしておこう。

CをJavaに自動変換するなんて現状ではまだ現実的とは思えないな。
JavaをCに変換するのは簡単だけどその逆は容易でない、というか、
不可逆反応です。それだけJavaが整然としたすっきりとした言語ってことだね。

JavaをC#に変換するJUMP to .NET ですら変換がうまくいかないことがあり、
RMI使っているJavaソースや一部のJava独自のライブラリをC#に変換できないというし。

ある程度は自分で書き直した方が早いんじゃないかな。

104 :デフォルトの名無しさん:02/12/28 01:39
>>101
C言語ソース -> Javaソース じゃなくて
C言語ソース -> Javaバイトコード だったら出来るんじゃない?

それに C言語ソース -> Javaソース だったら
可変長引数の処理とかも無理っぽいし。

110 :デフォルトの名無しさん:02/12/28 05:16
>>104
可変長引数なら、
可変長引数をあらわすこんなクラスをつくればいいんじゃないか?
import java.util.Vector;

public class VariableLengthArgument {
private int number;
private Vector vector;
public VariableLengthArgument(){
number = 0;;
}

public void add(Object obj){
vector.add(obj);
number++;
}

public Object get(int index){
return vector.elementAt(index);
}

public int getNumber(){
return number;
}
}

111 :デフォルトの名無しさん:02/12/28 05:42
>>110
それだったら素直に Vector 使った方が早い。

117 :デフォルトの名無しさん:02/12/28 17:37
public class Point3d {
????????public double x;
????????public double y;
????????public double z;

????????...

????????public void add(Point3d p) {
????????????????this.x += p.x;
????????????????this.y += p.y;
????????????????this.z += p.z;
????????}

????????...
}

このaddメソッド程度のものをnativeで書いた場合とどちらが速いんですかね?
そういったことを試したサイトありませんか?

139 :デフォルトの名無しさん:03/01/04 15:21
ううむ、JIT様がガリガリ最適化したら、
どう書いても同じになりそうな気がするんだが
そうでもないのか。

182 :デフォルトの名無しさん:03/01/13 15:44
>>139
JIT様の最適化にも癖があるよーで…

185 :デフォルトの名無しさん:03/01/18 00:09
>>182
いわゆるJITってクラス境界を越えたinline化はしないのかな?
そうでもしないと限界がすぐに見えちゃう気がするけど。

最近JNIをやってるのですが、JNI Callしたあとって必ず
Exceptionのチェックをしないとダメなんですかね?
かなりウザいんですが・・・

下がりすぎてるようなのでage

188 :デフォルトの名無しさん:03/01/18 10:03
>>185
> Exceptionのチェック
んなわけない

190 :デフォルトの名無しさん:03/01/18 11:34
>>188
そうなの?FindClassとかGetMethodIDとかは戻り値が0だったら
エラーが起こってるのは判るけど、
CallObjectMethodとかだと戻り値だけじゃわかんないやん。

で、一度exceptionが起こると、続くJNI呼び出しはおかしくなるようです。
つかjava.exeが固まります(jdk1.4.1)。というわけで

env->CallIntMethod();
check();
env->CallObjectMthod();
check();
...

なんていうコードを書くハメになったりするわけですが、激しくダサい。

198 :むー:03/01/24 04:05
>>190
Javaメソッド呼んだ後にExceptionOccurredでチェックして例外発生して
たらC++例外投げるようなJNIEnvのラッパーみたいなの書いて、
nativeメソッド全体をtry-catchで囲んどいてラッパーから投げたC++例外
をキャッチしてJava側にさっくり戻る、みたいなことやったりしたらだめかね?


199 :デフォルトの名無しさん:03/01/24 23:46
>>198
結局そうなりますた。
が、windowsでは動きましたがlinuxではJVMがクラッシュしますた。
例外が原因らしいことまでは分かったのですが・・・

200 :デフォルトの名無しさん:03/01/25 09:26
>>199
そんなに甘くないのか… なんでだろう?
Linux版のJVMではJava例外の実装にC++の例外機構の何かを使って
バッティングしちゃった、とかそんな理由なんかな。
stack-unwindでJVMのスタックかどっかを破壊しちゃうとか。
core見ないとわかんなそうだけど、JVMのcore読みなんて鬱すぎる…

203 :デフォルトの名無しさん:03/01/26 09:37
>>200
こんなのありますた
http://mail.gnu.org/archive/html/bug-lib-gplusplus/2000-10/msg00004.html

ショボーン
http://mail.gnu.org/archive/html/bug-lib-gplusplus/2000-11/msg00006.html

ショボーン
http://wmf.editthispage.com/discuss/msgReader$3455?mode=topic

344 :デフォルトの名無しさん:04/04/07 10:37
Java側 → Win32dllは、JNIにて実現できる通信ですが、
Win32exe(プロセス) → Java側を実現するには、どのような手段が一番いいですかね?

アプリケーション間通信だけできればいいので、できればあまり大げさにはしたくないです。
Win32間でないからパイプは無理だし、一つのOS上での通信なのでソケット通信は少々大げさかなと。

345 :デフォルトの名無しさん:04/04/07 10:38
>>344
>Win32間でないからパイプは無理
嘘だろ?

374 :デフォルトの名無しさん:04/12/09 00:41:58
JNIでdefineClassメソッドを使ってbyte配列から取得したクラス情報を元に、インスタンスって生成できますか?
それにしても、JNIのDefineClassってどうやって使うんだろう・・。

375 :デフォルトの名無しさん:04/12/09 00:48:26
DefineClassってJNIじゃないだろ


376 :374:04/12/09 00:55:46
>>375
クラス操作 DefineClass
jclass DefineClass(JNIEnv *env, jobject loader, const jbyte *buf, jsize bufLen);
raw クラスデータのバッファからクラスをロードします。
パラメータ:
env: JNI インタフェースポインタ
loader: 定義されたクラスに割り当てられるクラスローダ
buf: .classファイルデータを含むバッファ
bufLen: バッファ長
戻り値: クラスオブジェクトを返します。エラーが発生した場合は null を返します。

ttp://java.sun.com/j2se/1.4/ja/docs/ja/guide/jni/spec/functions.doc.html


377 :デフォルトの名無しさん:04/12/09 01:17:16
いや、それやりたいのならJNI必要ないだろうという意味だ
コアAPIでできるんだから


378 :374:04/12/09 07:48:29
>>377
それをネイティブコードでかけるかという質問なんです。

390 :デフォルトの名無しさん:04/12/18 21:10:34
>>376
JNIインタフェースのDefineClassって、
バージョン毎にシグネチャが異なるのか?
それともヘルプが間違ってるだけなのか?

あと使い方誰か教えてくれ。
何度やってもネイティブコード上でうまくインスタンスを取得できない。

399 :デフォルトの名無しさん:04/12/19 16:02:26
そういうこと

苦労してJNIでクラスローダ作ったところでいくらでもいじられるんだし
JNIのコードだってスタックサイズの制限とかで大きいの作れないんだから
余裕で解析されるだろうな

それくらいなら帯域とかあるだろうがURLクラスローダを継承して通信を暗号化、
毎回ロードするほうがまだ現実的

ネトゲとかでいくらネイティブコードでもbotとかツールとかなくせないわけだしね
安全性のためにJNIってのは意味ない

400 :デフォルトの名無しさん:04/12/20 00:03:00
>>399
> それくらいなら帯域とかあるだろうがURLクラスローダを継承して通信を暗号化、
> 毎回ロードするほうがまだ現実的

「まだ現実的」ってのがどういうことを意図しているのかよくわからんが、
JNIでクラスローダ作るのって大した手間じゃないし
ネットワークを意識しなきゃならんほうがいろいろ面倒だと思うがね。

460 :デフォルトの名無しさん:2006/05/22(月) 09:43:09
JNIでネイティブのDLLを呼び出すJAVAアプリ作ったんだけど、
JARファイルにまとめると動いてくれないよ。(エラーも出ずに何も反応無く終了する)
JARファイル中のDLLを読み込むにはloadLibraryかloadじゃなくて
findLibraryかなにかで読み込めば良いの?

461 :デフォルトの名無しさん:2006/05/22(月) 10:00:30
>>460
標準のJNIのローダーはjarに対応してたっけ?
ネイティブのファイルシステムに置いて無いとダメじゃないのか?

471 :デフォルトの名無しさん:2006/07/12(水) 13:09:44
CHAR *GetStringFromJstring(JNIEnv *env, jstring jstr)
{
CHAR *sjisCode = 0;
INT32ret = 0;
const jchar *jchr = 0;
INT32jlen = 0;

// jstringがNULLではないときのみ処理を行う
if(jstr != NULL)
{
// 文字列、文字長の取得
jchr = env->GetStringChars(jstr, NULL);
jlen = env->GetStringLength(jstr);

// バッファの確保(すべて2バイト文字だった場合を想定)
sjisCode = (CHAR *)malloc(jlen * 2 + 1);
if (sjisCode != NULL)
{// メモリ確保成功
memset(sjisCode, 0, (jlen * 2 + 1));
// コード変換
ret = WideCharToMultiByte(CP_ACP, 0, jchr, jlen, sjisCode, jlen * 2 + 1, NULL, NULL);
sjisCode[ret] = '\0';
}

// 取得文字列の開放
env->ReleaseStringChars(jstr, jchr);
}
return sjisCode;
}

479 :デフォルトの名無しさん:2006/09/05(火) 22:25:34
JNIの勉強をしているのですが,CPU使用率のように連続的にデータを取得する際,
Java側からwhileループをまわして何度もdllを読み込むという非効率な方法をとっています.
一度dllを呼び出すだけで連続的に返り値を読み取る方法はあるのでしょうか
ご教授お願いします.

480 :デフォルトの名無しさん:2006/09/05(火) 22:36:18
>>479
dll読み込む、dll呼び出すってのが、具体的に何を指して言ってるのかわからん。

481 :479:2006/09/07(木) 12:53:19
>>480
言葉が足りなくてすみません.
dll読み込む、dll呼び出すというのは,ネイティブメソッドを実行するという意味で書きました.
現在はネイティブメソッド実行時に,返り値としてCPU使用率を取得しているのですが,
この方法ではJava側でWhileループで何度もネイティブメソッドを実行する必要があります.
ネイティブメソッド側でWhileループをつかってJavaに連続的に値を返す方法は
ないのでしょうか

590 :デフォルトの名無しさん:2008/08/14(木) 01:26:18
こんな感じ?

#include <jni.h>
JNIEXPORT jobject JNICALL Java_Goodbye_getGoodbye(JNIEnv *env, jclass clazz) {
return (*env)->NewDirectByteBuffer(env, "goodbye", 7);
}

import java.nio.*;
public class Goodbye {
public static void main(String[] args) {
System.loadLibrary("goodbye");
ByteBuffer buffer = getGoodbye();
byte[] b = new byte[buffer.remaining()];
buffer.get(b);
System.out.println(new String(b));
}
private static native ByteBuffer getGoodbye();
}

609 :デフォルトの名無しさん:2009/01/02(金) 03:54:04
このコアダンプももう見飽きたw

# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x61e012bb, pid=1668, tid=1888
#
# Java VM: Java HotSpot(TM) Client VM (11.0-b15 mixed mode, sharing windows-x86)
# Problematic frame:
# C [sse.dll+0x12bb]

Current thread (0x002b7400): JavaThread "main" [_thread_in_native, id=1888, stack(0x00900000,0x00950000)]

siginfo: ExceptionCode=0xc0000005, reading address 0xffffffff

Registers:
EAX=0x00000000, EBX=0x26947e88, ECX=0x002b7a98, EDX=0x00000004
ESP=0x0094fbb8, EBP=0x0094fc00, ESI=0x0094fc2c, EDI=0x002b7400
EIP=0x61e012bb, EFLAGS=0x00010206

Top of Stack: (sp=0x0094fbb8)
0x0094fbb8: 002b7400 0094fc44 00000000 00000004
0x0094fbc8: 0094fbd8 47012a00 00a06a48 00a06fda
0x0094fbd8: c2040000 c2b00000 c2c60000 41b00000
0x0094fbe8: c7417200 c800f880 c8111580 47012a00
0x0094fbf8: 00989e07 0094fbfc 0094fc38 00a0926b
0x0094fc08: 002b7514 0094fc2c 0094fc24 00000000
0x0094fc18: 00000004 0094fc44 00000000 2298a768
0x0094fc28: 00988069 269483a8 2298a788 00000004

Instructions: (pc=0x61e012bb)
0x61e012ab: 45 08 89 04 24 8b 82 34 03 00 00 ff d0 83 ec 14
0x61e012bb: 0f 28 45 e8 0f 58 45 d8 0f 29 45 e8 8b 45 08 8b


http://hibari.2ch.net/test/read.cgi/tech/1033795664/l50人気ブログランキングへ