Why Can’t We Upcast Sets in Salesforce?

Question

When working with Apex collections, such as Sets, a common assumption is that we can upcast a Set<Account> to a Set<sObject> since Account inherits from sObject. However, attempting to do so results in errors during compilation or runtime. Here’s an example:

Set<sObject> testSet1;
Set<Account> testSet2 = new Set<Account>();

// Attempting to upcast
testSet1 = (Set<sObject>)testSet2;

This code produces the error:

Incompatible types since an instance of Set<Account> is never an instance of Set<SObject>.

The behavior might seem counterintuitive, especially given that Lists and Maps in Apex allow such upcasting. Let’s delve into why this happens and what makes Sets different.

Explanation

The restriction arises because Apex Sets are implemented using Java Sets in the backend, specifically as instances of java.util.HashSet. In Java, Generics (such as Set<T>) are invariant, meaning you cannot assign Set<Account> to Set<sObject>. This restriction ensures type safety by preventing unintended operations that could lead to runtime errors.

For instance, allowing this kind of upcasting would enable adding a Contact object to a Set<Account> by casting it to a Set<sObject>. This would break the type safety of the collection. Here’s an example to illustrate why this restriction exists:

Set<Account> accountSet =new Set<Account>();
Set<sObject> sObjectSet = (Set<sObject>)accountSet; // Hypothetical upcast
sObjectSet.add(new Contact()); // Would corrupt the original accountSet

Java enforces this restriction through Type Erasure, a mechanism where generic type information is removed during compilation. As a result, the runtime cannot validate or enforce type constraints on generics, necessitating these strict rules.

Why Do Lists and Maps Allow Upcasting?

Unlike Sets, Lists in Apex seem to behave more like Java arrays rather than generic Java collections. Arrays in Java are covariant, meaning you can assign Account[] to sObject[]. This covariance allows implicit and explicit upcasting, though it introduces potential runtime risks. Consider this example:

List<sObject> sObjectList = (List<sObject>)(new List<Account>());
sObjectList.add(new Contact()); // This works at compile-time but fails at runtime

This code compiles, but throws a System.TypeException at runtime when you try to add a Contact object to the List<sObject>.

For Maps, Apex documentation doesn’t provide explicit details about their implementation, but their behavior suggests some flexibility in type handling. For instance, you can upcast the value type of a map:

Map<Id, String> stringMap = new Map<Id, String>();
Map<Id, Object> objectMap = (Map<Id, Object>)stringMap;

However, attempting to upcast the key type produces a compilation error:

Map<Id, String> stringMap = new Map<Id, String>();
Map<Object, String> invalidMap = (Map<Object, String>)stringMap; // Compilation error

This suggests that Maps in Apex may use custom implementations or leverage Java wildcards, enabling limited flexibility in upcasting.

Summary

In summary, the inability to upcast Sets stems from Java’s implementation of generics, which is inherited by Apex. This behavior ensures type safety and prevents runtime errors, even though it might seem inconsistent with the behavior of Lists and Maps. Understanding these nuances can help you avoid confusion and write more robust Apex code.