Why apex-lang for Apex developers ?

apex-lang is an open source Apex library, its Apex port of very popular Apache Common Lang java project. Almost all java developers and open source projects in Java depend on Apache Common Lang. This is really good to see that something similar came to apex in open source. apex-lang is comprising of many Utility classes that port the Apache’s stuff to apex, plus give nice wrapper on top of standard Salesforce apex api also. Here is a list of useful Apex util classes

• ArrayUtils:

  • APIs : To reverse, merge, subset, compare and most importantly SORT arrays. As with Apex List<Object>  and Object[] can be used interchangeably, so the same class with go well with Apex List collection too.        

  • Views : I worked a little with the sorting api’s. I liked the convenience of Apex port done for Java’s Comparator. Script statements consumed in sorting big collections requires a little care, will cover the sorting API, in a separate blog post.

• EmailUtils:

  • APIs : On top of Apex e-mail api, had support for sending html/plain email with attachments too.

• LanguageUtils:

  • APIs:  to deal with many language specific options like preparing list of SelectOption, parsing language information from HTTP request headers like “Accept-Language”. More details about this in Richard’s blog post

• MapUtils:

  • APIs : To join and compare maps.

  • Views : I was expecting much more here, like support for Map-Keys as UDT(User Defined Types) etc.

• PageUtils: A bunch of useful API’s, good stuff to get request params, set page messages and url redirects.

• RandomUtils/RandomStringUtils:

  • APIs : For more precise control on how to generate randoms. Definitely offers flexibly APIs as compared to standard Apex Math.random().

• TestUtils:

  • APIs : To see if their are messages of a given severity etc.

  • Views: Few more APIs could be their like, one for creating mock test users for System.runAs(), can be a good addition to this.

• SObjectUtils:

  • APIs : 

    • To copy fields across Sobjects

    • Check if fields are null/empty

    • Get/put fields using field-name as string

  • Views : Developers beginnning with Apex, should read this class to know the mini java – reflection style support with Apex.

• SoqlUtils:       

  • APIs: Its too rich and would need time to carefully read this blog post from Richard.

  • Views : Nice bunch of APIs for creating dynamic SOQL, and well documented in the blog post too. Excellent !

• WordUtils :

  • APIs : Interesting API’s to capitalize, reverse case etc etc the Strings.

• Other Util Classes like  StringUtils, SystemUtils, UrlUtils, UserUtils, SetUtils, BooleanUtils, NumberUtils, also offer decent APIs on standard Apex primitive data types and other types like User. Can be handy on many occasions.

Apex-Lang should be matured to standard Apex API

I said this because of a couple of reasons, like

• Presence of Governor Limits : Because Apex always runs under control of notorious Governor. This governor just gives us small number of script statements to execute for ex. Trigger : 10,000, Test : 20,000, Anonymous Block,Visualforce Controller, or WSDL Method : 200,000. So under these small limits, it becomes risky specially if your biz logic is already on edge of these limits. Even one can easily reach these and other limits(stack depth etc) while working on big collections.

• Loading of many Apex classes: As coming from Java background, I was habitual of following too many design patterns and creating many different Apex class files for Utility, Factory and many other relevant stuff. But sometime back I came to know that “Loading new Apex class is a big performance penalty, it triggers some validation code to ensure that dependent classes etc are valid”. So this becomes a big penalty when creating frameworks like this, its hard to keep number of Apex classes to minimal. Solution to this is “to create many related nested/inner classes inside a big Apex class file”.

• Apex code limits: Though this is not a big reason, but as these frameworks are normal Apex classes, they share your org code limits. If you are working on big Salesforce projects, you can already be on or close to border of this limit. This salesforce community link is good example of this.

So because of these reasons, projects like apex-lang should be matured to standard Apex API. Not all utility classes but many could be moved to standard Apex API. So for this reason, I am posting this as an idea on Salesforce Idea Exchange. Please promote it, if you want to see apex-lang maturing to standard apex-api. (link to idea)

References

• apex-lang at Google Code

• apex-lang at Code Share

• apex-lang SOQL builder

• Getting started with apex-lang

• Idea Exchange : Mature Apex-Lang to standard Apex API