Looks good to me.

I want to merge the pd-for-android piece (libpd/pd-for-android#167) now in order to create a 1.4.0-SNAPSHOT, and it refs this commit.

When to merge this?

Just to check: As this touches the Java wrapper, are there any changes to Java on desktop? Does it still build for "normal" Java?

yes, normal java still builds (on my machine).
I have added 3 new methods to PdBase API, but I filled empty corresponding functions in the various jni sources.

Of course, this is a breaking change for external users, if they use their own jni: they will have to add these new functions too, unless the app won't link.

Wow. This looks great! Unfortunately, due to family matters, I can't look into it in detail right now, but as soon as I have time, I'll definitely try it myself. Thank you so much!

When do we plan to merge this?

@danomatika I defer to you wrt merging this.

It would be good to have someone who uses libpd with Java desktop to check. I haven't done a Java build in a long time.

javalib, javasrc and javadoc all build without error here (btw, I imagine they could easily be added to CI?).

I would like to test the Java samples on desktop, unfortunately there's nothing about it in the docs, and I haven't been able to figure it out on my own.

Would someone know how to run the Java samples on desktop, via commandline (without using Eclipse)?

I'm now thinking that another solution might be better, that would imply less change in the Java API, maybe no change at all actually.
PdBase.openAudio() already provides a Map<String, String> options argument, which could be used to pass specific options to the native implementation, instead of adding new jni functions for setting the device ids or the buffer size.

I'm investigating this solution, I'm switching this to 'draft' in the mean time.

I don't think you need to change your approach, I just wanted to know that someone had checked that the desktop Java still builds ok. Are the new functions applicable to Android only? If so, why not wrap them in defines etc so they are available on Android only. If accepting new key/value controls works when opening audio, perhaps that's nicer. I defer to those using the Java API to decide but I always prefer if whatever is changed tries to stay consistent with the current design, naming, usage etc.

stay consistent with the current design

I agree, that's why I think the new version #423 is better. It doesn't change the Java API, reusing an already existing possibility. I just should have thought of it before :-)

closing this in favor of #423