Drools rule validating objects within Scala Option type

Question

(Mandatory Newbie Disclaimer)

I'm trying to write a rule that fires whenever an object within a (scala) list matches a condition. The issue here is that the list is actually an Option(List[TypeA])... (Also, I realise it isn't best practice to store lists in working memory, but I can't do otherwise given the circumstances)

The case classes I'm using have the following sort of structure:

TypeA {
    arg1 : Option[List[TypeB]]
}

with

TypeB {
    value : String
}

I've written a rule similar to this:

when
    $a : TypeA($l : arg1)
    $b : TypeB() from $l.get()
then
    System.out.println($b)

I've tried this out without the ".get()" only to get an object of type Some().

Using the ".get()", I have managed to return the contents of the Option but it doesn't seem to match the expected type (List[TypeB]). Instead the type of the value returned seems to be scala.collection.immutable.$colon$colon

Any ideas on what the problem is? And if there is any proper way to handle Options in Drools?

Answer 1

Since you are doing a lot of Java and Scala interop, I suggest you make yourself very familiar with the Scala's javaconverters functionality. This handy collection of utilities allows you to convert Scala collections to Java collection and vice versa.

In your case, I think you need to convert from a Java collection to a Scala collection. Try the following:

import scala.collection.JavaConverters._

val myScalaList = $b.asScala.toList

Example from the documentations:

import scala.collection.JavaConverters._

val sl = new scala.collection.mutable.ListBuffer[Int]
val jl : java.util.List[Int] = sl.asJava
val sl2 : scala.collection.mutable.Buffer[Int] = jl.asScala
assert(sl eq sl2)

An additional problem you have is that of mutable and immutable data structures. The standard list structure in Java is mutable but by default Scala offers you an immutable list unless you explicitly indicate that you want a mutable list. Therefore, there will be some impedance mismatch when doing naive conversions between the two worlds.

As I have mentioned in an earlier post, you can avoid yourself many issues by creating Java classes for the entities that you need to push into Drools. Mixing Java classes with Scala classes in Scala based projects is not an issue.

An alternative method is to create a function in your Scala case class which converts the Scala collection to a Java collection using the asJava method and returns it. In your DRL file whenever you need to reference that scala collection, call this method so that you get a Java collection instead.

Ideally, JBoss Drools, if they so choose, need to either enhance their current compiler to deal with Scala types better or make a dedicated Drools Scala compiler which will not mangle the Scala types.

Answer 2

The only thing I can think of to try:

when
    $a : TypeA($l : arg)
    $b : TypeB() from (ArrayList)$l.get() // or some other Java *-List
then
    System.out.println($b)

Worth another try:

when
    $a : TypeA($l : arg)
    $b : TypeB() from $l.get()asJava()*-List
then
    System.out.println($b)