Can't find a post saying this, and I get a compile error, but just to be sure, this is not supported in Apex right?

public interface Access {

    public interface Context {

    public Set<Id> accessibleContacts(Context context);


Pity it isn't given that the inner class approach is good for grouping classes in an outer class that acts as a namespace. And an arbitrary and so annoying irregularity.

  • If your main use case is to have a pseudo-namespace, is there a functional difference between this nested interface approach and an inner interface inside of an outer class?
    – Derek F
    May 22, 2020 at 21:05
  • Thanks Derek - good point. I'll slightly expand the example where the ideal would be interface/interface.
    – Keith C
    May 22, 2020 at 21:12

2 Answers 2


As the documentation says in this entry Differences Between Apex Classes and Java Classes

 - Inner classes and interfaces can only be declared one level deep inside an outer class.

So you are allowed to declare an interface only inside a class (not inside an interface). I think you can still acquire the desired output of having a bunch of interfaces inside a "namespace". Just make it abstract, so it cannot be instantiated

public abstract class Access {

    public interface Context {}

    public Set<Id> accessibleContacts(Context context) { 
        throw new NotImplementedException('You must implement the accessibleContacts method');

    public class NotImplementedException extends Exception {}
  • Yep if you read the docs carefully enough which I don't... And the question remains "why" the irregularity.
    – Keith C
    May 22, 2020 at 21:15

The main reason why this is not supported, is that Apex isn't Java. When salesforce.com sat down and started designing Apex, they created a BNF that they felt could be implemented in a reasonable amount of time, have enough language features to be useful to the majority of customers, and be generally secure and stable enough that it wouldn't crash frequently.

Even back then, though, developers had a very good chance of running into Internal Server Errors if they didn't strictly follow the code patterns laid out in the documentation. Things like deeply nested classes, nested interfaces, etc were simply out of scope for the project, as they would have been too complicated, and could be solved by other, simpler patterns. The compiler was too fragile to handle large new features, and many of these probably would have broken Apex completely.

Think of all the things we don't have from Java: events, nested interfaces, default parameters, lambdas, anonymous inner classes, deeply nested classes, nested interfaces, java.lang.Reflect, nested namespaces/packages, import statements, there's a huge list of things that are just different or missing. Apex was thrown together in a very short amount of time (as far as compilers go), and the fact that it worked as well as it did initially was a surprise to some.

I don't think you can get an official answer for why it's not supported other than a vague "we didn't have time" or "it was too complicated" type answer. Just know that the old compiler could not have handled this type of code, and today we're still in compatibility with that old compiler. For now, if you want interfaces grouped together, put them inside an abstract class, or group your classes into unlocked packages (or not, just use folders into your repo!).

If you're not yet using DX, you may want to start leaning in that direction. It offers the sort of organization you're looking for, just not on the server side. It's not likely we'll see many of these features any time soon, although I would be pleasantly surprised if they were.

  • Thanks. Yes we use SFDX, and have low expectations on innovation in Apex, it being a proprietary language. Just feeling frustrated at this inconsistency between classes and interfaces.
    – Keith C
    May 24, 2020 at 21:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .