Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiler crashes when calling method with instance of Java interface that has changed #9054

Closed
scabug opened this issue Dec 19, 2014 · 4 comments

Comments

@scabug
Copy link

scabug commented Dec 19, 2014

The method is JComboBox.setModel(ComboBoxModel), which until JDK 1.7 was not parameterized.

I am constructing an instance of ComboBoxModel using scala-swing's ComboBox.newConstantModel (see
https://github.com/scala/scala-swing/blob/master/src/main/scala/scala/swing/ComboBox.scala#L121), which has not been updated since before the type parameter was added, and so does not specify a type for the super-interface (but does itself have the type parameter).

That compiles fine, however, when my source includes an attempt to use the resulting value in a call to setModel, the compiler throws an exception in type checking.

Even if scalac cannot accommodate this type of change, it would be much more helpful to get a compiler error with an explanation.

Here's a console session reproducing the problem:

scala> import scala.swing._
import scala.swing._

scala> val cb = new ComboBox[Int](Nil)
cb: scala.swing.ComboBox[Int] = scala.swing wrapper scala.swing.ComboBox$$anon$1[...]

scala> val m = ComboBox.newConstantModel(List(1, 2, 3))
m: javax.swing.ComboBoxModel = scala.swing.ComboBox$$anon$2@771904ae

scala> cb.peer.setModel(m)
java.lang.IndexOutOfBoundsException: 0
	at scala.collection.LinearSeqOptimized$class.apply(LinearSeqOptimized.scala:51)
	at scala.collection.immutable.List.apply(List.scala:83)
	at scala.reflect.internal.tpe.TypeMaps$AsSeenFromMap.correspondingTypeArgument(TypeMaps.scala:551)
	at scala.reflect.internal.tpe.TypeMaps$AsSeenFromMap.loop$3(TypeMaps.scala:585)
	at scala.reflect.internal.tpe.TypeMaps$AsSeenFromMap.classParameterAsSeen(TypeMaps.scala:590)
	at scala.reflect.internal.tpe.TypeMaps$AsSeenFromMap.apply(TypeMaps.scala:467)
	at scala.reflect.internal.tpe.TypeMaps$AsSeenFromMap.apply(TypeMaps.scala:441)
	at scala.collection.immutable.List.loop$1(List.scala:172)
	at scala.collection.immutable.List.mapConserve(List.scala:188)
	at scala.reflect.internal.tpe.TypeMaps$TypeMap.mapOver(TypeMaps.scala:115)
	at scala.reflect.internal.tpe.TypeMaps$AsSeenFromMap.apply(TypeMaps.scala:468)
	at scala.reflect.internal.tpe.TypeMaps$TypeMap.applyToSymbolInfo(TypeMaps.scala:218)
	at scala.reflect.internal.tpe.TypeMaps$TypeMap.loop$1(TypeMaps.scala:227)
	at scala.reflect.internal.tpe.TypeMaps$TypeMap.noChangeToSymbols(TypeMaps.scala:229)
...
@scabug
Copy link
Author

scabug commented Dec 19, 2014

Imported From: https://issues.scala-lang.org/browse/SI-9054?orig=1
Reporter: Moss Prescott (mossprescott)
Affected Versions: 2.11.4
See #8745
Duplicates #8439

@scabug
Copy link
Author

scabug commented Dec 19, 2014

Moss Prescott (mossprescott) said:
The problem turns out to be the raw JComboBox type, resulting from the call to scala-swing's un-parameterized peer method.

The following very ugly workaround not only makes the compiler not crash, it also works:
cb.peer.asInstanceOf[javax.swing.JComboBox[Int]].setModel(m.asInstanceOf[javax.swing.ComboBoxModel[Int]])

@scabug
Copy link
Author

scabug commented Dec 20, 2014

@gourlaysama said:
This is a duplicate of #8439. It is an issue with the newly generified classes in Java 7 Swing.

See also #8745 for the specific case of JComboBox.setModel.

@scabug scabug closed this as completed Dec 20, 2014
@scabug
Copy link
Author

scabug commented Dec 20, 2014

Moss Prescott (mossprescott) said:
Yes, that's certainly the same bug. Thanks for looking into it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant