The Force.com IDE is a powerful client application for creating, modifying and deploying Force.com applications. Based on the Eclipse platform and built on the Tooling API, the Force.com IDE provides a comfortable environment for programmers familiar with integrated development environments, letting you code, compile, test, package, and deploy all from within the IDE. Much of the actual work, such as compilation, happens on the Force.com platform—the Force.com IDE performs the communication and result parsing transparently.
The Force.com IDE is open-source. You can download the source code on GitHub. We look forward to seeing how the IDE develops as the community tinkers with it!
Apex Code The Force.com IDE is the only tool you need to write and manage Apex classes and triggers. The Force.com IDE locates syntax errors, and its Apex Test Runner executes unit tests and integrates error messages, debug output, and code coverage reports. Learn more about Apex.
Visualforce Create and edit Visualforce pages, components, static resources, and controllers. Learn more about Visualforce.
Application Components Download and edit all metadata components available in the Metadata API. Create Eclipse projects containing definitions of your Force.com schema, tabs, applications, and more! Edit these components directly in the IDE and changes are saved back to your organization automatically. Learn more about Metadata.
Development Lifecycle Develop and test your project against a Sandbox or Developer Edition organization, then deploy the finished application into your production organization with the Deploy to Server wizard. Learn more about Enterprise Development.
Online Project Mode Keep your local metadata files up to date with your Salesforce organization and easily detect and resolve conflicting changes.
Schema Explorer View your Salesforce organization's schema and construct and execute SOQL queries from within the Force.com IDE. Similar to the Apex Explorer, the Schema Explorer shows information about all standard and custom objects and fields.
Code Share Apply Force.com application lifecycle management best practices through integration with any Eclipse-enabled version control system. Teams can now collaborate on the development, testing and deployment of their PaaS applications.
Warning: If you upgrade the Force.com IDE before your org is upgraded to Spring ’16, the Force.com IDE can't fetch your organization details. See Salesforce Spring '16 is Coming Soon! Key Dates to Mark on Your Calendars for the Spring ’16 upgrade schedule. If you've already upgraded the plug-in and need to revert to a previous version, check out Error logging into Salesforce org with custom URL from Force.com IDE in the Salesforce Developers Discussion Forums.
Spring ’16 (Force.com IDE v36.0) contains the following updates.
You can now execute Apex test suites in the Force.com IDE. A test suite is a collection of Apex test classes that you run together. For example, create a suite of tests that you run every time you prepare for a deployment or Salesforce releases a new version.
To execute test suites, select Run | Run Configurations | Apex Test | New launch configuration (). Select the Test tab. To create a run of test suites, select Use suites, and then select one or more test suites. To execute the selected test run configuration, click Run.
To create or customize a test suite, use the Developer Console or the API. See Salesforce Help: Manage Sets of Apex Test Classes with Test Suites or Object Reference for Salesforce and Force.com: TestSuiteMembership.
Synchronous Apex test runs can include only one class. Because synchronous test runs are faster than asynchronous runs, all Force.com IDE test runs that include methods from only one Apex class are now executed synchronously. Test runs that include multiple classes are executed asynchronously as they always have been. Your test run configurations no longer include an option to configure synchronous or asynchronous execution.
Test results now load in the Apex Test Results view as your test methods finish executing. Previously, test results displayed only after all tests in the run had executed. If your test run’s results aren’t looking promising, you can stop your test run using the Progress view’s terminate icon.
If you expand test results in the Apex Test Results view before your test run finishes, the results collapse again when more methods finish executing.
To update your code coverage, execute Apex tests by selecting Run | Run Configurations | Apex Test. You can then view code coverage for your classes in the Apex Test Results pane.
To view code coverage highlighting, double-click a class name in the Apex Test Results pane’s Code Coverage list. Lines that aren’t covered by your unit tests are highlighted. Unlike the Developer Console, which color-codes both covered and uncovered lines, the Force.com IDE highlights only the lines of code that still need coverage.
To change the color for your uncovered code or to replace the highlighting with squiggly underlining, select Window | Preferences. Enter Annotations in the filter text box, then select Annotations | Apex Code Coverage. Make your desired changes, and then click Apply.
You can now filter which requests are debugged by setting up whitelisting. Previously, all events in your org triggered debugging during a debugging session. Now you can focus only on the events that are relevant to the problem you’re debugging.
To set up whitelisting, select Whitelisting Enabled in your Remote Apex Debugger configuration, and then filter by user ID or request type. To filter by user ID, enter a SOQL condition expression in the SELECT id FROM User WHERE field. Or enter a comma-separated list of user IDs in the text field in the User IDs section. To filter by request type, select one or more entry points, or enter a regular expression in the Entry Point Filter field. For example, to whitelist requests made by the Visualforce page myPage, enter .*/apex/myPage.apexp.
Typically, modifying an Eclipse debug configuration during a debugging session doesn’t affect active debug targets. However, whitelist modifications affect both current and future sessions.
You can now purchase Apex Debugger licenses for your parent org and share them among the users in your org’s sandboxes. In your parent org, view active sessions and revoke licenses on the Apex Debugger page in Setup. Revoking a license doesn’t prevent your user from initiating future debugging sessions.
JDT icons now display in the Apex Debugger’s Variables pane to denote access and definition modifiers for Apex variables. You can determine at a glance whether a variable is static, local, global, and so on. Previously, JDT icons displayed in the Outline pane, but all variables in the Variables pane had the same icon.
For a list of JDT icons, see JDT Icons in Eclipse’s Java development user guide.