I recently heard it's possible to compile Java 1.5 to native code for Windows and Linux (Jnc: http://jnc.mtsystems.ch/)

And that it even works fairly well.

Has anyone tried compiling any sketches with it? It seems like it would be fantastic for performance hungry OpenGL sketches, deployment purposes and even game dev with processing.

I'm going to try to see if it's even possible over the next couple days, but I figured I'd ask if anyone already had positive results. (Nothing came up in the few searches I did)

Jack

Thanks PhiLho for your thoughts!

I think that all makes a lot of sense. The startup times are somewhat annoying though, though I suppose just popping up a quick spash screen with a launcher like processing does is a nice way to show response while the jvm starts. Or maybe have the windows installer register the jvm as a service, but that kindof makes me cringe a little.

I wasn't able to get it to compile the core.jar successfully, so I got blocked there. I probably need to try an older version of processing that is 1.5 compatible?

I also just found Excelsior JET which also has an AOT compiler that looks like it's even currently supported (yet also commercial)

If I get it working I'll try to do some benchmarks and post my results.

Jack

Well, Excelsior JET at least seems to work!

So far in the one test I did (just taking a particle system I wrote and checking the FPS in both cases) Excelsior JET created equal or worse frame rates.

But I'm not sure what caused it because I don't have a profiler and I didn't take the time to check out where the time is actually being spent yet (just using timers).

The code I was testing used OpenGL, so that has to go through JNI somewhere, and it updates FloatBuffer/DoubleBuffer/IntBuffer objects every frame so it can use glDrawElements/glDrawArrays calls. If I had to guess I'd think that could be the problem.

Also, I try to stay away from object allocations in the main loop as much as possible, but I suppose it still could be a difference in the memory manager. I'm really grasping at straws without hard data though.

I'll want to do some tests of static scenes with scripted camera paths and log the fps for comparison. Also, I didn't enable total program optimization, because of the long compile times (which really doesn't matter if it only needs to be built once before release) But I should test that to see if it helps at all. It sounded like that was more for just stripping out code that isn't used over real speed gains.

Any other thoughts on better ways to test the two? I haven't lost hope yet!

Jack

Dmitry, Processing does a pre-processing (sic) pass on the code, to add a base class around it, to add imports, to add 'f' after numbers with decimal points, to convert #BAD8AA to 0xFFBAD8AA and so on.
So it generates a .java file in your temp dir, and then just compiles it with the regular Java compiler. Then, as you found out, the PDE runs the generated class(es) files in a separate process.

Now, you can also ask the PDE to export the sketch to HTML (a jar and an HTML page) or to an exe (light wrapper, actually).
The jar seems to be a good candidate for bytecode post processing.

Note that some people also just use Eclipse (or NetBeans, etc.) to write sketches, using Processing (core.jar and some others) as a simple library (but loosing some syntax facilities).