.::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.

This is actually something that I spent two days on trying to get to work properly. There were a couple of variables that made this harder than necessary: the documentation on getting the latest version of Photran to compile was a bit out-dated (we need the latest version of the CDT from HEAD for the tests to run) and the fact that we are switching to Eclipse 3.3 which might not work well with all the plug-ins out there.

The plan was to run some metrics and code coverage measurements on the Photran code base. Using the data that we gathered we could evaluate sections of code that needed refactoring and/or testing. We could only use free tools since we wanted the students to be able to run them on their own computers. Naturally, if we did not have this major restriction we would have chosen some better commercial tools.

The State of Flow Metrics was the first one I tried but it does not do a good job. The UI and visual feedback were so bad that I did not even know if it was working. So, I ran the tool on a smaller project; it completed the analysis. However the information it provides is not presented intuitively. Instead it adds a little icon on the left margin of the editor that does nothing more than indicate that it had analyzed that method. Then the data is presented in the Problems view along with all the other errors and warnings. For small projects, this is fine but for larger ones with 100s (or 1000s like the CDT) of warnings, you cannot even determine which are warnings from the metrics tool (vs warnings from the Java compiler). So this is pretty much useless for large projects or workspaces with 1000s of warnings. It has an export feature that is supposed to export the data to HTML and CSV forms but it refuses to complete for me.

The second metrics plug-in I tested was much better. It had failed to work the first time I used it because it was not able to access the data that it had collected from the analysis. However, after upgrading to the latest version of Eclipse 3.3 (Version: 3.3.1 Build id: M20070921-1145) this problem vanished.

Metrics view using the Metrics Eclipse plug-in

So, now we needed a code coverage tool or more specifically one that could analyze the tests that have been written for Photran. This is slightly more tricky. We need code coverage tools that can measure coverage on JUnit plug-in tests (vs the normal JUnit tests). JUnit plug-in tests must launch an instance of Eclipse to successfully execute to completion. So a majority of the test coverage tools mentioned here cannot do a decent job.

For instance, in Photran, if you just ran the normal JUnit tests there are only 125 such tests vs 1566 if you run the JUnit plug-in tests. So the coverage is going to be low for the former execution.

There was only one free tool that I could find that offered support for measuring JUnit plug-in tests: EclEmma. The first time I installed EclEmma it corrupted my entire workspace and I had to restore everything from the repository. I installed EclEmma again today on the latest version of Eclipse 3.3 and I think I know the proper way to invoke it so that it will not corrupt the workspace: always create two different run configurations and never mix them. So, when running the Photran, you should always create 2 configurations — one that EclEmma will run and one that normal Eclipse will execute without coverage. And the workspace should also always be cleaned after running EclEmma.

EclEmma code coverage in action.

I believe that the Eclipse update fixed something to make EclEmma work properly on Mac OS X. Yesterday, there was no clean separation of an EclEmma run-time from a normal run-time. In fact, both of them were always merged in the same dialog. This could be why the workspace was being corrupted since EclEmma's instrumentation was replacing the normal ones.

Bottom line, if you want to a good metrics and code coverage tool, go with the Metrics and EclEmma plug-ins. Of course, if you can afford it, go for a commercial tool like Clover.

One would expect that that given the popularity of Eclipse that there would be an easy way to setup Struts with it. However, this does not seem to be the case. There are various resources on how to use some non-standard Eclipse installation (EasyEclipse, MyEclipse) or some outdated plug-in (StrutsConsole, EasyStruts). But it is really hard to find one on how to use a standard Eclipse installation. The definition of what is a standard Eclipse installation is debatable since there are just so many different combinations of it.

In fact, here is a list:

• Developing Struts with Easy Struts for Eclipse
• First Struts Tutorial using Eclipse, MyEclipse
• How to setup a basic Struts project using Eclipse IDE - this one actually comes pretty close to what I need but it is outdated.

However, in my case, I would like just like to use a simple installation that just enables me to launch my Struts application from within Eclipse. I don't really need any of the more complicated features. If I needed those features, I would be using IntelliJ which has great integration with Struts (and almost everything else that you usually use Java with e.g. Hibernate, Spring, etc) built-in.

Fortunately, I found this thread after some searching. The instructions are a bit terse but you can definitely follow along with some trial and error. Just make sure that you have one of the supported servers installed. In my case, I was using the Apache Tomcat server but there are adapters for other servers as well. Also, make sure that you follow (or to be more specific, obey) the folder structure imposed. It's a pretty conventional and there should not be a reason to not put things in their recommended folders.

All that is required is to have the Web Tools Platform (WTP) plug-in installed. My past experience with installing the Web Tools Platform had me downloading a whole bunch of required plug-ins before it could work. Needless to say, it was not a pleasant experience. So I was happy to see that they have released all-in-one package for the WTP project here. This is definitely a time-saver. The WTP is a comprehensive project that is maturing toward the usability and stability that one associates with the Eclipse Java Development Tools (JDT).

Now that everything is working - after much time-wasting - I believe that I have reconfirmed my view that having too many choices is not always good! It's really annoying when all you are trying to do is get some prototype up quickly and you are not able to do that because you have to make a decision between product A, B or C. Sure you can go ahead and read the comparisons and user reviews but most of it is not going to make that much sense to you if you have never used similar products before. And the reason you have never used them before is because you are just beginning to create your first prototype!

I find the situation of having too many choices to be really prevalent in the Java world. I am not against having different choices but I know that when I am just beginning to use some new tool, I would really like everything bundled together so that it just works out of the box! I don't want to select product AA only to be told that before I can use product AA I need to install either product A.1 or product A.2! Just give me a working combination that I can quickly use to see if my prototype can even work in the first place!

And don't get me started on the XML configuration files that are necessary before you can begin running that Java application....

One would expect that that given the popularity of Eclipse that there would be an easy way to setup Struts with it. However, this does not seem to be the case. There are various resources on how to use some non-standard Eclipse installation (EasyEclipse, MyEclipse) or some outdated plug-in (StrutsConsole, EasyStruts). But it is really hard to find one on how to use a standard Eclipse installation. The definition of what is a standard Eclipse installation is debatable since there are just so many different combinations of it.

In fact, here is a list:

• Developing Struts with Easy Struts for Eclipse
• First Struts Tutorial using Eclipse, MyEclipse
• How to setup a basic Struts project using Eclipse IDE - this one actually comes pretty close to what I need but it is outdated.

However, in my case, I would like just like to use a simple installation that just enables me to launch my Struts application from within Eclipse. I don't really need any of the more complicated features. If I needed those features, I would be using IntelliJ which has great integration with Struts (and almost everything else that you usually use Java with e.g. Hibernate, Spring, etc) built-in.

Fortunately, I found this thread after some searching. The instructions are a bit terse but you can definitely follow along with some trial and error. Just make sure that you have one of the supported servers installed. In my case, I was using the Apache Tomcat server but there are adapters for other servers as well. Also, make sure that you follow (or to be more specific, obey) the folder structure imposed. It's a pretty conventional and there should not be a reason to not put things in their recommended folders.

All that is required is to have the Web Tools Platform (WTP) plug-in installed. My past experience with installing the Web Tools Platform had me downloading a whole bunch of required plug-ins before it could work. Needless to say, it was not a pleasant experience. So I was happy to see that they have released all-in-one package for the WTP project here. This is definitely a time-saver. The WTP is a comprehensive project that is maturing toward the usability and stability that one associates with the Eclipse Java Development Tools (JDT).

Now that everything is working - after much time-wasting - I believe that I have reconfirmed my view that having too many choices is not always good! It's really annoying when all you are trying to do is get some prototype up quickly and you are not able to do that because you have to make a decision between product A, B or C. Sure you can go ahead and read the comparisons and user reviews but most of it is not going to make that much sense to you if you have never used similar products before. And the reason you have never used them before is because you are just beginning to create your first prototype!

I find the situation of having too many choices to be really prevalent in the Java world. I am not against having different choices but I know that when I am just beginning to use some new tool, I would really like everything bundled together so that it just works out of the box! I don't want to select product AA only to be told that before I can use product AA I need to install either product A.1 or product A.2! Just give me a working combination that I can quickly use to see if my prototype can even work in the first place!

And don't get me started on the XML configuration files that are necessary before you can begin running that Java application....

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.