groovy

Strange behaviour with Swingbuilder.list and listData casting to Vector

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 1.6.5, 1.7.1
  • Component/s: Swing
  • Labels:
    None
  • Number of attachments :
    0

Description

I have this example:

import groovy.swing.*
import javax.swing.*

def swing = new SwingBuilder()

def masterData = [en: ['Hello, World!', 'How are you?'], 
                  es: ['Hola Mundo!', "Como Esta?"], 
                  can: ['Foon Ying!', 'Lei Ho Ma?']]

def detailModel = new DefaultListModel()

swing.actions() {
  action(id: 'masterAction',
          name: 'masterAction',
          closure: {e->
            def l = e.source
            if (!e.valueIsAdjusting) {
              def i = l.selectedValue
              detailModel.clear()
              masterData[i].each {
                detailModel.addElement(it)
              }
            }
          })
}
swing.frame(title: 'My Frame', pack: true, visible: true,
                 defaultCloseOperation: javax.swing.WindowConstants.EXIT_ON_CLOSE) 
{
  panel() {
    tableLayout() {
      tr {
        td {
          scrollPane() {
            list(valueChanged: masterAction.closure, 
                 visibleRowCount: 3, 
                 listData: masterData.collect {k, v -> k })
          }
        }
        td {
          scrollPane() {
            list(visibleRowCount: 3, model: detailModel)
          }
        }
      }
    }
  }
}

the code shown works fine when run under Groovy 1.6.4 via IntelliJ Maia EAP 10666. When run directly in 1.6.4’s GroovyConsole, it gives an error:

Exception thrown: Cannot cast object '[en, es, can]' 
with class 'java.util.ArrayList' to class 'java.util.Vector'

org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 
'[en, es, can]' with class 'java.util.ArrayList' to class 'java.util.Vector'
	at ConsoleScript0$_run_closure2_closure5_closure6_closure7_closure8_closure10.
            doCall(ConsoleScript0:31)
	at ConsoleScript0$_run_closure2_closure5_closure6_closure7_closure8_closure10.
            doCall(ConsoleScript0)
	at ConsoleScript0$_run_closure2_closure5_closure6_closure7_closure8.
            doCall(ConsoleScript0:30)
	at ConsoleScript0$_run_closure2_closure5_closure6_closure7_closure8.
            doCall(ConsoleScript0)
	at ConsoleScript0$_run_closure2_closure5_closure6_closure7.
            doCall(ConsoleScript0:29)
	at ConsoleScript0$_run_closure2_closure5_closure6_closure7.
            doCall(ConsoleScript0)
	at ConsoleScript0$_run_closure2_closure5_closure6.doCall(ConsoleScript0:28)
	at ConsoleScript0$_run_closure2_closure5_closure6.doCall(ConsoleScript0)
	at ConsoleScript0$_run_closure2_closure5.doCall(ConsoleScript0:27)
	at ConsoleScript0$_run_closure2_closure5.doCall(ConsoleScript0)
	at ConsoleScript0$_run_closure2.doCall(ConsoleScript0:26)
	at ConsoleScript0$_run_closure2.doCall(ConsoleScript0)
	at ConsoleScript0.run(ConsoleScript0:24)

The workaround is to use:

list(..., listData: masterData.collect {k, v -> k } as Object[])

This is probably more ‘correct’ according to the API, anyway.

Still, something feels ‘off’ here…why the different behaviors?

The IntelliJ run line is:

"C:\Program Files\Java\jdk1.6.0_16\bin\java" -Dgroovy.home=C:\DEVTOOLS\groovy-1.6.4
 -Dgroovy.starter.conf=C:\DEVTOOLS\groovy-1.6.4\conf\groovy-starter.conf 
"-Dtools.jar=C:\Program Files\Java\jdk1.6.0_16\lib\tools.jar" -Didea.launcher.port=7532 
"-Didea.launcher.bin.path=C:\Program Files (x86)\JetBrains\IntelliJ IDEA 10666\bin" 
-Dfile.encoding=windows-1252 -classpath "C:\DEVTOOLS\groovy-1.6.4\lib\groovy-1.6.4.jar;
C:\Program Files (x86)\JetBrains\IntelliJ IDEA 10666\lib\idea_rt.jar" 
com.intellij.rt.execution.application.AppMain org.codehaus.groovy.tools.GroovyStarter 
--conf C:\DEVTOOLS\groovy-1.6.4\conf\groovy-starter.conf --classpath 
C:\DEVELOPMENT\CascadingLists\out\production\CascadingLists 
--main groovy.ui.GroovyMain 
C:\DEVELOPMENT\CascadingLists\src\CascadingLists.groovy

Java is:

C:\Windows\System32>java -version
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)

This is IntelliJ Maia EAP #10666.

This is 64-bit Win7 RC.

Same issue is seen with 1.7-beta1.

Execution is like:

C:\DEVTOOLS\groovy-1.7-beta-1\bin>set CLASSPATH=
C:\DEVTOOLS\groovy-1.7-beta-1\bin>set GROOVY_HOME=C:\DEVTOOLS\groovy-1.7-beta-1
C:\DEVTOOLS\groovy-1.7-beta-1\bin>groovyconsole.bat

See also: http://markmail.org/message/wxx5wweewikciyjv, http://wordpress.transentia.com.au/wordpress/

Activity

Hide
blackdrag blackdrag added a comment -

added some line breaks

Show
blackdrag blackdrag added a comment - added some line breaks
Hide
blackdrag blackdrag added a comment -

this looks like a bigger problem if my guess is right. JList does use two setListData methods, where one takes a Vector and the other takes an Object[]. Now we don't really do a dirct method call here, we use the bean setter. But what is the setter here? beans don't support overloaded setter, which means one of those two is randomly taken.

Show
blackdrag blackdrag added a comment - this looks like a bigger problem if my guess is right. JList does use two setListData methods, where one takes a Vector and the other takes an Object[]. Now we don't really do a dirct method call here, we use the bean setter. But what is the setter here? beans don't support overloaded setter, which means one of those two is randomly taken.
Hide
Andres Almiray added a comment -

If so then the fix would be to let the JList factory handle setListData() directly by inspecting the type of its argument.

Show
Andres Almiray added a comment - If so then the fix would be to let the JList factory handle setListData() directly by inspecting the type of its argument.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: