Preventing certain moves using ValueSelector results in ClassCastException

I have a Lecture class with a startTime planning variable and a fixed duration. I'm trying to filter out moves that causes the end time to go past 16:00.

I have written a selection filter:

public class LectureOutOfBoundsSelectionFilter
        implements SelectionFilter<Schedule, Lecture> {

    @Override
    public boolean accept(ScoreDirector<Schedule> sd, Lecture lecture) {
        return !lecture.isOutOfBounds();
    }
}

Which I configure as follows

<changeMoveSelector>
    <filterClass>package.PinnedTimeslotChangeMoveFilter</filterClass>
    <valueSelector>
        <filterClass>packager.LectureOutOfBoundsSelectionFilter</filterClass>
    </valueSelector>
</changeMoveSelector>

But I'm getting a class cast exception related to a different planning variable in Lecture. I've tried adding variableName="startTime" but this triggers a different class cast exception.

Am I on the right track here, and how does the variableName attribute actually work?

I'll start off your additional comment, where you explain further:

> With variableName="startTime" I'm getting java.lang.ClassCastException: class package.ImmutableTimeslot cannot be cast to class package.Lecture. Without variableName set, I get java.lang.ClassCastException: class package.Room cannot be cast to class package.Lecture.

There is an explanation for this behavior, although it is not really very intuitive:

• When you put the filter on the value selector without a variable name, both variable types will reach the filter. In this case ImmutableTimeslot and Room. Since your filter expects a Lecture, either of the two throws the exception.
• When you specify the selector's variable name to be startTime, this no longer triggers the value selector on values of the room variable; therefore, you are getting an exception where ImmutableTimeslot doesn't match Lecture.

In both cases, the problem appears to be that your filter is expecting Lecture instances (the entities), but the solver is sending either ImmutableTimeslot or Room (values of the planning variables). This is arguably the correct behavior of a value selector (emphasis on the word "value").

The reason why I'm calling this "not really intuitive" comes in two parts:

• The same SelectionFilter interface is always required, regardless if applied to a move selector, an entity selector or a value selector. So, based on where you intend to use it, the generic type required is different and that is confusing. (A move, an entity or a value respectively.)
• In cases with multiple variables (such as yours) without specifying a variableName on the selector, the generic parameter needs to be Object, because that filter will be receiving both types of values and that is the only way to avoid the exception you are getting.

All in all, not the best design; it comes from 2012 and due to maintaining backwards compatibility and us actually discouraging the use of selection filters, it has survived unchanged until the present day.