Declaring a plugin dependency on SerialPortMonitor plugin, does not allow access to its JsscSerialService, is there a solution?
I am trying to make my Arduino Support plugin share the JsscSerialService from SerialPortMonitor plugin. I tried both optional dependency and non-optional dependency. If the SerialPortMonitor plugin is installed I get Illegal Access when trying to instantiate the service, complaining that the JsscSerialService class is loaded by different class loader than the class trying to instantiate it in CLion.
The dependency is recognized by the IDE because if SerialPortMonitor is not installed my plugin shows as needing it, if dependency is not optional.
Is there something else that needs to be done on the SerialPortMonitor side to allow its serial service to be shared by other plugins?
I am trying to avoid having the plugins conflict on the common jssc library for serial port communicaitons. What I did was create a separate plugin with a clone of the JsscSerialService. I can use this plugin's JsscSerialService from Arduino Support as a service by declaring a dependency on it. I have the SimpleSerialPortService plugin, optionally depend on Serial Port Monitor. If it is installed, then the SimpleSerialPortService plugin delegates all service calls to SerialPortMonitor's service. That way my Arduino Support plugin, or any other that uses SimpleSerialPortService plugin, would work with or without Serial Port Monitor and at the same time not conflict with it, if it is installed.
All I am missing is the ability to instantiate the service through ApplicationManager.getApplication().getService() or through JsscSerialService.getInstance().
In both cases I get:
java.lang.IllegalAccessError: failed to access class com.intellij.plugins.serialmonitor.service.JsscSerialService from class com.vladsch.plugins.simpleserialportservice.JsscSerialServiceDelegate (com.intellij.plugins.serialmonitor.service.JsscSerialService is in unnamed module of loader com.intellij.ide.plugins.cl.PluginClassLoader @24eb424c; com.vladsch.plugins.simpleserialportservice.JsscSerialServiceDelegate is in unnamed module of loader com.intellij.ide.plugins.cl.PluginClassLoader @20441121)
Please sign in to leave a comment.
Hello, Vladimir,
Thanks for your efforts. The idea sounds interesting.
Can you, please, make a ticket in CLion's youtrack , set the subsystem as "embedded" and attach your desired serial service interface?
I'll have a look what could be done.
Illia, I'll open an issue on CLion's youtrack but I don't think it is only CLion that is affected. Serial Port Monitor can be used in other IDEs.
I already reworked my plugin to use a clone of the Serial Port Monitor plugin's JsscSerialService. So from my perspective, the functionality of that service is good enough.
Specifically, in my plugin I close the port when a build starts, if the user so configures it, and reconnect it after a successful build. That way, the Arduino upload builds do not fail because the serial monitor is keeping the port busy.
Right now, the service allows any port to be closed by name. This is fine.
In my plugin, I check if the port was connected by my plugin before closing it, I do not close a port which was not first opened by the plugin. I think the service should be aimed at a cooperative plugin environment. If a plugin misbehaves, then it is up to the user to disable it or uninstall it.
I published the plugin SimpleSerialConnectorService along with the source (based on the Serial Port Monitor Service), with a readme file giving instructions on how to add it as a dependency to an existing plugin. Nothing fancy. Just the bare bones. Does what Serial Port Monitor service does.
The only changes I made to the original service:
Another reason I wanted to put a layer between my code and Serial Port Monitor, is to isolate the plugin(s) from API changes. If the Serial Port Monitor service changes or jssc changes, then in most cases, it would be possible to limit the changes to the SimpleSerialConnectorService plugin implementation layer or at least make it backwards compatible for a few releases.
JetBrains releases almost every month, with frequent API changes. As a user of the IDE, I don't have an issue and love the eye candy of each new release. As a plugin maintainer, ...
For many plugins, maintained by less than enthusiastic authors, in their spare time, for whom the novelty of maintaining a plugin has worn off long ago, this is much too often. Any reduction of the churn is welcome.
Just remembered the other major reason for having a plugin provide the service vs using what the IDE provides directly. This always bit me in the past for bug fixes and new features. Even when the IDE service becomes available, it will most likely do so only for the last few releases.
By having this plugin provide the service or seamlessly (I hope) delegate it, I can have my plugin(s) work with older and newer versions of the IDE right away, without having to wait for a supporting release.
BTW, Illia,
Dmitry Cherkas and I touched base in 2018 when I forked Arduino Support plugin and added serial monitor tool window. We both thought it was a good idea to come up with a solution for conflicts on the jssc library between plugins, but neither one of us had the time and the issue fell off the radar. I guess, better late than never.
Well, let's do than via the CLion ticket. Even though the serial monitor may be used with any IDE, nobody is going to take care about it except CLion team.
By the way, if you only care about connecting/disconnecting the port during uploads, I'd like to make something more generic than sharing JSSC, because it's gonna be done for many other frameworks, not only Arduino
Opened YouTrack Issue: CPP-33192
Illia, I have a few changes in the tool window beyond the automatic disconnection and planning on adding features similar to Arduino IDE graphing from values in the serial monitor console. However, it would be useful for users if they could have the auto-disconnect on build, reconnect after build available in the serial port monitor profile. Reconnection should only be done if the console was disconnected by the build. That way, a profile for the same port as used by Arduino Support but not connected in Serial Port Monitor, will not suddenly be connected by Serial Port Monitor after the build.
One caveat in build disconnection that I encountered was that for very short builds, the disconnect needed a 20ms delay before allowing the build to start. Otherwise, the build would encounter port-busy condition. In my plugin, I added a configurable delay, defaulting to 50ms for this.