Hanging on CoreMidiDeviceProvider.getMidiDeviceInfo() with Java Modules / CoreMidiDeviceProvider.getLibraryVersion() returns <null>

[leomekenkamp]

Hi. Using CoreMidi4J in a Java Jigsaw / JSR 376 / Modules application I have run into inconsistent hanging issues. My application would hang on the call to CoreMidiDeviceProvider.getMidiDeviceInfo() most of the times but not always. When running under the NetBeans debugger the call would always return normally.

For now I am instantiating a CoreMidiDeviceProvider instance before calling getMidiDeviceInfo(). That somehow seems to 'fix' things: I have yet to see my app hanging after explicitly constructing a CoreMidiDeviceProvider instance.

Strangely enough, even with this 'fix' in place CoreMidiDeviceProvider.getLibraryVersion() always returns and CoreMidiDeviceProvider.isLibraryLoaded() always returns yes. Before the 'fix' I would also see for the version without instantiating a provider instance.

I am inclined to think that this all has something to do with Java Modules, because in unit tests (running 'outside' of the module system) I never see getMidiDeviceInfo() hanging. And getLibraryVersion() returns "1.6" inside unit tests.

Currently running under Temurin 21.0.4. 21.0.3 gave the same results. Any idea on what causes this unexpected behaviour?

[brunchboy]

Sorry, I doubt anyone is going to have any insight about this, but I am concerned about those downloads @JONTY650413 posted, they seem likely to be malware, should we delete them?

[brunchboy]

Since I saw similar spam come in from another user, I am deleting them for safety. If there is a legitimate explanation for these links, please spell out the details. For now it looks like a spam bot campaign trying to use GitHub comments as a vector for malware.

[DerekCook]

Hi. Been out all day in the garden, so only now catching up.

I would say the clue is in what you have already reported, and this is possibly an issue with J21 and the module structure.

I am afraid I am a Luddite on Tenurim J17 LTS for which COREMIDI4J which is working fine, and I still have not migrated any of my (very legacy) code to the module structure, as I see no benefit in doing so.

James, thanks for deletng those suspicious posts. I had the same feeling about them.

[brunchboy]

Indeed: https://socket.dev/blog/github-users-targeted-by-new-wave-of-spambots-promoting-malicious-downloads

[DerekCook]

Good spot!

[leomekenkamp]

Hi. Been out all day in the garden, so only now catching up.

Ah, make Monty Don proud!

I would say the clue is in what you have already reported, and this is possibly an issue with J21 and the module structure.

I am afraid I am a Luddite on Tenurim J17 LTS for which COREMIDI4J which is working fine, and I still have not migrated any of my (very legacy) code to the module structure, as I see no benefit in doing so.

Ok. Well, at least there is a simple workaround and it is described above, so ppl running into the same issue might stumble upon this thread and find it.

What is the project way of handling issues like this? Keep it open, 'close as completed' or 'close as not planned'?

[brunchboy]

This is primarily Derek’s project, so I’ll let him make the judgement there; my own leaning would be to leave it open for now to make it easier for people to spot the workaround; if we do close it I’d lean towards “not planned.” But I also wonder if there is a way we could find a minimal reproduction case to submit as a bug to the OpenJDK project, because this really feels like a bug there rather than with CoreMidi4J to me. And indeed perhaps even without doing that we may find the problem goes away in a future update to Java, since it is supposed to be backwards compatible.

[DerekCook]

I think a reproducible case would help in the reporting of this

[leomekenkamp]

Sure, I will set one up when time permits.