Matthew Aidekman

Turns out any supporting MXJ classes in the same folder with your patch That includes java classes, and abstractions.

mxj-bug-stated-with-sanity

Matthew Aidekman wrote on Mon, 20 July 2009 17:30

Errrr....Is there a verb in this note, somewhere?

Another classpath issue, perhaps? Java Virtual Machines need to know where the classes one is calling are to be found, especially when they are not in a standard library place (when the path to the code is not in the JVM's "classpath")..

Matthew Aidekman wrote on Mon, 20 July 2009 17:30Turns out any supporting MXJ classes in the same folder with your patch That includes java classes, and abstractions.

What is the issue, precisely? 
Another classpath issue, perhaps? Java Virtual Machines need to know where the classes one is calling are to be found, especially when they are not in a standard library place (when the path to the code is not in the JVM's "classpath")..
is this the issue?

The situation is that I keep my classes in the same folder with my maxpat file.

If I open my maxpat file, mxj starts fine, but then if I open a different maxpat file in another place somewhere, my mxj no longer sees any of the supporting classes and I get a ton of errors.

the work around is keeping a dummy file in the same folder which you can open before continuing to work.

This sounds like normal behavior. It's a matter of managing your classpaths and it seems you should perhaps reconsider how you want Max to find your java classes.

What I typically do while writing mxj code is to add my project's build directory to Max's java class path via the max.dynamic.class.dir setting in the max.java.config.txt file. Otherwise, if I'm installing someone else's mxj stuff or distributing my own, I pack it up in a jar and add it to Cycling '74/java/lib. Alternately I think you could put class files under Cycling '74/java/classes, but I tend to reserve that for the mxj code that C74 distributes with Max. It's easier to keep track of a few jar files than a ton of individual class files, especially if your code gets broken up into multiple files.

Anyway, the point is if you put your java code in one of these standard places where Max can always find it, you no longer need to worry about whether the class file is in the same folder as your max patch.

Wow. I guess keeping multiple versions of anything is dead in the water... Hrm...

Wow.  I guess keeping multiple versions of anything is dead in the water...  Hrm...


Matthew Aidekman wrote on Thu, 30 July 2009 22:14

Hmmm. If you really need multiple versions, I guess you could try to keep doing things the way you have been and workaround your issue with the dummy patch or whatever you were doing.

But you are asking for trouble if you ever need multiple versions of some Java classes running simultaneously in one Max session. My understanding is that there is one global class loader for Max, so say you have some java class MyMaxObject, and you have two different versions of a class with that name in different folders. I'm not positive but I think whichever one gets loaded first will be the one used by your other patches too (does anyone know? I don't feel like testing that myself right now)

If you need multiple versions running simultaneously, I'd suggest you put you java code in a package with a version number in it. Like I release my java code in an 'ajm' package to avoid conflicts with other people's code. If I needed to, I could potentially introduce packages like 'ajm1', 'ajm2', etc, and keep track of the different versions of my code that way. Make sense? Definitely a hassle, but doable and should avoid unpleasant surprises.

Versioning is always tricky. I think most people try to maintain backward compatibility and only keep the latest version around. If you're going to break backward compatibility, then that seems like a valid reason to introduce a name change like I'm suggesting.

Matthew Aidekman wrote on Thu, 30 July 2009 22:14Wow.  I guess keeping multiple versions of anything is dead in the water...  Hrm...  

Versioning is always tricky. I think most people try to maintain backward compatibility and only keep the latest version around. If you're going to break backward compatibility, then that seems like a valid reason to introduce a name change like I'm suggesting.


Versioning is always tricky. I think most people try to maintain backward compatibility and only keep the latest version around.

This is why I recommend setting up a version control system of some sort: the developer's FRIEND!!

Look up GIT or SUBVERSION....or even CVS... these can be life savers, ESPECIALLY with Java versioning...you haver only the latest available to the javac and jvm, but have the ability to "fall back" to earlier code at any time...

 If you're going to break backward compatibility, then that seems like a valid reason to introduce a name change like I'm suggesting.

It's a clear reason to do a slight reneame to the object: adding a coupla characters , or a version number to a class name can be very clarifiying when going through forgotten code.... NoteColorFileController.java and NotesColorStreamingController.java

may do exactly equivalent things, but their file names makes it clear that they are using differing internal methods to implement the action... 

Quote:Versioning is always tricky. I think most people try to maintain backward compatibility and only keep the latest version around.

This is why I recommend setting up a version control system of some sort: the developer's FRIEND!!
Look up GIT or SUBVERSION....or even CVS... these can be life savers, ESPECIALLY with Java versioning...you haver only the latest available to the javac and jvm, but have the ability to "fall back" to earlier code at any time...

Quote: If you're going to break backward compatibility, then that seems like a valid reason to introduce a name change like I'm suggesting.

It's a clear reason to do a slight reneame to the object: adding a coupla characters , or a version number to a class name can be very clarifiying when going through forgotten code....  NoteColorFileController.java and NotesColorStreamingController.java
 may do exactly equivalent things, but their file names makes it clear that they are using differing internal methods to implement the action... 
just mah 2 cents,
l&k
charlie


MXJ Bug (stated with sanity