GP2X Java On Gp2x?

[PokeParadox]

I'm only really asking due to the fact I have a mobile and webgames module in which the language is java. If the java code could run on my GP2X I would show more enthousiasm for the language. (That's the idea anyhow.)

One of my friends in my course raised the idea, so I thought I'd put it to you all.

 

[aapje89]

there is a javavm for gp2x but it sucks.
I dont know what it exactly can and can not do, sorry (check the file archive).

 

[lemon]

gcj is able to native compile java code so its probably possible to compile gcj for arm and then use it to create native arm binaries of your java code which don't need a vm.

 

[bpmurray]

I've been looking at JamVM, which is a full J2SE (not a J2ME). I'm having problems compiling, but it certainly looks like something that could be used. However, I'm using cygwin, and I think I'll have to switch to Linux.

 

[edanuff]

I've been looking at JamVM, which is a full J2SE (not a J2ME).

Over on the Nokia 770 mailing list, they've been tackling this same thing. Someone there documented it on his website.

http://www.microemu.org/maemo/

Here are what appear to be the most common set of projects used to get some form of Java running on handhelds:

VM:
JamVM - http://jamvm.sourceforge.net/
SableVM - http://sablevm.org/
Kaffe - http://www.kaffe.org/

Compiler:
Jikes - http://jikes.sourceforge.net/

Classes:
GNU Classpath - http://www.gnu.org/software/classpath/

UI:
SWT - http://www.eclipse.org/swt/
AWT - Odonata AWT - http://odonata.tangency.co.uk/
SDL - sdljava - http://sdljava.sourceforge.net/

J2ME:
MicroEmulator - http://www.sourceforge.net/projects/microemulator)

 

[PokeParadox]

Wow, this is lookin fairly positive!

 

[edanuff]

Wow, this is lookin fairly positive!

​

Well, it shows that it's feasible anyway. Someone with time on their hands needs to take it on (not me, unfortunately), but all the raw ingrediants are there.

 

[Octoate]

There is also another JVM with a JIT compiler which is actively developed since 1997 called CacaoJVM. It also works with GNU Classpath and seems to be designed for the use with embedded devices.
And this are the supported platforms:

CACAO has been compiled and tested by the developers on the following platforms:

* alpha-unknown-freebsd5.4
* alpha-unknown-linux-gnu
* arm-unknown-linux-gnu
* i386-unknown-freebsd5.3
* i686-pc-linux-gnu
* mips-sgi-irix6.5
* mips-unknown-linux-gnu
* powerpc-apple-darwin7.2.0
* powerpc-unknown-linux-gnu
* x86_64-unknown-linux-gnu

 

[bpmurray]

That all sounds about right. There are two parts, the runtime classes and the virtual machine. I'm currently chewing through GNU classpath 0.90, and it looks like I'll have to play around with jawt.c, since it seems to assume that AWT is a minimum requirement. This does make sense, since we're talking about a full J2SE.

Anyway, I'll continue along this path until I hit a wall & I'll keep this thread posted as I go.

 

[edanuff]

I'll have to play around with jawt.c, since it seems to assume that AWT is a minimum requirement.

I haven't tried it yet, but I think that you can use the Odonata AWT classes with SdlJava instead of the Classpath AWT.

 

[Anhaedra]

Java is going open source, so yes, I suppose this is possible.

http://www.computerworld.com/action/articl...=NLT_BNA&nlid=1

 

[Anhaedra]

Nobody cares about Java going opensource?

 

[edanuff]

Nobody cares about Java going opensource?

It is good news but I think that people will be more excited once it actually happens.

 

[Parkydr]

Has anyone seen java running on other handhelds? My experience of Java on older PCs is that it uses lots of processor and memory.

 

[rokdcasbah]

yeah i learned a little java and at first i was interested in figuring out a way to get something running on the gp2x, but then i realized:

java is ass slow!

i don't think i have a single game on my phone that controls nicely...it always takes a ridiculous amount of time to register a button hit.

some light reading:

http://www.jelovic.com/articles/why_java_is_slow.htm
http://www.armadilloaerospace.com/n.x/john...ive?news_id=295

to sum it up:
- lots of (dynamic) casts in java.
- all objects, regardless of size, go on the heap.
- automatic garbage collection
- garbage collection plus larger heap = more memory used and possible use of virtual memory

perhaps once it's made open source we'll see some more different implementations.

 

[zzhu8192]

yeah i learned a little java and at first i was interested in figuring out a way to get something running on the gp2x, but then i realized:
java is ass slow!
to sum it up:
- lots of (dynamic) casts in java.
- all objects, regardless of size, go on the heap.
- automatic garbage collection
- garbage collection plus larger heap = more memory used and possible use of virtual memory
perhaps once it's made open source we'll see some more different implementations.

While many of these points are true in general, there are ways to work around each one. One could argue that then you'd be defeating the purpose of using Java at all, which is probably a valid point. Some of the reasons why I use Java is because:
1) Great IDE's 2) Great analysis 3) multi-platform 4) Easier debugging 5) Simple language 6) language protection features like type safety and bounds checking really expedites development.

Some potential work arounds on above points:
- dynamic casts. well, just don't cast. And don't use any libraries that is based on runtime dynamic types. Or you can use lots of static methods/functions.

- objects go on the heap/garbage collection. Nothing inherently wrong with the heap. The problem is more like the garbage collector can slow you down at bad/all times. Well, just allocate everything at the beginning and don't dynamically allocate anymore.

Other issues not mentioned.
- array bounds checking. well, don't use arrays, at least not java arrays. :lol:
- slow startup. well, you can use GCJ. it will help startup time a bit. Not as long as JVM init time.
- No JIT for arm that I'm aware of. The blackdown SDK I found for arm doesn't seem to work right.

If you write some mathematically intensive apps in Java, you'll find that they run quite nicely compared to C++. Some Java progs may even run faster (although that seems unlikely). The only rationale for that is perhaps the JIT is doing a better job of optimization to native code than say GCC/G++ at compile time. This makes sense since the JVM knows more about performance statistics at run time than static compilers at compile time. (Although you can work around this too with GCC using profiling)

Sorry about the rant, but I think that Java is not all bad, even for mobile/embedded programming.

 

[rokdcasbah]

i'm sure you know more about it than me.

i'm still planning on learning python at some point...hopefully that will be a good transition to c.

don't use arrays! that sounds painful...

 

[bpmurray]

Actually, just back from JavaOne, and the usual "Java's going opensource but ...." story was touted. I think it probably will eventually, but under such strict conditions that it will miss the spirit of OSS by a mile, i.e. it'll still be Sun's code and Sun will decide how it goes, etc., just like the JCP conditions.

 

[PSyMastR]

Isn't there a program that fully compiles java for arm platforms?

 

[bpmurray]

Isn't there a program that fully compiles java for arm platforms?

Yes - the GNU toolchain has a Java compiler. However, by doing that, you produce an executable that's platform-specific. The idea of Java is that it's more than just a language: it's a platform, i.e. write once, run anywhere. So when you compile your java app into a jar, that can be executed by any JVM on any platform (at least, that's the theory).

Apropos the performance of Java, it's quite comparable to that of any compiled programs. In fact, the vtable management in Java is generally more efficient than C++. Old version of Java weren't particularly fast, but since 1.2, it's been pretty darn quick indeed. The only inefficiency is the heap usage, but you can optimize that using the commandline settings for your VM.