What are the risks or drawbacks of creating Parameterized Interfaces using of the Apex API version 25?

Question

Unfortunately, as of API version 26, SFDC removed parameterized interfaces.

However, it is relatively easy to create new interfaces and set the version as 25.

So, to take the example from Parameterized Interfaces - what are they?, I can make the Pair and DoubleUp interfaces, as "version 25", but then I can make the StringPair itself as "version 38" (for example).

The StringPair compiles and functions as expected.

While one might argue that this would not be idiomatic Apex and that newer developers might not be able to find documentation to support it (if they don't use stackechange, but who doesn't?), I'm wondering from a technical perspective, what problems should I expect?

• Do issues related to instanceof also effect Parameterized types?
• Are there performance problems?
• Are there known compatibility issues when such interfaces might be come into contact with newer features or objects/sObjects which are dependent upon newer features?

To be clear, I'm not suggesting putting all the code or any other code into older API versions, just specifically the parameterized interfaces.

Answer 1

Do issues related to instanceof also effect Parameterized types?

Yes. The instanceof behavior for these almost certainly has edge cases or areas where there is no defined behavior.

Are there performance problems?

There have been in the past. I'm not aware of any ongoing performance problems, but there's also very little use of parameterized types in Apex, and as they are no longer supported net-new adoption finding performance issues would be unlikely to be a priority.

Remember that by being on APIv25 you're opting in to dozens of years old bugs in these classes. Many Apex bugs have to be fixed as versioned due to somebody somewhere relying on the improper behavior, leading to the fixes being versioned changes.

There are known issues with how managability rules (what prevents you from breaking customers in managed packaged code). Absolutely do not do this for a managed package.

I would still strongly discourage the use of this in non-managed code. Any support for issues found will be limited.

Answer 2

For "Shits and giggles", I decided to try transcribing some Java code to Apex to see how (ab)using parameterized types might hold up in more complicated scenario.

Perhaps either my understanding or my transcription is incorrect since even version 25 doesn't support an interface like:

public interface TaxStrategy<P extends TaxPayer> {
  public double extortCash(P p);
}

So, I had to settle for making the interface simply:

public interface TaxStrategy<TaxPayer> {
  public double extortCash(TaxPayer taxPayer);
}

or

public interface TaxStrategy<P> {
  public double extortCash(P p);
}

Either way, the Apex compiled, but when I tried to anonymously execute my code, the attempt failed with:

DEBUG LOG apex.bytecodeinterpreter.InterpreterRuntimeException: Made lookup for method that does not exist on this type (TAX_XTOR_EmployeeTaxStrategy). MethodRef = void.TAX_XTOR_TaxStrategyIntf$$lTAX_PAYR_TaxPayerIntf$$r_iextortCash(java/lang/Object)java/lang/Object Error Id: 1723891688-25942 (1784837775)

If I added debug logs, I could verify the code executed until the correct strategy was instantiated, but suddenly died when the extortCash() was executed. Interestingly, this is actually a silent failure, as the log doesn't include the exception and has a status of "Success".

While it is possible that my interpretation from Java to Apex is incorrect, that there are silent failures and SFDC makes the code very difficult to debug is a big blocker in my book.