dhjdhjdhj

If I create multiple [mxj] objects, is there a single global JVM created or does each object get its own JVM? I would hope it's the former but just wanted to check. What if different mxj objects pull in different jar files?

If I create multiple [mxj] objects, is there a single global JVM created or does each object get its own JVM?  I would hope it's the former but just wanted to check. What if different mxj objects pull in different jar files?

one-jvm-or-many

Yes, there's one JVM in Max (or in Max for Live).

I'm not sure I understand the second question. All mxj objects share a classpath (modulo a bit of dynamic patching so that patchers can see class files in their search path at load time). The objects are differentiated by the name of the MaxObject instance they create.

Yes, there's one JVM in Max (or in Max for Live).
I'm not sure I understand the second question. All mxj objects share a classpath (modulo a bit of dynamic patching so that patchers can see class files in their search path at load time). The objects are differentiated by the name of the MaxObject instance they create.


My second question (well, really both questions) was (were) around shared data. I was concerned that if I have different jar files, each loaded by separate mxj objects and then those jar files access a third jar file to share some data, this would fail if multiple VMs were used.

My second question (well, really both questions) was (were) around shared data. I was concerned that if I have different jar files, each loaded by  separate mxj objects and then those jar files access a third jar file to share some data, this would fail if multiple VMs were used.

I'm not sure what you mean by sharing data in JAR files... Properties would be constant/static. Or do you mean using static/factory classes for sharing? If so, you might still run into problems since Max uses three (at least, I think) different class loaders. But if everything's in the same declaration in the MXJ config file (static, specifically) you should be fine.

Obviously, you need to be thread-safe...


Could be static class, could be singleton, or an instance that I want to be able to pass around.

Why is Max using three different class loaders?

I'm not such a huge fan of Java in general but it is so easy to put together some convenience stuff in Java (specially when using IntelliJ) that I'm tempted to use it to replace some complex (but non-real time) abstractions.

As I try to optimize my main app done with Max, I'm finding that a lot of nested abstractions seems to have a significant effect on load time, for example so I'm looking for ways to replace some of it.

Re: the class loaders. One is fixed when Max launches (or rather, when mxj initialises); there's a "dynamic" one which can, in theory, be reloaded while Max is running. And there's a transient classloader which kicks in when a patch is loaded, so that any class files in the search path or relative to the patcher are visible.

Or at least this is my understanding - it's been a while since I've worked at the Java language level; these days I generally target the JVM from Python or Clojure, both of which I can reload from source.

Interesting. Would you be willing to share an example or two of Clojure for Max? I've been thinking of looking into jHaskell rather than Java but I figured it would be easier to start with Java to get up to speed with the Max libraries first, particularly because IntelliJ does such a great job helping you find the right method calls

There should be plenty of examples here: 

https://github.com/cassiel/net.loadbang.clojure

 - let me know if anything doesn't make sense.

There should be plenty of examples here: https://github.com/cassiel/net.loadbang.clojure - let me know if anything doesn't make sense.


One JVM or many?