History of Apex language compiler

Apex – what does this abbreviation mean?

The abbreviation Apex means Advanced Programming Experience. Although there’s no official confirmation, that’s how it should be understood. There’s no record of it in the documentation. But Salesforce managed to accustom us with its naming using experience word, for example, Lightning Experience or, recently changed, the name of Communities to Digital Experiences.

In the beginning, there was an interpreter

Going back to the history of the language: its first implementation occurred with the Winter ’07 release. But it was only for the internal use of Salesforce and, eventually, was supposed to be shared with bigger customers until after a short phase of beta tests. The Apex author – Parker Harris, one of the Salesforce founders – claimed that developers “must get used to the new programming language,” “it’s not difficult if they’re accustomed to the syntax of database language and Java. But if they’re not database programmers, some terms might be new for them.”

Certainly, at that time, Apex syntactically didn’t differ from one of the most popular programming languages – Java.

Moreover, Harris assumed that Apex would not be designed for building UIs. Its primary purpose was to provide an additional layer of abstraction over database transactions, handle them, and enable simple data into objects transformation. That same year, Harris introduced VisualForce, a technology for creating user interfaces for customers, which, combined with Apex, represented a milestone in the platform’s development.

Bull’s eye – time for compiler

Enabling programmers to write code and launch it on the Salesforce platform gives them new opportunities. Since then, implementing complex business processes and providing tailor-made solutions is possible. Combined with VisualForce, from basic CRM, Salesforce technology became a universal environment. The concept was changed so the catchphrase famous in the early existence  of the platform – No Software – was replaced with a new one, “Platform as a Service.” To identify it with the platform, its name changed to Force.com. It was announced during the Dreamforce conference in 2008.

Let’s return to Apex. The first version of the language had no compiler, and the entire code was interpreted during command execution. It created some inconveniences related to effectiveness and language capabilities, such as the lack of possibility to deserialize JSONs. Also, the issue was the significant use of heap ram. Initially, the heap value on the Salesforce platform was 3 MB.

Despite huge commercial success, working on language development has not slowed down. In 2012, after 4 years of intensive work, Salesforce presented its first Apex language compiler. Although it wasn’t a compiler as we think of it now because all compilation operations were done in a cloud (specifically on the Force.com platform). But thanks to the new compiler, the Apex code was compiled directly to the bytecode, which then was launched on the Force.com platform. That year, the amount of heap ram was increased from 3 MB to 6.

Tentacles of an octopus

The first compiler, however, wasn’t perfect. In one of the podcasts, Chris Peterson – the current Product Director of Apex – said that he joined Salesforce during the time of implementing this first compiler, and at the time, it resembled octopus’s tentacles. He used this comparison because Apex was strongly integrated with all other Salesforce systems and services. It was potentially a major problem he had to deal with.

The question is, why?

An opportunity presented itself – of writing a new (and much better) programming environment using the Visual Studio Code editor. It had a great and undeniable advantage. The editor enabled using the Language Server protocol, created by Microsoft, in a simple way. Thanks to that, the language syntax and validation didn’t have to be defined directly in the editor. It could be done by using a local compiler (launched on a computer) and then, through a server, verify the syntax of the written code in real-time.

However, the compiler of that time wasn’t suitable for this task. It was too heavily integrated with all other Salesforce services, preventing the compiler from operating outside the platform. Once again, the product team had to improve the compiler.

New quality

After a few years, a new compiler was ready. In 2017, a new plugin to VSCode was featured; it enabled working with a code by using the Language Server protocol. Most likely, works on this solution have lasted for a longer time – there’s no detailed information but is it estimated that it all has happened between 2015 and 2017. Chris Peterson mentions that users were also given a local compiler of the Apex code by the time the plugin to VSCode was released. Still, it wasn’t a fully-fledged compiler since the compilation results weren’t saved anywhere, and it lacked a full integration with Salesforce services.

But it was one step further in the compiler development as well as the language itself. Chris’ team (whilst not many know that) has been releasing weekly patches for Apex. And if there’s a serious issue – once for a particular release. The language itself hasn’t been evolving syntactically too much, but it’s constantly improved.

Evergreen, that is, Salesforce Functions

Finally, we reach the present, and another challenge Apex is facing. Some time ago, Salesforce unveiled the Evergreen project – currently called Salesforce Functions. In a simplified way, it’s based on the defragmentation of a code to a function and then launching it in a cloud (same as in the case of AWS Lambda). Ultimately, code can be written in several popular languages, including Apex. But the challenge is to integrate with external maintenance and services of the platform. That’s why the other compiler is under development; it’s supposed to be provided with a standard library, and all integrations would be carried out through API. It’s essential since one of the Salesforce Functions capabilities will be launching functions locally to run tests. That’s the reason why any integrations with services need to be outside the compiler.

At the moment, it’s already known that Salesforce Functions will be shared publicly (GA) in the next release, and probably, the development of another compiler version is currently being finalized.

To sum up

Since its creation, Apex had strictly defined its objective, and it fulfills it up to this day. It was improved in terms of syntax. For example, there’s better control over returning the null value (Safe Navigation Operator, which I wrote in the following article: Null value in Salesforce – Safe Navigation Operator), SOQL inquiry enhancements (the FIELDS clause), or inherited sharing classes. However, the fastest-growing is not visible to developers – the language stability or how fast instructions are processed.