Jack, Java bytecode -> C++ [Updated to be more descriptive]

Miscellaneous Topics
#1

Jack is a silly attempt to write a Java bytecode to C++ transpiler to allow ahead of time compilation of Java apps. I intend to use it to target platforms that don’t have a JVM or other restrictions, e.g. iOS, consoles etc.

Goals:

  • Java 1.5 language compatibility
  • reflection
  • exceptions
  • covariant return types (needed for generics)
  • threading
  • JNI and a custom native interface to ease wrapping C/C++ apis.
  • minimal runtime library ala Avian VM
  • debuggable (preserve class hierarchy, field and method names, inline Java source as comments for readability)

Non-Goals:

  • run Eclipse
  • Swing/AWT/EE support
  • runtime bytecode loading
  • full java memory model

Done

  • translation of class hierarchy (that was no fun…)
  • translation of method bodies (surprisingly simple)
  • ordered class initialization (differs from JVM on the fly class initialization)
  • GC (via Boehm GC for now)
  • covariant return types
  • basic class descriptors (instanceof etc., C++ dynamic_cast doesn’t quite cut it)
  • String literals (they need special care…)
  • Arrays (since they are special case in many respects)
  • incremental compilation, so C++ compile times are quick as well.
  • compiles the first iteration of the runtime library, ~220 classes.

Todo

  • exceptions
  • full reflection support
  • threading & monitors
  • JNI & custom native interface
  • more work on the runtime library

I have a plan for each Todo and am confident that this can be realized within a reasonable time-frame.

I’d love to get input on what you guys thing the runtime library should contain at a minimum. I want to focus on things relevant to game development. The runtime can be extended later on, be it by including OpenJDK or devising custom runtime classes. I’d be in favor of keeping it simple.

Feedback welcome, if you fork it and want to contribute i’d be even happier. Note the disclaimer at the top of the README :slight_smile:

#2

Ah I have seen this before on random browsing session. Any current running/published project using this?

#3

If you wanted to use this to target a java game using JOGL or LWJGL for iOS, how would that work? I’m specifically wondering about how the graphics coding would look.

#4

Hopefully just straight LWJGL code :slight_smile: LWJGL would need a specific iOS port of course.

The higher agenda is libgdx of course but it’d have to start with a LWJGL port in the first place.

Also you’ll be needing a wrapper for touch input and some extra APIs for specific iOS functions and requirements.

Anyway, I’m looking forward to seeing what comes out of this. Hopefully a fully-compliant Java 7 core with annotations and everything all working as expected. Of particular importance to me is a binary compatible ObjectInputStream/ObjectOutputStream. Also I think you might need to ditch Boehm at some point, bite the bullet and go fully accurate compacting GC.

Cas :slight_smile:

#5

I’d just start with a naive semi-space GC and revisit if everything else more-or-less works. Real GC is a real PITA.

#6

Riven already created a nice GC implementation in Java. Thankfully he left out all the nitty gritty details, like getting registers and the stack in order on rewrites, blocking threads etc. Riven doesn’t like C++ much.

Unity uses Mono, which in turn uses either Boehm or their own sGen GC. Looks like Boehm was good enough, even on mobile.

Also, who uses Java serialization?

#7

More food for thought on GC is checking out the JikesVM source. Did I mention that this is insanely ambitious? This isn’t a project I’d attempt unless someone was throwing insane amounts of money at me.

#8

You can get surprsingly far without a vast amount of effort.

Boehm’s good enough on mobile… if you don’t rely on it working properly, which is unfortunate, because it means you practically daren’t rely on it at all. So what everyone does is make lots of pools and never allocate or deallocate anything if they can help it, which kinda makes a mockery of the way things should work in Java. Not only that but in C#, devs make heavy use of structs instead of relying on ordinary heap objects. Food for thought. Riven’s GC is a good start, algorithmically; the remaining parts of the implementation I’m sure you could mostly figure out. Don’t forget that in the context of games programming it is enough to have a GC that runs in a reliably short amount of time every single frame when System.gc() is called - so factor that into your optimisations. I’d rather have a constant 3ms spent on GC every frame than randomly getting 100ms delays. Or worse, regularly getting 100ms delays.

I use Java serialization extensively - it makes a remarkably efficient way of configuring game data without having to write anything much manually or parse stupid files at startup (==slow). It is also super-effective at managing save/load games and hibernating application state (something iOS really really really needs you to do right). That’s why you need to support it :slight_smile:

Cas :slight_smile:

#9

There are much better ways to do the same job. :yawn:

#10

Actually, no there aren’t.

Cas :slight_smile:

#11

Let’s hear it boys, Serialization is relevant to our interest.

@topic, I guess Jack is not used right now for the upcoming iOS libgdx backend ? since you guys said its almost done, only audio and something to do

#12

We are currently using.MonoTouch and IKVM. That backend is almost complete. Jack should be used for an alternative backend that won’t cost money, or at least not 400$ such as a MonoTouch license.

#13

Well I wasn’t aware that the current iOS backend would involve such a cost per developer. Obviously we dont have that kinda money, and even if we did, I would only spend that if I was sure of success…

Meaning I would wait for Jack aswell.
Besides the fact that I think every java to C++/native code attempt is good, because we already do so much to hide java and make it work without java problems (private jre and whatnot)

Btw I’m using JNA for gStreamer actually… would that work ?

#14

I’d have to look ibto JNA but my gut feeling tells me it’s doing funky things. Would you use gstreamer on iOS?

#15

Well that was just out of curiosity if I were to convert my java code to C++ for a desktop game.
Of course not needed for iOS - for that I just use libgdx features.

#16

Ahh, the sense of being valued for spending hours explaining how Jack could be implemented, explaining GC strategies and writing a mockup implementation, currently met with a mixture of sarcasm, insinuations and compliments, never really wears off. It’s a gift, really, to deal with that emotionally. I’m awesome like that!

#17

you are my butt buddy!

#18

This must be some new internet slang for an ersatz homosexual co-dependent abusive relationship.

I shall patiently wait until Titan Attacks runs in native code and then rejoice.

Cas :slight_smile:

#19

Cas, I think Nate was subtly hinting that Kryo could do a better job than plain old Java Serialization ;D

NO HE’S MINE! >:(

#20

Ahh I didn’t make the connection.
I’m sure Kryo’s great, it’s just not as simple as … implements Serializable { …

Cas :slight_smile:

Serialization by various means