06 Apr Difference between Apex and java
Apex is a proprietary programming language provided by the Force.com platform to developers similar to Java. It is a strongly typed, object-oriented, case-insensitive programming language, following a dot-notation and curly-brackets syntax. Apex can be used to execute programmed functions during most processes on the Force.com platform including custom buttons and links, event handlers on record insertion, update, or deletion, via scheduling, or via the custom controllers of Visualforce pages.
The following is a list of the major differences between Apex and Java:
- No packages (except when code is packaged for deployment).
- Code is case insensitive so it is very easy to get name clashes e.g. a variable “map” clashing with the type “Map”. The reserved words in the language are reserved largely irrespective of the context they are used in. You end up adding arbitrary name variations to work around this.
- The governor limits on how much code can be run per request mean that there are restrictions on what sort of algorithms you can build.
- Building frameworks and abstractions is unsafe: gains in code cleanliness are worthless if they result in the application hitting any of the many governor limit brick walls. Perhaps related to both the governor limits and the lack of any lightweight library mechanism there is a negligible amount of useful shared library code available.
- Debugging tools are improving but are limited.
- Little unit testing infrastructure beyond a few assert methods and a @isTest annotation so Test Driven Development is harder.
- No switch statement.
- Enum support is very basic.
- No char type – have to substring out a single character string to steps through strings.
- toString isn’t marked as virtual so can’t be overridden.
- String format methods are limited and parse methods are not provided.
- A List is not an Object. So you can’t return lists of objects from methods of return type Object.
- You can’t throw Exception, you have to sub-class it. You can’t add constructors to your exception.
- No anonymous inner classes. Can only nest inner classes one level deep. Inner classes cannot reference fields of the containing class – they are like static inner class in Java. So it is really just playing with the name of a class – qualifying it by the containing class name.
- Static members only have request scope so can’t be used for e.g. caching across requests.
- The architecture keeps the server-side code stateless and so offers no mechanisms like Java’s HttpSession interface.
- Only one type of List, Set and Map. No Collection super class, so have to explicitly use List or Set.
- The == operator tests for value equality and the === operator tests for reference (memory location) equality (on SObjects and collections).
- When a large amount of processing needs to be done you have to move to using Asynchronous Processing in Force.com. Writing tests then becomes a challenge as asynchronous processing in the test context is very limited.
- No IO available except HTTP access to external resources that have to be nominated. No way to find the URL of a static resource (e.g. a resource called “A” is at “/resource/1264356232000/A” – according the Visualforce URLFOR) or open it in Apex code (to do e.g. programmatic content merging). Correction: there is this technique that allows file or zip file content to be read via a PageReference if a prefix of “/resource” is added.
- No way to sleep in Apex code making any kind of polling in Apex hard to accomplish.
“Know more about Salesforce Consulting at Techila”