I thought blobs were a primitive data type, and I wanted to see how the sort function would work. It bombs out with System.UnexpectedException: core.filemanager.ByteBlobValue cannot be cast to java.lang.Comparable What's going on here? did I implement it wrong, or is the documentation off? How, should it behave, anyhow? The error makes me think int needs to implement Comparable for a more meaningful result.


 List <blob> myList = new List <blob>();

  String myString = 'StringToBlob';
 Blob a = Blob.valueof(myString);

  String myString1 = 'StringToBlobabc';
 Blob b = Blob.valueof(myString1);

  • Isn't it just mylist.sort() with no parameters?
    – Eric
    Commented Aug 27, 2015 at 4:39
  • sorry, i had a typo in my code. it doesn't work tho. Commented Aug 27, 2015 at 4:42
  • blobs are just binary data, not even UTF-8. Why would you expect them to sort? It would be like sorting a set of JPG files or .xlsx files based on their contents.
    – cropredy
    Commented Aug 27, 2015 at 4:50
  • @Niv I am running into error when trying to run your code in anonymous window..was it working for you? just curious
    – javanoob
    Commented Aug 27, 2015 at 4:52
  • i'm saying that the documentation says that that sort works for primitives, and blob is a primitive.... I think the documentation is wrong. Commented Aug 27, 2015 at 4:59

2 Answers 2


Blob is indeed a primitive data type:

Contains methods for the Blob primitive data type.

And List.sort allows you to sort primitives:

Using this method, you can sort primitive types, SelectOption elements, and sObjects (standard objects and custom objects).

However, the documentation is often wrong with respect to built-in objects, mostly because built-in objects are pseudo-classes. I call them pseudo-classes because they don't follow the normal rules that classes do in Java, and many of them don't behave as you'd expect if you actually read the documentation.

As an example, you can only use the for-each loop on Iterable objects (those that implement the Iterable interface, which returns an Iterator object, one that implements the Iterator interface). The documentation implies this when you read up on custom iterables. You can call iterator() on a Set, and you can use it in a for-each loop, which means that it does, technically, implement the Iterable interface. So, you should reasonably be able to use a Set in String.join(Iterable<ANY>, String).

However, if you've ever tried this, you'll find that Set doesn't implement Iterable, meaning you can't actually use it in String.join, despite the fact that it works in for-each loops, and has a function that returns an iterator. This actually prompted me to post an idea. This same behavior also thwarts attempts to write utility methods that can accept either Sets or Lists as Iterables, since Sets don't technically do so, but you could accept an Iterator argument and use that instead...

I read an interesting article about how Apex Code is actually an interpreter that acts as an intermediary to the underlying JVM that salesforce.com runs on. What this means is that there are many constructs that simply aren't written into Apex Code that should probably reasonably be there, and again, built-ins and primitives are basically pseudo-classes that look like real objects until you start to look too closely. While Apex Code does work most of the time, there's plenty of edge cases where this isn't true, and the documentation doesn't cover edge cases very well.

In summation, when you find a bug like this, you have to work around it. I'd probably suggest storing all your blobs as hex strings and comparing those in memory. It'll only cost you double the size of the blob to store it as hex strings, but at least they'll sort properly. I'd also suggest filing a bug against the documentation using the Feedback option.


Maybe a bug??

Well, I guess you could go about it like this:

List <blob> myList = new List <blob>();
List<String> strList = new List<String>();

  String myString = 'StringToBlob';
  String myString1 = 'StringToBlobabc';

for(string s : strList)

although I do not know if the blob values would necessarily be sorted but they would be sorted according to their original string value;

Not ideal, and I am sure you knew this but just in case...

  • Is it just me? I am receiving the error when trying to run the code in the question System.UnexpectedException: core.filemanager.ByteBlobValue cannot be cast to java.lang.Comparable
    – javanoob
    Commented Aug 27, 2015 at 4:48
  • 1
    I broke Salesforce! What do I win? Commented Aug 27, 2015 at 5:00
  • 1
    A fun support ticket for a rollercoaster ride of we tried to call you (1am) but you were not available (on a number different than what you told them to call you on) only to have the case closed and directed to the forums because us Dev's, credentialed people, users, etc are not allowed to report bugs....Unless we pay for the privilege
    – Eric
    Commented Aug 27, 2015 at 5:13
  • 2
    @Bachovski Not a problem. Sorting strings is basically the same as sorting blobs. Compare byte by byte from left to right until one byte is lower than the other or one string terminates.
    – sfdcfox
    Commented Aug 27, 2015 at 5:27
  • 2
    @Niv Salesforce documentation is backwards from most other platforms you'll use, ever. See, in languages like C, C++, or Java, a specification is drawn up, which becomes the documentation of the language, which in turn is then implemented into the language. Conversely, in Apex Code, the language is made up as the developers go along, and then they feed that information to the documentation team, who makes it look all pretty. In other words, the "code" never has bugs, but the documentation does (e.g. the feature wasn't implemented, but the docs said it was...).
    – sfdcfox
    Commented Aug 27, 2015 at 5:33

You must log in to answer this question.

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