[java-dev] dynamically loading java classes in a standalone

one more question.

how large are all of those classes before you jar them up?

it is very possible that the jar is being unzipped when the mxj  
classloader falls back on trying to locate the class in the max  
search path. as a matter of fact it is entirely possible that all  
jars in the max search path are being unzipped temporarily into  
memory ,including max.jar, since the classloader needs to crack open  
any jar file it finds in the search path to check if it contains the  
class it is looking for.

This previous point would explain the memory blowup you are seeing.  
As mentioned before, the long time it takes for instantiation would  
be due to the fact that the whole max search path is being scanned  
for each class you are loading since your jar is not in the system or  
dynamic classpath and the classloader is falling back to its last  
resort scheme for classloading.

t





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
>
> 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
>>>
>>> _______________________________________________
>>> java-dev mailing list
>>> java-dev at cycling74.com
>>> http://www.cycling74.com/mailman/listinfo/java-dev
>>
>> _______________________________________________
>> java-dev mailing list
>> java-dev at cycling74.com
>> http://www.cycling74.com/mailman/listinfo/java-dev
>
> _______________________________________________
> java-dev mailing list
> java-dev at cycling74.com
> http://www.cycling74.com/mailman/listinfo/java-dev