Deal with various deprecation warnings in the code about openblcmm HOT 3 OPEN

So, ToolKit.getMenuShortcutKeyMask() does turn out to be a problem due to Java 8. So the following two methods were deprecated at the same time, in Java 10 (well, I'm assuming it was the same time, anyway):

• InputEvent.getModifiers()
• ToolKit.getMenuShortcutKeyMask()

We use InputEvent.getModifiers() when processing user input, and our main use of ToolKit.getMenuShortcutKeyMask() is Mac compatibility. Mac systems should prefer the "command" key instead of Control, and we use that function to get the keycode that we need to check on. (Theoretically, other systems could be configured to have a different menu shortcut key too, of course.)

Their replacements were versions with "Ex" at the end, which report on "extended" modifiers which are a little more sensible to work with. InputEvent.getModifiersEx() already existed in Java 8, so instances of just using that are easy enough to deal with, but ToolKit.getMenuShortcutKeyMaskEx() wasn't introduced until Java 10. So if we want to keep Java 8 support, we have to keep on using the deprecated version. The two functions often go hand-in-hand, too, so in cases where we're making use of both methods, we've effectively got to keep on using the deprectated InputEvent.getModifiers(), too. (We could do some finagling to be able to just use the newer one, but IMO it's not worth the code complication, especially since we don't have an alternative for getMenuShortcutKeyMask().

Relatedly, the constant InputEvent.CTRL_MASK is also deprecated, in favor of InputEvent.CTRL_DOWN_MASK.

So, for now I've just added in @SuppressWarnings("deprecation") on a few functions, and we'll just let it sit for longer. Eventually, of course, Java is going to get rid of the old versions, and once that happens, we'll have to choose between continuing to support Java 8, and supporting the newer Java version. I'd be fine with ending Java 8 support in that case... Honestly it might not be a terrible idea to just do it prematurely anyway. The Libera #java community discourages the use of Java 8 nowadays pretty heavily regardless.

The places where I've suppressed deprecation warnings because of this:

• blcmm.gui.tree.CheckBoxTree.CheckBoxTree() - In the keyPressed listener that's set up there
• blcmm.utilities.Utilities.changeCTRLMasks()
• blcmm.gui.panels.EditPanel.setCtrlEnterAction()

So, this bug'll probably have to remain open until we go ahead with ending Java 8 support.

from openblcmm.

Eh, okay, turns out JTextComponent.modelToView(int) and JTextComponent.viewToModel(Point) is another Java 8 blocker. In those cases, Java 9 added methods with 2D at the end of the name, which is the versions to call. Those don't exist in Java 8, though, so there's not much to be done if we want to keep on supporting Java 8.

I'm suppressing deprecation warnings for these, too -- fortunately just a single use each. The locations where they're found:

• blcmm.gui.text.AutoCompleteAttacher.show()
• blcmm.gui.text.HighlightedTextArea.addLink() - in the mouseMoved() method in the MouseAdapter setup there

from openblcmm.

Okay, at this point we've got no deprecation warnings showing up while compiling. There's the suppressed ones above, which we can't do anything about until we decide to stop supporting Java 8. It looks like they should still be present in Java 21, which I believe is supposed to be the next LTS release, so I think we'd be good for awhile. I'm mentally thinking that maybe we'd drop support for it in OpenBLCMM v1.5.0, whenever that is.

from openblcmm.