Hello.

As you can guess my the title, I am starting a project to port a Java Virtual Machine to the Nspire.

So far I have found an open sourced JMV here

http://jamvm.sourceforge.net/

That I believe can be ported to the Nspire. It is also written almost entirely in C so I think that'll help.

What I want to do is basically be able to take any Java byte code, and be able to run it on the Nspire. (Possible Minecraft, anyone?)

However, I don't know where to start with this project. I downloaded the source for the JVM and found the main file, however I do not know what I need to do to port it to the Nspire.

I hope that this can become a community project where anyone can contribute, because if it were only myself, it might never come to fruition, which would be a shame.

So, first question, where do I start? ExtendeD suggested to me earlier to try to compile the project as is using the Ndless SDK to see what dependencies aren't supported, although I don't know what I should make for a makefile to do that.

Thanks!

:O This makes me want to leanr Java!!! DO NOW !! lol
Now if only this could be done with C++

i might be interested. also did you try what extended suggested, thats how i would do it, get one bug out at a time

Well, I'm trying to figure out how to try what Extended suggested. I don't exactly know what I need to do with make, includes, etc.

A ton. I count at least 47 files.

I have some time on my hands. Mainly on the Weekends though.

Yeah, once this gets started I'll start a sourceforge project for it, or perhaps a DropBox Shared Folder.

Something for multiple people to collaborate on the project.

You won't see minecraft. It uses a few native code libs which will be worse to port than the whole JVM, like LWJGL.

Not to say you shouldn't do it! There's plenty of stuff (games) that run with pure java libs.

First of all: such projects are interesting because they can indeed help filling in the blanks of the Ndless infrastructure, and therefore help other projects, which is a good reason to pursue them - not to mention that they can be a good learning experience

But if the port of JamVM and its dependencies (GNU Classpath...) is completed, people should not set their hopes too high about its speed, for the practical purposes of, say, running Java games on the Nspire. Not to say that it shouldn't be done, but here are several facts:
* JamVM's performance is better than that of a number of other JVMs, but it's not the most optimized JVM for ARM platforms. The one in OpenJDK / IcedTea (well, Sun/Oracle's code) is, but chances are that it's harder to compile than JamVM is, and it definitely has a much larger fooprint;
* GNU Classpath (which is what released versions of JamVM use) is missing lots of classes and methods, and it's unmaintained; OpenJDK's class library is not necessarily very easy to compile either, and it has a larger footprint than GNU Classpath has, because it's more complete.

I'm speaking out of my recent professional experience with Java (precisely JamVM, GNU Classpath, OpenJDK) and native code on recent ARM platforms, and I don't mean to bash Java
The platforms I've used / I'm using have superscalar Cortex-A8/A9 processors (i.e. more advanced than the ARM9 in Nspires), clocked at much higher frequencies (4x-8x), and they have much more RAM (512 MB or 1 GB), than Nspires... and yet, on such platforms, CPU-intensive native code is more or less an order of magnitude slower than on modern x86_64 cores. What performance can interpreted languages achieve on platforms which are nearly an order of magnitude less powerful than those ? Yeah, probably not much better than TI's proprietary, non-standard Lua, or a third-party port of LuaJIT


Reo: well, open source software is unlikely to use Jazelle, read more thoroughly the page you've pointed


Again, there are plenty of valid reasons for working on such a project, some of them are mentioned in the first paragraph. But speed for practical matters is unlikely to be one of them.

Reo: well, open source software is unlikely to use Jazelle, read more thoroughly the page you've pointed

Obviously a non-ARM specific virtual machine wouldn't use Jazelle, we'd have to find a way to implement it ourselves.