.::output >> /dev/null::.

This was something that I really wanted to blog about for a long time...

Last year I wanted to know a way to save sessions in Eclipse like I could for Firefox. For instance, Firefox allows you to save the open tabs and windows into a new session and restore that session in the future. That way if you ever need to recall a set of tabs for reference, they can be easily activated by restoring the saved session.

In fact, any decent, editor or IDE should the option to save sessions. Heck, Vim and Emacs have this feature out-of-the-box. Sessions are really useful when you have to work on groups of related files at the same time but don't want to have to remember which they are.

So why was there apparently no way to do this in Eclipse? Initially, I thought that Working Sets might be the solution. However, they only allowed you to group files into sets. They don't actually remember the editors that are opened and what state you were in. So Working Sets were not even a poor man's implementation of sessions.

Then epiphany struck! We could use the Mylyn plug-in to accomplish this. In fact, as you shall see, Mylyn can do even better than just saving sessions - it infers them automatically based on what you are doing! Mylyn comes installed standard now on Eclipse 3.3 and higher. In fact, the Mylyn view is even shown by default; it's not activated though.

Anyone who does not use sessions has a) an incredible memory, b) an inhumane ability to do context switching between tasks AND c) the luxury of not having to close his IDE ever. Or the developer just doesn't know that such an excellent tool exists out there...

This is Mylyn
I have readjusted my perspective a bit so that everything can fit nicely in a 800x600 window. The picture above shows the Mylyn view with some sample local tasks.

Activating a previous session
I am activating a previous session. By default, Mylyn automatically remembers the last context that you were in before closing the editor and will restore that.

Previous session restored
You can see that Mylyn remembers the files that were opened in that session and has restored them in the editors. The current active task (see the Task List view) has a blue bullet next to it. In the Package Explorer view, you can even see the other files that I might have referred to in a previous session but did not open in any editor.

Creating a new local task (context)
Mylyn allows you to create local task for your own use. With the proper server, you can also create sharable tasks in a Bugzilla or JIRA repository. That way, you can share the same session with yourself when you are working on a different machine or with your other teammates so that they can take a look at the same things that you are looking at.

Editing a local task (context)
You can easily associate other metadata with each task. In fact, Mylyn was originally created to be a task-oriented system. It allows you to split your work into little tasks to help you focus.

Deciding to show everything or just the active task
You can easily switch between showing all the files in the Package Explorer or focusing on the active task by clicking on the Mylyn button.

Mylyn has a whole bunch of other features. Some of the interesting ones include:

• The ability to share a context with different tasks. You can clone the current context and paste it into a different task.
• It cleverly remembers what editors and files that you have accessed and stores those into its session.
• It intelligently forgets editors and files that you have not looked at for extended periods.
• You are always in control - you can override the behavior easily and promote/demote certain files from sessions.
• It records how long you spent on each task so that you can actually report that figure with certainty.
• It's well integrated with different perspective and views in Eclipse. And it is constantly being improved upon.

Mylyn is great for helping you focus on your programming tasks. It stays out of your way for the most part but is easily accessible when you need it. Once you start using it, you really wished that every IDE out there (including the venerable IntelliJ) supported it.

I have been using Eclipse as my primary Java IDE for some time now. I like most of the features that it offers. However, to get the best performance you have to forgo everything you know about low memory requirement software. Eclipse is not one of those. In fact it is a memory hog.

In fact, if you just use Eclipse straight out the box, you are probably going to feel that is the most sluggish IDE around. This sluggishness is not limited to Eclipse only though (more on this below). So, to get the best performance, you have to weak the settings for the amount of memory that it uses to counteract the effects of Java's garbage collection.

In OS X, you want to hunt for the file eclipse.ini. You can find this file in Eclipse.app/Contents/MacOS/eclipse.ini. To get to that folder, you need to right-click on Eclipse and select "Show Package Contents". Find the lines that read -Xms<some_number> and -Xmx<some_number>. The former number represents the minimum heap space size and the latter refers to the maximum heap space size. Change the numbers to something more reasonable like 256 for the minimum memory and 512 for maximum memory. If you run Eclipse now you will feel the difference.

Just a couple of days ago, I downloaded IntelliJ IDEA touted as the most intelligent Java IDE. Well, it does live up to its name. The error and warning messages convey clearer meanings compared to the ones in Eclipse. However, using it out-of-the-box was a bit of an experience. IntelliJ IDEA has a very conservative initial heap space allocation - a meager 32MB. That is definitely not enough. After a couple of minutes of using IntelliJ, it was already doing its garbage collection!

So, it is time to tweak the VM. In OS X, hunt for the file IntelliJ IDEA <some_version>.app/Contents/MacOS/info.plist. info.plist is a XML file that you can open in a text editor. Look for near the end of the file for the VMOptions key and change its string value to something like this. Unix and Windows users can refer to this page to get the location of the configuration file.

Note that the developers of IntelliJ also agree that the default memory settings are not always the best for your larger projects. Therefore, they have also posted an >a href="http://blogs.jetbrains.com/idea/2006/04/configuring-intellij-idea-vm-options/">article on their blog that details the settings that they use. An important fact that they point out is that allocating a lot of RAM to IntelliJ is not always the best choice since the garbage collector might have to potentially free up a whole bunch of stuff all at once.

IntelliJ has a lot of non-commercial plug-ins available but the better and more complicated ones are usually commercial. These commercial plug-ins can cost more than an academic license for IntelliJ. Their exorbitant cost is one good reason why I will still have to use Eclipse for certain tasks. Another reason is the total number of plug-ins: Eclipse has way more plug-ins than IntelliJ. The last time I checked, there were 827 plug-ins for Eclipse and 370 plug-ins for IntelliJ. That is more than twice the amount so if you are looking for a plugin for some language you are more likely to find as an Eclipse plug-in.

Lots of Java frameworks rely on configuration files to function. These configuration files are usually written in XML (which I still strongly believe is not human writable). Whilst the IDE usually provides nice auto-completion features for these configuration files, it is not able to reflect refactoring changes made to the Java source files. For instance, if the XML file refers to com.vazexqi.sample.Class and I rename it to com.vazexqi.sample.Class2, the XML file is not updated. I wish to study the feasibility of adding refactoring awareness for these configuration files in the Eclipse IDE. For starters, I will try to hack around with the Hibernate Tools plugin.

In case anyone is interested in following along, here are some of the steps that I have taken to get started.

Getting Hibernate Tools

I use the Help > Find and Install... feature in Eclipse to install Hibernate Tools. The site URL for Hibernate Tools is http://download.jboss.org/jbosside/updates/development/. There is nothing there for your web browser to load; it contains a site.xml for Eclipse to discover new features. Over the past few days I have had some trouble accessing the site so be patient if you cannot reach it as well. There are three major dependencies that Hibernate Tools has: Visual Editor, Eclipse Modeling Framework and Web Tools Platform (WTP). When you first try to install Hibernate Tools, it will warn you of those dependencies. So you will need to go grab the relevant plugins first. The three of them are listed under Callisto Discovery Site. After installing Hibernate Tools, it is a good idea to find out what features its XML editor provides. I followed the tutorial on the Hibernate website.

There is no need to grab JBoss Eclipse IDE, just Hibernate Tools will do.

The XML editor is based on the one from the WPT plug-in. The original WTP XML editor supports completion based on the XML schema (either DTD or XSD; I don't think it supports RELAX NG). Hibernate Tool extends it so that it supports completion for Java class names for the relevant attributes in a XML tag. Completion is suggested via the normal key sequence: CTRL + space.

I played around with Hibernate to discover what features the XML editor supports. This will help me when I need to hack it into submission.

Getting Hibernate Tool source code

To ensure that the version of Hibernate Tools you installed does not interfere with the source code when testing, you should disable it. The easiest way to do so, is to go to Help > Manage Configuration and select Hibernate Tools from the list on the left hand side of the screen. Click disable. You should be prompted to restart Eclipse. When you restart Eclipse, it will no longer load Hibernate Tools. If you need to load it again, you can always follow the steps again but this time select "enable" for Hibernate Tools. You need to select the third icon from on the toolbar to see the disabled plugins.

To start hacking away you need to get the source code from the JBoss CVS repository. There are some instructions here.

I used a slightly different route. I switched to the CVS Repository Exploring view and browsed the CVS repository at anoncvs.forge.jboss.com:/cvsroot/jboss. I then selected the following packages (individually) from HEAD/jbosside:

• org.jboss.ide.eclipse.freemarker.feature
• org.hibernate.eclipse.updatesite
• org.hibernate.eclipse.test.feature
• org.hibernate.eclipse.releng
• org.hibernate.eclipse.feature
• org.jboss.ide.eclipse.freemarker
• org.hibernate.eclipse.mapper
• org.hibernate.eclipse.jdt.ui
• org.hibernate.eclipse.jdt.apt.ui
• org.hibernate.eclipse.help
• org.hibernate.eclipse.console.test
• org.hibernate.eclipse.console
• org.hibernate.eclipse

The freemaker packages are not really required but without it I get some configuration errors when I run Hibernate Tools and try to manage it with Help > Manage Configurations.

At this stage, you should be able to run the packages above as a single Eclipse application. Make sure that the WPT plug-ins are enabled since there is a dependency for it.

Over the next few days I will be looking at the source code and seeing how Hibernate Tools offer completion for Java class names. From here I will try to find out how the information is embedded (it cannot be in the DTD or XML schema since that form has to remain compatible with other applications that use it). Next, I will try to register the plugin to receive notifications whenever a refactoring (rename, move, pull-up, etc) has been done and modify the referenced Java classes in the XML file.

Hopefully after this I will get a better idea on how to develop a general framework that will allow support for different types of configuration files.