Can an interface somehow prevent lambda expression implementations?

Question

Background

I am exposing the following interface as part of an API:

public interface Pasture {
    /**
     * @param t         The time of the visit (as measured from optimization starting point).
     * @param tLast     The time of the preceding visit (as measured from optimization starting point).
     * @return          The expected reward that will be reaped by visiting under the given conditions.
     */
    double yield(long t, long tLast);    
}

The client passes me models of "pastures" as objects implementing this interface. Each object represents one pasture.

On my side of the API, I keep track of "visits" to these objects at various times, then invoke pasture.yield(time, lastVisitTime) when I need to know how much the pasture would have produced in the mean time.

The problem arises that this interface can be implemented on the client side as a lambda expression, and apparently each lambda expression instantiation does not necessarily create a new object with a new identity, which is what I rely on in order to keep track of which pastures were visited at what times.

Question

Is there a way of preventing the interface from being implemented as a lambda expression, forcing instead that the client implements it as an anonymous class. Adding a dummy method to it would do the trick, of course, but that would be arbitrary and untidy in my opinion. Is there another way?

Answer 1

It is not the lambda edge case that is your problem.

You are making an assumption that the same object represents the same Pasture and are therefore making your object do two things at once. That is a code smell and is the cause of your difficulties.

You should force your Pasture objects to implements something like equals so that you can then check if the items are the same. Sadly there is no interface that does that, the nearest one is Comparable.

public interface Pasture extends Comparable<Pasture> {

Answer 2

You can add some checked exception to method:

public interface Pasture {
   double yield(long t, long tLast) throws Exception;    
}

But it is strange approach to deny lambda.

Answer 3

"[...] apparently each lambda expression instantiation does not necessarily create a new object with a new identity, which is what I rely on in order to keep track of which pastures were visited at what times."

^{(Emphasis mine.)}

When you're doing something, and it's causing you trouble, why not just stop doing it?

Instead, whenever a client passes you a "pasture", allocate a new internal ID for it and associate the pasture (and any metadata, such as the last visit time, that you may wish to store for it) with the ID.

That way, it doesn't matter if the client passes you the same pasture object several times — as far as your code is concerned, those pastures will have different IDs, and therefore represent distinct pastures with their own last visit times and other data, even if the client-side parts of them might be implemented by the same object.

(At least, that's true as long as the reused pasture objects don't maintain any mutable internal state; but your client should know better than to reuse objects with such state, and so does the Java 8 lambda implementation.)

Here's a quick sample implementation, using simple sequential integer IDs:

public class PastureManager {
    private int maxID = 0;
    private Map<Integer, Pasture> pastures = new HashMap<Integer, Pasture> ();
    private Map<Integer, Long> lastVisit = new HashMap<Integer, Long> ();
    long time = 0;

    public int addPasture (Pasture pasture) {
        maxID++;
        int id = maxID;
        pastures.put(id, pasture);
        lastVisit.put(id, time);
        return id;  // in case the client needs to re-identify the pasture
    }

    public double getYieldFor (int id) {
        Pasture pasture = pastures.get(id);
        if (pasture == null) {
            throw new IllegalArgumentException("Invalid pasture ID " + id);
        }
        long lastTime = lastVisit.put(id, time);
        return pasture.yield(time, lastTime);
    }

    // ...remaining code omitted...
}

The key feature here is that you never pass Pasture objects around after they've been added and assigned an ID, and you especially don't compare them or use them as map keys. Instead, any code that needs to refer to a specific pasture should use the pasture's ID; only the addPasture() and getYieldFor() methods (and possibly removePasture(), if you have such a method) need to access the actual Pasture objects stored in the pastures map.