0

I got the following error today: java.lang.NoSuchMethodError: javax.swing.JList.getSelectedValuesList()Ljava/util/List;

We have some customers still using old java6 versions out there. (Some old posready/embedded-version of windows that doesn't accept installing 1.8 directly..) Therefore I use compiler compliance level 1.6 in eclipse. However, after an upgrade of our software, some customers reported errors/freezing. I logged in, and found the following error: java.lang.NoSuchMethodError: getSelectedValuesList()Ljava/util/List; It appears that this particular JList method in was introduced in 1.7, and I have started using it since getSelectedValues() is deprecated. But this breaks things on 1.6, since the method does not exist in 1.6. I have made a workaround, instead of calling getSelectedValuesList() I now call the following method:

public static <E> java.util.List<E> getSelectedValuesList(javax.swing.JList<E> l) {
    try {
        return l.getSelectedValuesList();
    }catch(java.lang.NoSuchMethodError err) {
        ArrayList<E> v = new ArrayList<E>();
        Object[] oo = l.getSelectedValues();
        for (Object o : oo) {
            v.add((E)o);
        }
        return v;
    }
}

This seems to work ok. But my question is, since source level is 1.6, how do I detect similar errors? Since I don't even have 1.6 installed, how can I know for sure that all my swing methods that I call actually works in 1.6? I don't want to introduce yet another bug later on. :-)

runholen
  • 850
  • 11
  • 24
  • 1
    *"how can I know for sure that all my swing methods that I call actually works in 1.6?"* Use the compiler **cross-compilation options** as I detail in [this answer](http://stackoverflow.com/a/22496754/418556).. Note that if you find that answer helpful, I'd like to transfer it here so it can be an 'accepted answer'.. – Andrew Thompson May 04 '16 at 13:35
  • BTW - I expect your current work-around would be producing 'deprecated' warnings? I detest having to ignore warnings every time I compile. Fortunately there might be a better way to avoid them in this case. See [`JList.getSelectedIndices()`](http://docs.oracle.com/javase/8/docs/api/javax/swing/JList.html#getSelectedIndices--) which is very much ..not deprecated & has been [available since 1.4.2](https://www.cs.duke.edu/csed/java/jdk1.4.2/docs/api/javax/swing/JList.html#getSelectedIndices()) (& probably earlier). – Andrew Thompson May 04 '16 at 13:42
  • Hi. I now tried javac.exe with source 1.6, target 1.6 and bootclasspath rt.jar of the 1.6 version The problem with including bootclasspath is that it then complains on error: "type JList does not take parameters ... JList list" I really want to keep my generics in the source and still be able to detect missing methods. – runholen May 06 '16 at 07:46
  • Try removing the *"source 1.6,"* parameter. Let me know how it goes. – Andrew Thompson May 06 '16 at 07:59
  • javac: target release 1.6 conflicts with default source release 1.8 – runholen May 06 '16 at 09:20
  • Hmm.. I guess you'll just need to run the full options ***occasionally*** and parse through the output for the errors caused by missing methods.. – Andrew Thompson May 06 '16 at 09:59

0 Answers0