Feasibility of using Julia to create a DLL connected to Java

Compiling Julia is possible, and you end with a DLL, it’s not going to be small, but I question why you need that, and I think you will not get just one DLL with PackageCompiler.jl. Also it you think compiling to DLL or anything is needed for speed then that’s not true basically, and since this is a physics engine, it seem like soft-realtime, and that has special requirements, I’ll address lalter.

Certainly. Look at e.g. the PythonCall.jl project. It’s by-directional, i.e. ses it’s [py]juliacall.

But that and RCall.jl and such a project to call in the other direction, to call Julia, are not made for compiling the Julia code first to a DLL. Though I do not think it’s ruled out using those projects if you’ve already done that.

I would first as a prototype just try to use Julia from Java without thinking of a DLL, to see if it’s fast enough, and you like the language. Julia should be, can be, as fast as anything out there if you do things right.

See the discussion here/first post at least and my answer, in short, it’s not just for statistics or just from e.g. Stata:

I’ve not tried this, but it at least exists:

FYI: This is an older package:

You can call C from Java, and from C the C API, i.e. that way, or with projects helping, that in effect do this for you.

If it helps you and you can call C++ from Java (I’m sure you can) then it may be better to call Julia from it with, a project I’ve great confidence in/well documented:

The C API to Julia handles only basic types, one reason I point to the above C++ project, it relates to:

It’s also an option to call Python, and with the project above to Julia, in case it’s more mature then the other projects above.

The problem with mixing Java, a GC-language with another GC-language, such as Julia or Python, is that which GC should work (or both?). Java has good real-time GC available, Julia does not, so for a soft (or hard) real-time project you want to eliminate GC activity, meaning heap-allocations from the, or if soft-realtime, at least limit it. Though you may tolerate the Julia GC activity. In Julia instead of having a very good garbage collector for real-time, you rather want to eliminate the need for GC, and that’s a good approach, e.g. for robotics, but then you have to be careful. One project might help, it’s a bit limited yet, e.g. doesn’t support the GC, but for you it might be a plus: StaticCompiler.jl