I've been developing mxj externals in eclipse and I recently upgraded from 6.1.6 to 6.1.7. Now it seems as though zap() no longer works to reload java classes after making changes. I have a call to zap() in my mxj external's constructor, and I'm reloading mxj by deleting the mxj external and immediately undoing the delete. I've been using it this way for the last month, or so, without problems, but now it no longer works. The only way I can see the effect of changes made in eclipse is by quitting and relaunching Max. Has something changed recently?

has-zap-been-zapped-in-6-1-7

I've noticed that even at the level of the mxj object (i.e., not classes loaded by the mxj) the old technique of deleting and undoing the delete no longer works to reload classes. Anybody know why this is? Is something being cached somewhere perhaps? It's really tedious having to quit and relaunch Max all the time.

Just re-read your post... not sure why this would not work.

Just re-read your post...  not sure why this would not work.


Thanks for the reply. But as I said in my original post, delete/undo no longer works. It used to, but not since upgrading to 6.1.7. The Java code is the same. Now I have to relaunch. Strange... I deleted Max's cache (~/library/caches), but that didn't make any difference. Could there be some weird situation in which the JVM is caching the classes until Max quits? Don't know if that could happen, but I don't get what could have changed.

...heh... okay, just saw that you re-read...

...heh... okay, just saw that you re-read...
yeah, I'm stumped.


hi, could you please send me some Java example where it does not work the way you expect it to do (if you want to send it offlist, then just send it to support@cycling74.com and mention that it should be forwarded to me) and i can have a look at it

Thanks Stefan. I'll put something together and send it off-list.

thanks for sending me the clear example (off list) - what i tried is:

- open you example - click the message - i get the expected answer

- changed the line you mentioned in your java class

- opened the compile window (there seems to be a problem which is noted now, i had to click the menu entry a second time)

- added the directory where i unpacked the stuff to my classpath

- sent the message - the expected old answer

- delete/undo -> sent the message - the new message (with the print i just un-commented) --> which is i think what you would want/expect

if you use the steps above, does it work for you, too ?

tested with Max 6.1.7 - 32 & 64 bit on Mac OS X 10.9.2

- open you example - click the message - i get the expected answer
- then i sent the mxj a "viewsource"
- changed the line you mentioned in your java class
- opened the compile window (there seems to be a problem which is noted now, i had to click the menu entry a second time)
- added the directory where i unpacked the stuff to my classpath
- re-compiled the stuff

tested with Max 6.1.7 - 32 & 64 bit on Mac OS X 10.9.2


Well, I guess the only real difference is that I’m working in Eclipse, though I’m not sure why that would change things…

Using the example I sent, if I comment/uncomment in Eclipse, then delete/undo in Max, the change does not take effect. I have to quit/relaunch Max to see the change.

This was not the case previously, as I have been working in Eclipse for several months, and delete/undo always worked as expected. Unfortunately, working in mxj's text editor/compiler really isn't a viable alternative to Eclipse for me...

The only other thing I can think of, which I had forgotten about when I posted originally, is that I did update Java around the same time I updated Max. My current version is Java 7 update 55 (build 1.7.0_55-b13). Are there any known problems with the latest Java and mxj?

(btw, I'm also on Max 6.1.7, Mac OS X 10.9.2)

Well, I guess the only real difference is that I’m working in Eclipse, though I’m not sure why that would change things…
Using the example I sent, if I comment/uncomment in Eclipse, then delete/undo in Max, the change does not take effect. I have to quit/relaunch Max to see the change.

(btw, I'm also on Max 6.1.7, Mac OS X 10.9.2)


Oracle Java RE is not currently supported for Mac. You will need to install Java for OS X, provided by Apple:

http://support.apple.com/kb/DL1572?viewlocale=en_US

Oracle Java RE is not currently supported for Mac. You will need to install Java for OS X, provided by Apple:
http://support.apple.com/kb/DL1572?viewlocale=en_US


Ah, okay. I think some Java updater opened up at one point, and I decided to upgrade (against my better judgement... I usually ignore update windows that pop-up on my machine—e.g., Adobe). I'll revert back to whatever version Apple is offering.

Okay, reverted back to version 6 (java -version shows: java version "1.6.0_65"). No luck. Same problem. Besides that, Eclipse was set to use 1.6 in the project settings (as was Max, actually), so I'm not sure it ever touched 1.7 anyway. There also seem to be many people running Java 1.7 on 10.9.2 in the wild... In fact, loads of people are recommending not to use 1.6 at all, since it's said to be a security problem. Don't know. Don't particularly care. Just want to get Max/Eclipse/mxj and the wonderful old delete/undo workflow back!

For the sake of being thorough I tried it using mxj's built-in text editor/compiler, but no luck.

Is there anything else you'd recommend I try, Stefan? Any other possible explanation of this behaviour that you can think of?... Or even some kind of explanation as to what the difference might be between delete/undo and quit/relaunch? If I understood better what Max is doing, with regard to mxj, in each of those cases, maybe I could track down some other root cause for this problem.

i'll try this on windows tonight to see if behaviour has changed - not had chance this week

Has zap() been zapped in 6.1.7?