GP2X Java On Gp2x?


PokeParadox

Founder of Pirate Games - Penjin Coder
Staff member
Joined
Dec 8, 2005
Messages
6,603
Age
40
Location
UK
Website
pokeparadox.itch.io
WEBSITE
https://github.com/pokeparadox
YOUTUBE
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.
 
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.
 
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.
 
bpmurray posted on Mar 19 2006 at 03:28 PM said:
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)
 
Last edited by a moderator:
PokeParadox posted on Mar 20 2006 at 11:26 AM said:
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.
 
Last edited by a moderator:
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
 
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.
 
bpmurray posted on Mar 20 2006 at 03:04 PM said:
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.
 
Last edited by a moderator:
Anhaedra posted on May 18 2006 at 09:14 AM said:
Nobody cares about Java going opensource? :(

It is good news but I think that people will be more excited once it actually happens.
 
Last edited by a moderator:
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.
 
rokdcasbah posted on May 19 2006 at 12:35 PM said:
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.
 
Last edited by a moderator:
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...
 
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 posted on May 24 2006 at 04:00 PM said:
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.
 
Last edited by a moderator:
Back
Top