java - JamVM on Motorola FX9500 Problems - what should I do? -

i using motorola fx9500 rfid reader, runs linux jamvm version 1.5.0 on (i can deploy applications - cannot change java vm or options limited) - here's see when check version:

[cliuser@fx9500d96335 ~]$ /usr/bin/jamvm -version java version "1.5.0" jamvm version 1.5.4 copyright (c) 2003-2010 robert lougher <rob@jamvm.org.uk>  program free software; can redistribute and/or modify under terms of gnu general public license published free software foundation; either version 2, or (at option) later version.  program distributed in hope useful, without warranty; without implied warranty of merchantability or fitness particular purpose.  see gnu general public license more details.  build information:  execution engine: inline-threaded interpreter stack-caching compiled with: gcc 4.2.2  boot library path: /usr/lib/classpath boot class path: /usr/local/jamvm/share/jamvm/classes.zip:/usr/share/classpath/glibj.zip 

i need write application grabbed oracle java sdk 1.5.0 , installed onto windows 7 pc, has version:

c:\>javac -version javac 1.5.0 

am being idealistic in considering application compile compiler work correctly on aforementioned jamvm? anyway, pressing on in ignorance write little application:

public final class testapp {     public static void main(final string[] args) {         long p = long.min_value;         int o = (int)(-(p + 10) % 10);         system.out.println(o);     } } 

compile aforementioned javac compiler , run on pc so:

c:\>javac testapp.java  c:\>java testapp 8 

all fine there. life good, take .class file , place on fx9500 , run so:

[cliuser@fx9500d96335 ~]$ /usr/bin/jamvm testapp -2 

eek, the...as can see - returns different result.

so, why , who's wrong or specification not clear how deal calculation (surely not)? need compile different compiler?

---

why care this?

the reason came situation calculation happens inside java.lang.long.tostring , have bug in real application logging out long , getting java.lang.arrayindexoutofboundsexception. because value wanting log may @ ends of long.

i think can work around checking long.min_value , long.max_value , logging "err, can't tell number long.xxx, believe me, lie you?". when find this, feel application built on sandy foundation , needs robust. considering saying jamvm not job , writing application in python (since reader has python runtime).

i'm kind of hoping tells me i'm dullard , should have compiled on windows pc .... , work, please tell me (if true, of course)!

---

update

noofiz got me thinking (thanks) , knocked additional test application:

public final class testapp2 {     public static void main(final string[] args) {          long p = long.min_value + 10;          if (p != -9223372036854775798l) {             system.out.println("o....m.....g");             return;         }          p = -p;          if (p != 9223372036854775798l) {             system.out.println("w....t.....f");             return;                     }          int o = (int)(p % 10);          if (o != 8) {             system.out.println("eeeeek");             return;         }          system.out.println("phew, close one");     } } 

i, again, compile on windows machine , run it.

it prints phew, close one

i copy .class file contraption in question , run it.

it prints...

...wait it...

w....t.....f

oh dear. feel bit woozy, think need cup of tea...

update 2

one other thing tried, did not make difference, copy classes.zip , glibj.zip files off of fx9500 pc , cross compile (that must mean compiled file should fine right?):

javac -source 1.4 -target 1.4 -bootclasspath classes.zip;glibj.zip -extdirs "" testapp2.java 

but resulting .class file, when run on reader prints same message.

i wrote jamvm. guess, such errors have been noticed now, , jamvm wouldn't pass simplest of test suites them (gnu classpath has own called mauve, , openjdk has jtreg). regularly run on arm (the fx9500 uses pxa270 arm) , x86-64, various platforms tested part of icedtea.

so haven't of clue what's happened here. guess affects java longs these used infrequently , programs work. jamvm maps java longs c long longs, guess compiler used build jamvm producing incorrect code long long handling on 32-bit arm.

unfortunately there's not can (apart avoid longs) if can't replace jvm. thing can try , turn jit off (a simple code-copying jit, aka inline-threading). use -xnoinlining on command line, e.g.:

jamvm -xnoinlining ...