What about a jvm for bge/blender scripting?

Ok, in the middle of a model crisis, I took some time to relax with the source code of blender.
Has anyone ever thought about the possibility to replace the python interpreter with a java virtual machine.
It may seem a bit exaggerated at first to carry around an openjre but one nice side effect is that by developing one C++/Java bridge, “scripters” would be able to develop plugins and - for what i’m interested in - game logic using one of the many languages that currently run on the jvm.
It’s really an entire world of different languages (java, scala, javascript, python, groovy, kotlin, ruby… and the list goes on forever) that would open by “simply” creating the interface.
There is a standard native interface to link the native world to the jvm one, the underlying technology is old and reliable, it’s gpl too.
It is a long, boring task but it is not a particularly hard one.
The worst thing I can see is that, because the basic API would change, all the python scripts that are currently working would have to be rewritten. They would still be written in python but as an optional language among many.
Any thoughts?

I think what you’ll find is that many developers, including myself, would not want to change the API. People don’t want things to change.

That’s… not true. People love change, including developers, if it’s a change for the better.
I’m not sure if this would be a change for the better though.
I mean, I have no problem with the current python api, but I look at the multilanguage support of platforms like Unity as a nice feature.

I don’t see the need for a virtual machine. Ultimately, one would still need to rewrite all of the access methods that link into python. In fact, it would be very hard to access game data without writing an API for every single language. Even with this it would require a complicated API to expose the data from C++ in a manner that supports all languages.
Lastly, it’s not needed. You’d have a far greater challenge In maintaining api for more than one scripting language

Sent from my Nexus 5 using Tapatalk

I don’t want to look like I’m supporting this idea to the last resort, it’s just a random thought and i’m glad to read your replies but that’s no true either. You would effectively write and maintain one and only one API (namely a single set of java classes backed by their c++ counterparts) for all the languages, with absolutely no need to change a single character because of a potentially different user language. It’s not magic, it works because jvm languages either an embedded scripting interface or they exploit the fact that all jvm languages compile to the same set of bytecode instructions.

I think that while you’re at it you might as well make it capable of exporting to html5 and flash… In other words, you may as well create a new engine.

Im for it, since python is not easy to get into android, isn’t it? What about using mono?

If I was going to rewrite the scripting interface, I’d rather target Mono than the JVM. However, this isn’t something I’d want to spend our limited development resources on.

I’m not aware of this, essentially you’d require a shared memory state and to run two programs on the vm simultaneously, with one instance considered the host.

Sent from my Nexus 5 using Tapatalk

Looking at the blender code and the intricacies of the its modules I would discard the idea of replacing the script interface, it would be probably more realistic to add a second interface and let the two coexist until the older one can be put in “deprecated” state and removed much later on.

More or less, yes. For the blender to vm part it’s all about starting the vm at some point during the blender (or blender game engine) initialization. At that point you have the virtual machine running in the memory space of the blender process and the “only” thing to do is to pass data back and forth.
The variety of languages supported by the vm can recognize each other because in the end they all have to be stripped down to the virtual machine code so there is not a second vm but only one that apparently runs code written in different ways but in truth it executes the only existing bytecode language.

I’m away of how a vm works, but you’d need to essentially map memory between languages so they know “what” is what, which is the technical hurdle

Sent from my Nexus 5 using Tapatalk

I suspect we’re talking about different things because the multiple language support I’m referring to doesn’t require any memory manipulation.

Well, it does. You are accessing the same information about objects from the vm. The vm is just an interface. The languages that depend upon it will need to know which memory address correspond to which datum, and so on.

Sent from my Nexus 5 using Tapatalk

I really have this strong feeling that we’re talking like “How’s the weather? December the 12th”.
The languages for the vm X are translated into vm X code, there is no more need for memory awareness than there would be for two different parts of the same program, written in a single language. You might have to know how the vm internal works when you write the language implementation for the vm but we’re talking about using existing languages, not adding a vm then writing the languages we would like to have.

Ah, are you considering embedding the vm from c++

With respect to my point, yes the memory is accessible, but you need to know what is where.

In theory, I think the JVM can be used to drive C++ apps.

You could have a single set of Java functions to make the relevant BGE calls, and you could call those functions from other JVM languages, via the FFI they usually provide.

But, I’m pretty sure the implementation would be far from easy … It would probably be easier to streamline the existing Python system, to provide more flexibility (not that we have the “developer resources/expertise” to do either, but if we did, a focus on Python would be more likely to produce meaningful results).

I think we can all agree that, because the current script layer works well enough, adding a second one could have a priority just a bit lower than “change the orange color of the blender icon to a slightly darker orange”.
My current, small, experiments led me to conclude that embedding the jvm is not a problem at all.
I have “design” issues, mostly because my knowledge of dynamic libraries usage is vague at best.

“I think we can all agree…”. Please don’t speak for the world.

I couldn’t help replying to this (it’s a rare event, trust me).

I think it would make perfect sense to have a java api, instead of java. And I believe it’s not that hard to do. And I’m sure plenty of people have done it. One of them being http://cgchan.com/suicidator/. If you download it, you’ll see it has a “smallish” python bridge between python and the java implementation of suicidator, sitting in SCG.jar, and the other jars included in the package. I’m just looking for an open source implementation of this other than hacking the code and try to reverse engineer what they’ve done.