Use Service Provider Interfaces to load synths

[danielappelt]

This simplifies writing synth editors in other JVM languages than Java by extracting concrecte names of implementation classes from edisyn.Synth into a configuration file. In theory, this should also allow the distribution of synth editor implementations independently from the main program.

I am currently writing an edisyn editor in Clojure. The fact that you have to put the concrete class name of the implementing class into its super class does not play very well in this scenario as edisyn (Java) and the concrete implementation (Clojure) are always compiled in separate steps.

For the proposed change concrete class names are put into configuration file META-INF/services/edisyn.Synth. The file is not (yet) part of this pull request as I am not sure where it would need to go in order to be compatible with your build system. For an example, see the file my repository.

The implementation uses Java service provider interfaces as they are part of standard Java. Please be aware that this raises the minimum Java version required to run edisyn to Java version 9 as only of this version access to service providers is possible without directly instantiating them.

Implementing this feature using another (third-party) factory implementation could avoid raising the minimum Java version but would most probably need more effort at another end.

[eclab]

This is long overdue. I've got code up and running which loads classes from class names specified in a file called Synth.txt using Class.forName(). Very easy. HOWEVER I'm not quite ready to release the new Synth.java file, as it's going to come with some new synthesizers (JV-880 and CZ series) and the CZ series isn't ready yet. :-( Maybe I could post it just with the JV-880 for the time being.

What editor are you working on?

Adding a clojure jar file to Edisyn may be nontrivial.

On Apr 14, 2019, at 4:59 PM, Daniel Appelt [email protected] wrote:

This simplifies writing synth editors in other JVM languages than Java by extracting concrecte names of implementation classes from edisyn.Synth into a configuration file. In theory, this should also allow the distribution of synth editor implementations independently from the main program.

I am currently writing an edisyn editor in Clojure. The fact that you have to put the concrete class name of the implementing class into its super class does not play very well in this scenario as edisyn (Java) and the concrete implementation (Clojure) are always compiled in separate steps.

For the proposed change concrete class names are put into configuration file META-INF/services/edisyn.Synth. The file is not (yet) part of this pull request as I am not sure where it would need to go in order to be compatible with your build system. For an example, see the file my repository.

The implementation uses Java service provider interfaces as they are part of standard Java. Please be aware that this raises the minimum Java version required to run edisyn to Java version 9 as only of this version access to service providers is possible without directly instantiating them.

Implementing this feature using another (third-party) factory implementation could avoid raising the minimum Java version but would most probably need more effort at another end.

You can view, comment on, or merge this pull request online at:

https://github.com/eclab/edisyn/pull/12

Commit Summary

• Use Service Provider Interfaces to load synths File Changes

• M edisyn/Synth.java (38) Patch Links:

• https://github.com/eclab/edisyn/pull/12.patch • https://github.com/eclab/edisyn/pull/12.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[danielappelt]

Thanks for the heads up! It's an editor for the Arturia Beatstep (MIDI controller). Please note that it's possible that you need to check github directly as not all links seem to be forwarded by mail.

I have just released a JAR including the current state of the editor next to edisyn. The JAR can be created using a simple leiningen task - getting the task configuration right took quite some time though.

Still, I can imagine that it is not desirable to add extra run time dependencies in the official edisyn release for just one editor. Therefore, I was hoping that using the factory design pattern would also allow having (unofficial) editor implementations loaded from separate JARs. Using SPI this should in theory be possible.

I am looking forward to see your approach. No hurry needed from my side!