World: r4wp

Stack: [0xb69b4000,0xb6a05000],  sp=0xb6a03ea8,  free space=319k

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, 
C=native code)
C  [libc.so.6+0x764f3]  short+0x33
V  [libjvm.so+0x3f1541]  unsigned+0xe1
C  [libJNIdemo.so+0xc9c]  long double+0xc9c
C  [libJNIdemo.so+0xd24]  long double+0xd24
C  [libJNIdemo.so+0xefd]  Java_JNIdemo_doMain+0xbd
j  JNIdemo.doMain()V+0

It's crashing for Pekr too, and he's probably on Windows.

yes, Windows8

Do you want me to send you an error log it generated in the working 
directory?

Yes please, but in private channel (or email).

Andreas: reproduced a crash on Linux 32-bit with Java 1.6.0_27.

C  [libc.so.6+0x76550]  __strerror_r+0x190
V  [libjvm.so+0x22cc29]  jni_GetMethodID+0x99
C  [libJNIdemo.so+0xc9c]  exit+0xc9c
C  [libJNIdemo.so+0xd24]  exit+0xd24
C  [libJNIdemo.so+0xefd]  Java_JNIdemo_doMain+0xbd
j  JNIdemo.doMain()V+0
j  JNIdemo.main([Ljava/lang/String;)V+0

Java: "write once, debug everywhere" ;-)

Could someone else test it on Windows XP, 7 and 8?

Dinner time, bbl.

ok, sent to your email at red lang org ....

Thanks.

You're not declaring the calling convention of the functions in the 
interface table, so that's probably the problem on Linux

I'm not sure, but the way I read the C header, the VM parameter in 
your JVM! struct functions needs another reference level

Kaj: good points. For the VM parameter, it's unused anyway.

It's crashing anyway.

Found the cause of the error, will push a fix in a few minutes.

It's now running fine on my Linux 32-bit image.

Tested ok on Mac OSX 10.6.2 (adding the -d32 option for running the 
JVM in 32-bit mode).

The window closing is generating a Java exception on OSX, I will 
improve the code to make a more JVM-friendly exit.

hmm, nice observation, this java crap is case sensitive :-)

whoever came with case sensitivity in unix like system, should have 
broken hands long time ago :-)

Does it work now for you?

basically I got it working, it generated some events.class, but when 
I close the dialog, it throws some exceptions back to console. But 
yes, it is working ....

Can you show me the full output of `java -version`?

(checking if you're using a 64-bit VM)

java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)

Ok, try adding -d32 option when launching the app.

hmm, now tried to delete .class files and regenerate, I obtained 
following:


Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\!rebol\!Red\Red\re

d-system\bridges\java\JNIdemo.dll: Can't load IA 32-bit .dll on a 
AMD 64-bit pla
tform

        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary1(Unknown Source)
        at java.lang.ClassLoader.loadLibrary0(Unknown Source)
        at java.lang.ClassLoader.loadLibrary(Unknown Source)
        at java.lang.Runtime.loadLibrary0(Unknown Source)
        at java.lang.System.loadLibrary(Unknown Source)
        at JNIdemo.<clinit>(JNIdemo.java:9)

Have you used -d32 for launching the JVM?

I have some mess on my system, installing JDK did not add it to path, 
so I have to issue long Windows shitty path in console each time 
....

Yes: Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\!rebol\!Red\Red\re

d-system\bridges\java\JNIdemo.dll: Can't load IA 32-bit .dll on a 
AMD 64-bit pla
tform

I'm upgrading my JDK to 1.7 to see if I can reproduce those issues.

Pekr, I'm afraid you'll need to install a 32-bit JVM to make it work 
with Red.

well, dunno how, but it worked initially (dialog appeared), then 
I deleted .class files, and not being able to get it working again 
...

sho should I download whole 32 bit JDK?

downloading now ...

The first class files where generated on Andreas 32-bit machine.

were

Use the minimal JDK version.

http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html

You might need to uninstall the 64-bit version first.

they can't coexist? Btw - so 64 bit version is no go ATM?

I'm not sure they can coexit as Java is setting some environment 
variables that are unique.

Upgraded my JDK to 1.7.0_21, recompiled JNIdemo on Win7, everything 
is working fine.

Looks like -d32 option is working on OSX only, so a 32-bit JVM is 
required on other platforms.

(My .class files where generated on a 64-bit machine, but that does 
not matter.)

Anyway, Android is using a 32-bit JVM.

So we shouldn't have a problem there.

What does the bridge do?