Eclipse Tricks

As many of you know that eclipse is an open source Java workbench (IDE) for the development of any kind of applications irrespective of language boundaries (thanks to its plug-in extensibility mechanism and easy way of hooking up any plug-in to the workbench). Many of the IDE's built on top of eclipse.

This article speaks about some of the tricks and tactics of eclipse workbench which might be useful for your development or debugging.... I will be adding some of the things incrementally to this post...

• Show memory heap status in the eclipse.   

                      Window -> Preferences -> General -> Show Heap Status 

• Show location of the workspace on top of the IDE (which is launched)

From Dev Environment:

Place '-showlocation' in the launch configuration

    Run/Debug Configuration -> Arguments ->

Example values:

    -os ${target.os} -ws ${target.ws} -arch ${target.arch} -nl ${target.nl} -consoleLog -showlocation

Also one can provide customized workspace for the IDE to get launched using the Main tab in the launch configurations.

    Launch Configuration -> Main -> click on Location link

From build:

If the workspace location should be shown for the IDE which is installed in your machine. Then provide same argument '-showlocation' in the shortcut from where it is being launched.

• Boost Eclipse IDE Performance on Windows     (http://jroller.com/agileanswers/entry/boost_eclipse_ide_performance_on)

-vm
C:\cygwin\usr\java\jdk1.5.0_08\jre\bin\javaw.exe
-vmargs
-XX:+UseParallelGC

• Open References in workspace :   Ctrl + Shift + G

• Know all shortcuts    (Ctrl + Shift + L)

• Explaining How Builds Work to Users        -    http://www.eclipse.org/eclipse/platform-core/documents/scoped_builds.html

You have two modes of working: auto-build mode and manual build mode. By default, you are in auto-build mode and Eclipse takes care of compiling source files automatically. Builds occur automatically in the background every time you change files in the workspace (for example saving an editor). Auto-build is convenient because it means problems view, binaries, etc. are are up-to-date at all times. The downside is that in large workspaces auto-builds can be time-consuming if you are changing files in projects with lots of downstream dependent projects.

If auto-build is taking too long and is interfering with ongoing development, it can be turned off. Once in manual build mode, the user is in complete control over when builds occur and what gets built. Project > Build All (Ctrl+B) can be invoked at any time to trigger what auto-build was doing automatically. This allows you to build up a larger set of changes before invoking a build (Eclipse remembers which files have changed so that it does not have to do more work than required when you do ask for a build.

In large workspaces, building the entire workspace can take a long time if you make changes with a significant impact on dependent projects. Often there are only a few projects that really matter to you a a given time. You can now simply select the project or projects that you want to bring up-to-date, and select Build Project from the context menu or Project menu. This will build only the selected projects, and any prerequisite projects that need to be built in order to correctly build the selected projects. Projects that depend on the projects you build will not be built. If you're familiar with the make tool, or Ant, they work the same way.

If you're interested in a set of projects, you may find it inconvenient to be repeatedly selecting several projects in the Navigator. In this case, you can choose Project > Build Working Set > Select Working Set... and choose a working set that contains the projects that you want to have built. This has the exact same effect as selecting that set of projects in the Navigator and selecting Build Project. Again, prerequisite projects will be built automatically if necessary. Recently built working sets appear on the Project > Build Working Set > submenu, making it fast to switch to any of these. You can allocate a key binding for the command Repeat Last Working Set Build in the Project category of the General > Keys preference page, if you want a convient way to invoke a working set build.

Under normal circumstances, you should have no reason to use the Clean command. Eclipse builders are generally incremental - they only build files that have changed since the last build, or files that are affected by changed files. This makes Eclipse builds very efficient even when there are large numbers of files. If something goes wrong and Eclipse loses track of where it was, this incremental process may fail to bring a project up to date. If this ever happens, the Clean command is there so the user can manually intervene and set Eclipse back on the tracks. This ensures that the next build will recompile all files over from scratch, as if the builder was running for the very first time. Naturally, this can be time consuming for large workspaces. You can selectively Clean one or more projects if you know which projects are having problems building.