I have a problem in using Drools Planner (written in Java) in Scala. One of interfaces in Drools planner is declared as:
public interface Score<S extends Score> extends Comparable<S>
However another interface uses 'Score' as a raw type:
public interface Solution {
Score getScore();
Then I'd like to implement this interface in Scala:
class MySolution extends Solution {
def getScore: Score = ...
And I get a compilation error: Scala compiler disallows writing just 'def getScore: Score'. When I try adding 'Score[_]' or 'Score[whatever]' compiler complains about type incompatibility. What should I do?
Write a Java class to serve as a bridge between what the Java interface requires and what Scala allows.
SolutionBridge.java:
abstract class SolutionBridge implements Solution {
public Score getScore() {
return scalaGetScore();
}
abstract Score<?> scalaGetScore();
}
SolutionScala.scala:
class SolutionScala extends SolutionBridge {
def scalaGetScore() = null.asInstanceOf[Score[_]]
}
The error message which you omitted is not an extraneous detail. Re "I would also expect some support from Scala on this", you might also opt to participate in the process by reading the error messages and, if you don't understand them, include them when asking a question rather than vaguely paraphrasing them.
Error messages, they're important. Even when they're confusing. Especially when they're confusing.
Here is the error in 2.8.1:
a.scala:2: error: overriding method getScore in trait Solution of type ()Score[_ <: Score];
method getScore has incompatible type
def getScore: Score[_] = null
^
one error found
Here is the error with trunk:
a.scala:2: error: overriding method getScore in trait Solution of type ()Score[_ <: AnyRef];
method getScore has incompatible type
def getScore: Score[_] = null
^
one error found
There is a key difference there, which contributes to why it works with trunk when I do as the error message instructs me.
// this compiles with 2.9, but not with 2.8
class MySolution extends Solution {
def getScore: Score[_ <: AnyRef] = null
}
The way the raw type Score is being used in the java source (as a type constructor in one location but with an implied existential type argument in another, with the second appearance bounding the first) it's a wonder it works anywhere. You don't want to know how much damage accomodating this sort of thing has already inflicted on the compiler. It's true that it would be nice if raw types just worked, but many things would be nice. Some things are not possible, some things are not desirable, and some things require too much effort from the tiny number of people keeping the ship afloat. Raw types win the triple crown.
The next release of Drools Planner (5.2.0.M2) will fix this issue. Here's the commit on git.
In some cases, people want to define their own Score
implementation (for example NurseRosterScore
implements HardAndSoftScore
), to be able to show to the user per hard or soft constraint type what exactly is violated in the best solution. This change is the first step to make that easier and cleaner (even though it's already possible).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With