Are there current plans to address use of JetBrains "Marked for removal" functions?

[jomof]

From the build log in #848, these two:

• ConnectDocumentToLanguageServerSetupParticipant::projectOpened
• DebugAdapterServerPanel use of addBrowseFolderListener(...)

These would prevent users of LSP4IJ from moving forward to a new IJ Platform release in the future.

[angelozerr]

Indeed we should fix that:

• ConnectDocumentToLanguageServerSetupParticipant::projectOpened we need to take care to avoid breaking the feature.
• DebugAdapterServerPanel use of addBrowseFolderListener(...) any PR are welcome to change this code.

[jomof]

Unfortunately, even the DebugAdapterServerPanel/addBrowseFolderListener case isn't dead trivial.

The replacement function, addBrowseFolderListener(Project, FileChooserDescriptor), didn't exist yet in 2023.3 so I can't just drop that in.

The option I see is to use reflection to call new addBrowseFolderListener(2 params) if available, otherwise call old addBrowseFolderListener(4 params). Would that PR still be welcome? Does LSP4IJ have a standardized way of handling this kind of compat issue?

Notes:

• I assume dropping support for earlier IJ versions is a non starter, but if it isn't, the lowest version that would work is 2024.3.
• I evaluated subclassing TextFieldWithBrowseButton and can explain why that won't help if needed.

[angelozerr]

The option I see is to use reflection to call new addBrowseFolderListener(2 params) if available, otherwise call old addBrowseFolderListener(4 params). Would that PR still be welcome? Does LSP4IJ have a standardized way of handling this kind of compat issue?

There is some Java reflection in LSP4IJ but if we can avoid it, it would be better. I think we can move to 2024.3, but I don't know if it will be easy to do (what about tests? what about gradle? @sbouchet have you some idea?)

[fbricon]

we try to keep compatibility with at least last year's IJ version, so, as of today, that'd be 2024.1. A minimum of 2024.3 seems a bit aggressive to me.

I'm not too worried about "Marked for removal" warnings, as we'll always have a compatible version available when this actually becomes a real issue, i.e. when that code is actually removed upstream.

[sbouchet]

@angelozerr that should be straight forward. the code already compile and passes tests for 24.3, so it should be all right for 24.1 too.

[angelozerr]

Ok thanks @sbouchet for your feedback.