dynamically loading java classes in a standalone

On Feb 21, 2008, at 14:01 PM, Brad Garton wrote:

> I am guessing at behavior I don't understand. What is the
> difference between the 'immutable classpath" and the "dynamic
> classpath". I have a jar file that's about 6 Mbtyes, and inflates
> to about 30 Mbytes. If I put it on the system (immutable)
> classpath or just put it into one of the java classes/ or lib/
> subdirs, it takes about a minute to instantiate the object that
> references a class in that jar. I can watch the memory usage
> slowly creep up to about 30 Mbytes from the starting point as
> apparently all of the classes are being loaded and inflated in memory

The system classpath is the normal java classpath which is specified
to the vm at startup. java -classpath C:/blah/blah etc.Once the vm is
started it can't be changed. This relates to the security of the vm.
The only way you can add a new class to the vm at runtime is by using
a custom classloader.

The dynamic classpath is a construct we came up with so that classes
could be reloaded by the mxj classloader (our custom classloader) so
you don't have to quit and start max everytime you change a class
definition. This is useful during the development phase of an mxj class.

Thus, any class that you want to reload dynamically after its
definition changes needs to be in the dynamic classpath.For a
standalone the classes won't really be changing so you should put
your jar in:

my.app/Contents/support/java/lib/

alongside max.jar and see if that helps.

The only reason that your code is working at all in the standalone is
because as a last resort max will search the whole max search path
for classes and jars it cannot find in the classpath. This would
explain why it takes such a long time for your classes in the jar to
load. The fact that the memory is increasing suggests that there may
be a memory leak when max resorts to scanning the whole max search
path for a class.

It is not finding your jar in the classes directory since that
directory is only for classes not jar files. However it is finding
the classes in your jar file when it resorts to the full max searchpath.

The c74/classes folder is by default part of the dynamic search path.
We do not have a default dynamic jar path but one can be specified in
max.java.config.txt.

I am not sure how this plays out in a standalone since I am not sure
how to specify a relative path to a dynamic jar directory in the
context of a standalone. It would probably have to be relative to the
max executable itself.

In theory you could specify in max.java.config.txt these relative
paths for any dynamic class and/or dynamic jar directories and
included that max.java.config.txt in your standalone.It is just a
question of finding out what they should be specified relative to
which as i said above is probably the max executable itself.

So to make a long story short.

try moving your jar to the same directory as max.jar and see if your
standalone behaves as expected.

t

> If, however, I explicitly put the jar itself on the "dynamic
> classpath" then the object that draws on that jar load immediately
> with no huge memory allocation. I don't know what is causing the
> different behaviors. I assumed it had to do with how the JVM was
> loading the classes in the jar.
>
> Also, if I unpack the jar into all the separate classes in the
> classes/ dir, it acts like when I add the jar to the "dynamic
> classpath"; i.e. it loads quickly.
>
> brad
>
>
> On Feb 21, 2008, at 3:44 PM, topher lafata wrote:
>
>> I don't really understand what you mean by saying that your entire
>> jar is being loaded at startup. If you have any mxj instances in
>> your standalone patch they should only load the classes that they
>> have dependencies on. I am not aware of a way to get the JVM to
>> force load a bunch of arbitrary classes.It loads any class when it
>> needs it with the exception of the bootstrap classes.
>>
>> Regardless. I am not totally sure but if you include
>> max.java.config.txt it is possible that mxj will find it. You
>> might want to mess around with this.
>> In the case that it does find it you will need to mess around with
>> paths for the max.dynamic.jar.dir, max.dynamic.class.dir etc since
>> they will need to be
>> relative and I am not sure what they would be relative to.
>>
>> Sorry I can't be more helpful.
>>
>> t
>>
>> On Feb 21, 2008, at 10:51 AM, Brad Garton wrote:
>>
>>> Hey gang --
>>>
>>> I'm building some standalones (Max 4.6.3, OSX 10.4.11, 2 GHz
>>> Intel MacBook), and I can get things to work by putting the
>>> max.jar file in "my.app/Contents/support/java/lib/". Now I have
>>> a large jar file, and I put it in "my.app/Contents/support/java/
>>> classes/". The problem is that the standalone is treating the
>>> jar file as a system jar and loading the entire thing into memory
>>> at start-up. I want to add the jar to the dynamic classpath so
>>> that it will only load the classes I need from the jar.
>>>
>>> I do this when running MaxMSP by setting the
>>> "max.dynamic.class.dir" in the "max.java.config.txt" to point to
>>> the large jar file. How can I set the dynamic classpath in a
>>> standalone?
>>>
>>> thanks!
>>>
>>> brad
>>>
>>
>