Questions re Additional Java Files

[AndyMac]

I am wanting to modularise my modules to better share utility code. Much of what I want to do (probably showing my lack of Java skills) I have now worked out after some trial and error - but can't seem to work out how to access some methods in the VoltageModule class - specifically Log, LogError and ShowMessageBox. They always come up with "cannot find symbol". Is it possible to put these into a shared class for such utilities?

[andro]

Hi Andrew,

Probably you need this is your Java files:

import voltage.core.*;

Works for me.

Incidentally. I just upgraded from Java SE 1.8 for MD to Java SE 14. I found that the Oracle distro just gives blank gray panels, but the OpenJDK version 14 works fine. This is of course as per the instructions, but it's interesting to see a difference (though unexpected).

[AndyMac]

Thanks - I'd already got this in. It looks like Log and LogError have been changed from static (in v1) to non-static (in v2) and the static versions deprecated. ShowMessageBox does not look like it was ever static. Any other thoughts?

[andro]

I'll take a look.

[AndyMac]

Thank you

[andro]

Aha. VoltageModule is an abstract class, so the module you are making extends it. I have code in other java files, and you cant call a method in an abstract class, so none of the methods such as Log() or any of them are going to work, unless the file has a class that extends VoltageModule - but that's ridiculous.

I think we are snookered. This would mean that it is a large shortcoming of MD that you have to put everything in the one class. I don't like that.

Cherry Audio, help us out here please.

[AndyMac]

I was coming to the same conclusion (but you have explained it really well here). I can do a workaround in these cases by making the shared code return information that the main code in the module can deal with - not ideal, but I can move 95%+ of the code that I want to make shared to ensure consistency into my own classes, and just have some small stub code in the main modules - easy enough to maintain, but not ideal (but at least allows me to progress with the refactoring).

As to why... it may well be that some of this is around design decisions taken to ensure the performance of the environment at the cost of the "purity" of the coding model... but it is certainly an area where some more documentation for developers would probably be welcome - for example, providing a list of what Voltage Modular methods can be used in external code vs which ones have to be in the main class.

[andro]

So we would have to use normal Java logging in our extra Java files. Hmm.

[andro]

Logging to disk probably kills audio sample processing. Maybe it's not a good idea for production work anyway, thinking about it.

[AndyMac]

The logging was very specific logging for some activities I have when the module opens (Initialisation stage) to deal with some configuration stuff - so does not happen when any real audio processing going on - but agree, in normal situations, this would not be something you would do except for debugging.