Press ESC to close

Expecting more Java goodness in Apex?

Apex Runtime Update for Developer Edition Orgs complies Apex code to Java byte code. This change is awesome from performance improvements standpoint, but shall we expect more Java into Apex also ?

Few of the following Java features would be a nice addition to Apex:

1. Diamond operator

Why declare same Type information on both LHS and RHS with Generics. For ex. here is a redundant declaration for creating a Map

Map<String, Set<Integer>> numbersByKey = new HashMap<String, Set<Integer>>();

With Java 7, the same could be done simply by only specifying type information on LHS, as shown below. This would be a really nice feature to have in Apex also.

Map<String, Set<Integer>> numbersByKey = new HashMap<>();

Posted the same as Idea : https://sites.secure.force.com/success/ideaView?id=08730000000bZ0bAAE

2. Support for Switch Case statement

Community is demanding this a lot, for more than a year. Please promote this idea on IdeaExchange http://success.salesforce.com/ideaView?id=08730000000BrSIAA0

Recently Java 7, also added support for Strings apart from other primitives to Switch case, that could be a huge ease for Apex programmers too.

3. Have Generics support in Apex Language

Generics are partially supported in Apex, you must be using them with Collections and Batch Apex. But you can’t declare your own classes to have similar support like

/**
 * Generic version of the Box class.
 * @param <T> the type of value being boxed
 */

public class Box<T> {

    private T t; // T stands for "Type"

    public void add(T t) {
        this.t = t;
    }

    public T get() {
        return t;
    }
}

For more details about Generics please check : http://docs.oracle.com/javase/1.5.0/docs/guide/language/generics.html

Again found an Idea posted for the same : http://success.salesforce.com/ideaView?id=08730000000aDnYAAU

4. Support for Reflection

Reflection API in Java is the key to so many rich frameworks and open source good ness. Apex partially supports some of that via giving good describe information on Sobjects. If the same could be made available for apex classes, that would open many possibilities for richer APIs and frameworks on Apex.

For more details about reflection please check this WIKI article : http://en.wikipedia.org/wiki/Reflection_(computer_science)

Again, idea already posted on App Exchange for the same : http://success.salesforce.com/ideaView?id=08730000000BrVaAAK

Your views ?

Want to make Apex even more awesome, please post ideas and share your views ?

Comments (4)

  • Anonymoussays:

    December 12, 2011 at 4:34 pm

    There is so much I'd love to have in there!! Off the top of my head:1) Get rid of the “List has no rows for assignment to SObject” exception. If a query returns no result, just assign null to the object, e.g. Account test = [select id from Account where id = null];system.assertEquals(null, test);2) Rework callout restrictions, in particular Batch.There are so many times an operation takes more than one callout to complete. One recent example was a sfdc/google contact sync where you have to first request the contact from google, make updates, then post back. Doing this with batch apex required a ton of back flips to make it work.3) Make testing helpers a priority.Given testing is such a core component of Salesforce's ideology, the effort given to making features testable is painfully behind the times. Key items:- Callout mocking- SOQL Overriding- Write to any field (e.g. createdDate) / object (e.g. object history)- Bypass validations- Bypass triggers- Bypass workflows

  • Anonymoussays:

    December 12, 2011 at 5:09 pm

    All great points Ralph, you touched many panic veins of an Apex programmer. The issues pointed out by you are really major apex problems, specially callout restrictions and test data isolation. But my this post is more targeted getting some Java goodness in Apex, I got in mood to share this post, when reading Java 7 specs and recalled that Apex classes will be Java byte code now, so we can expect similar from them.

  • Anonymoussays:

    January 29, 2012 at 4:42 pm

    I think it's a misnomer to call anything “Java Goodness” as Java can only be improved by becoming less like Java and more like another language.Apex, and Salesforce, would be best served by breaking its mimicking of Java and implement a new runtime that allows for multiple languages. Java is a daed-end language as it can't be improved without making its syntax more complicated. Already its become more complicated in terms of reserved words than many assembly languages.

  • Anonymoussays:

    January 29, 2012 at 5:28 pm

    Liked your point about Java, being a J2EE guy in past and Java being my first crush, I still have a soft corner for it. I was happy about the way Java was going since Oracle acquired Sun Ms, and then what's happening with upcoming versions of Java are not that exciting as it used to be. But, on the same side, I believe Java Virtual Machine is still a mature enterprise grade system to coin on many things, like Groovy, Jython etc, that means create any language with better features, but compile back to JVM byte code for all the stability and good ness. The same applies with Apex, as Salesforce is it self based on Java/J2EE and all environment is in place. So it would be easier for Apex to adopt the same, and that is actually happening too. Apex will no more compile to AST, but to JVM byte code now, that is a big step towards significant improvements in Apex as a matured language. But, on the same side I agree with your point, Apex can be like Groovy or Jython, why limit it to Java only.

Leave a Reply

%d bloggers like this: