In the StrongAspectJ paper, the authors consider this example as a case for separate “proceed signatures”: 

Integer around(): //(1)
  call((Integer || Number) *()):
  Number proceed() { //(2)
  return new Integer(proceed().intValue()); //(3)
}

In this example, the advice declares an “advice signature” (1) that returns Integer objects but a “proceed signature” (2) that returns any Number objects. This allows the advice to be applied to any method returning *any* type of Number while at the same time guaranteeing that only Integers are returned.

What could this look like in JPIs?

One could capture this semantics with a syntax such as: 

jpi A Number()-> Integer();

Here, Number() is the “expected interface”, i.e., the proceed interface, while Integer() is the provided interface.

Generic Advice

Another example given in the StrongAspectJ paper is the following: 

<N extends Number>
N around():
call((Integer || Float) *(..)):
N proceed() {
  N n = proceed();
  while(n.intValue() > 100)
    n = proceed();
  return n;
}

Here the generic type parameter N is used to refer to any concrete return type (here Integer or Float of Number). Using the type parameter instead of just directly using Number has the advantage that one knows that the advice *will* return an Integer if a method call returning an Integer is advised but also *will* return a Float if a method call returning an Float is advised.

In JPIs one could model this as: 

jpi <N extends Number> A N()-> N();

Such a jpi could then be applied to calls such as… 

Long l = System.currentTimeMillis();

… while the jpi jpi A Number()→ Number() could only be applied in cases where the method returns a value of type Number.