Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When I create a class called Process it looks like I'm experiencing class shadowing. For example:

public class Process {

The existence of the above class prevents me implementing the Process.Plugin interface. While it isn't a reserved word, here's an example class that I might attempt to save:

public class MyPlugin implements Process.Plugin {
    public Process.PluginDescribeResult describe() {
        return null;

    public Process.PluginResult invoke(Process.PluginRequest request) {
        return null;

and I'm immediately hit with the following compile error message:

Invalid type: Process.Plugin

At this point I'd thought this was a similar situation to creating a class called Account or some other SObject name. When that happens, you can fully qualify Schema.Account to differentiate them.

But it seems Process.Plugin is already fully qualified; System.Process.Plugin isn't a valid type.

Is there any way I can have a class called Process in my org and still use Process.Plugin?

share|improve this question
up vote 8 down vote accepted

I agree with @ca_peterson. There is no way to do it. The Type Resolution documentation indicates the parser will look for an inner type on a class as it has precedence over a top-level class in a namespace (see last line of the doc quoted below). In your case, the parser would not find an inner type "Plugin" defined on your "Process" class, resulting in the "Invalid type" error.

Because the type system must resolve user-defined types defined locally or in other classes, the Apex parser evaluates types as follows:

  1. For a type reference TypeN, the parser first looks up that type as a scalar type.
  2. If TypeN is not found, the parser looks up locally defined types.
  3. If TypeN still is not found, the parser looks up a class of that name.
  4. If TypeN still is not found, the parser looks up system types such as sObjects.

For the type T1.T2 this could mean an inner type T2 in a top-level class T1, or it could mean a top-level class T2 in the namespace T1 (in that order of precedence).

share|improve this answer
very insightful - thanks Peter – bigassforce Apr 7 '14 at 22:55

This is a rather interesting situation since according to the docs Process is not the outer class but the namespace itself. Since you're not just shadowing a class name but instead an entire namespace I'm not sure there's a way around this; in fact I strongly doubt that there is.

share|improve this answer
Aha, a namespace and not a class... interesting – bigassforce Apr 4 '14 at 3:48

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.