Archive

Archive for the ‘eclipse’ Category

Running Code in Eclipse the Lazy Way

December 15th, 2008 No comments

I’m pretty happy working in Eclipse. Today I’ll share one of my favorite “workhorse” keyboard shortcuts.

So say you’re editing some unit tests (you are writing unit tests, right?) for a particular class and you want to run them. Of course, you’ve set up a launch to run all the tests in your project, but you have so many tests that you don’t want to sit through them all for this one little test. Try this instead:

    alt+shift+X and then T

Yay the tests in the current file were just run. So let’s decode that. “alt+shift+X”. X is for eXecute. Now what is “T” for? Oh yeah, Test. Execute test. That’s way faster than right-click, run as, JUnit test, etc. Or finding the JUnit view and clicking “run again”.

Now what if you wanted to debug? I can guess that the shortcut will end with a “T”. What does it start with though?

   alt+shift+D and then T

Nice. So “alt+shift+D” means debug.

Ok, now if I’m just editing a plain old Java file with a main() method, i.e. I’m testing by hand (bad boy!) what should I do?

   alt+shift+X and then J

Of course it starts with execute, and then “J” for Java. Similarly, if I want to debug:

   alt+shift+D and then J

Cool. Now do that a few hundred times until it’s in muscle memory and you stop using your mouse like a sucker.

Note that these shortcuts not only work in the active editor, but on selected resources. Select a class in the Package Explorer and try it out.

Bonus Shortcuts

So now you’re starting your debug session without the mouse. Don’t waste your time clicking those step buttons:

  • Step Into – F5
  • Step Into Selection – Ctrl+F5
  • Step Over – F6
  • Step Return – F7
  • Resume – F8

I have to admit these have been harder to get down after so many years in Visual Studio. Way it goes.

p.s. I realize these are kind of obvious, but sometimes I don’t do something unless someone tells me to, which may hold for others as well. :) Also there are actually shorter shortcuts for things like debugger (F11 I think), but I like mnemonics.

Categories: eclipse Tags:

Running javadoc Ant task from Eclipse

December 9th, 2008 25 comments

All things being equal, I like projects that build out-of-the-box. That is, given a clean checkout from revision control, a project should just build without requiring too much customization: setting environment variables, installing third party software, modifying the system path. I’m especially sensitive to this at the moment because I’ve just finished up five days (actually maybe 30 hours all together) getting one particularly horrible system to build.

Along these lines, I added a javadoc task to an Ant build script today and tried running it from Eclipse. Just for the record, that procedure is as follows:

  • Open build.xml
  • Right-click the task in the Outline View
  • Select Run As->Ant build.

Interestingly enough, this failed with the following error:

build.xml:208: Javadoc failed: java.io.IOException: Cannot run program
"javadoc.exe": CreateProcess error=2, The system cannot find the file
specified

A quick Google search reveals several suggestions that the solution is to make sure that javadoc.exe is on the system path.  First, it’s a little ridiculous that Ant can’t find javadoc from JAVA_HOME when it clearly uses the same mechanism to track down javac. Oh well. Bygones. Second, returning to the idea of builds that “just work”, I don’t want to modify my system path. What if I have several JDKs installed, used with several different projects simultaneously?

So, how do we get javadoc onto the system path without modifying it? Simple, modify the path in Eclipse. This time, run the Ant task with the following procedure:

  • Open build.xml
  • Right-click the task in the Outline View
  • Select Run As->Ant Build …

That elipsis at the end is important. This will bring up the Eclipse launch configuration dialog. Give your new launch configuration a name, like “Build <Project Name>” or something and switch to the Environment tab. Here you can specify the environment for Ant. But we don’t want to kill the whole system path, just prepend the location of javadoc.exe to it. So click New… and enter Path for the name and the following for the value:

   ${env_var:JAVA_HOME}/bin;${env_var:Path}

This prepends JAVA_HOME/bin to the current system path. Now click Run and everything should work fine. Yay.

Now, when someone else checks out the project you don’t want them to have to go through the same hassle. It’s still a hassle, just inside Eclipse instead somewhere else on the machine. The solution to this problem is to save the launch configuration!  Return to the launch configuration screen and open the Common tab. There you can select to save the configuration as a shared file. I usually save it in tools/launches. The resulting file will have a .launch extension. Commit the launch file to version control. Now anyone who checks out the project will have a properly configured launch configuration to build the project. No fuss, no muss.

Also note that this is a much more general purpose solution. It applies to any launch configuration where you need to modify the path, or set any kind of environment variables.

Possible Issues

There are a few potential issues I can think of:

  • That semi-colon in the path string may not work on non-Windows systems. I’m not sure if Eclipse is smart enough to fix that.
  • In the past, I’ve had trouble with the case of environment variables and Ant.

Also, I believe that an alternate solution to this problem is to register the JDK in Eclipse. This is ok, but it’s nice to not require it.

Categories: eclipse, java Tags: , ,

The Eclipse Reconciler

November 1st, 2007 5 comments

One aspect of implementing a text editor in Eclipse that I’ve found to be tricky is the reconciler. In this post, I’ll detail some of the lessons I’ve learned. I’m assuming you’ve gotten as far as creating a basic editor. The reconciler is a background process in your editor responsible for updating your model when the user takes a break from typing. The kinds of things it should update are:

  • Elements displayed in the outline view
  • Error markers
  • Folding regions

Some editor programmers don’t seem to know that the reconciler even exists. They usually take one of two approaches: update the entire model on every keystroke or update the model only when the user saves. Neither of these is very satisfying, especially for users familiar with editing Java in Eclipse. The former approach leads to poor performance on large files. The latter requires the user to save constantly to find out whether errors exist or get an up to date outline.

So, how does the reconciler work? The reconciler runs as a background thread in Eclipse. It sets a timer which will trigger a reconcile whenever it expires. Each time the user types a keystroke, the timer is reset. In this way, the user can type a great deal of text without being interrupted by the reconciling process. Once the user pauses, as all humans must, the reconciler’s timer expires and the model is updated.

Creating a Reconciler

Eclipse uses the strategy pattern to separate the timer/keystroke logic from the details of updating your model. The MonoReconciler is the simplest implementation of the timer/keystroke logic. It is configured with an instance of IReconcilingStrategy which is responsible for updating your model, i.e. you implement this interface.

The basic procedure for setting up your reconciler and reconciling strategy are:

  • Implement IReconcilingStrategy. You’ll want to implement the non-incremental version of reconcile(), i.e. reconcile(IRegion partition). More on this below.
  • In your editor’s SourceViewerConfiguration, override getReconciler() to return an instance of MonoReconciler, initialized with an instance of your reconciling strategy and isIncremental set to false

That’s it. Now when your editor is created, your reconciler will be initialized and the reconcile() method will be called whenever the user modifies the document. I usually store a reference to the editor itself in the strategy object.

The Reconciler Runs in Its Own Thread!

It’s important to always remember that the reconciler runs in its own thread, as with most stuff in Eclipse. It’s safe to access the document, but there are few other things you need to keep in mind:

  • All SWT/JFace operations must be executed in the UI thread. So, if you want to update your outline view after a reconcile, you’ll have to use Display.asyncExec().
  • Your model also has to be thread safe. If it’s being update in the reconciler thread and read from in the UI thread to update the outline view, you’re going to need some synchronization.
  • It is safe to add warning and error markers to the file from the reconciler thread

If your model is simple enough, one simple solution to this problem is to have the reconciler construct an entirely new model each time it runs and then pass it on to the editor with Display.asyncExec(). This way there are no shared objects between the threads and thus, no syncrhonization problems.

What if the user doesn’t start typing right away?

After you’ve implemented your reconciler, everything will seem great. Great until you (or a user) decides to just view a file without editing it. They’ll find that their outline view is not updated. Same with folding ranges, etc. The problem is that your reconciling strategy is not run until the document is actually modified. Go figure. If only there was a way to tell the reconciler, “Hey, how about an initial reconcile pass on the document right when it’s opened?”.

Fortunately, a friendly Eclipse programmer also thought of this question. Rather than implementing IReconcilingStrategy, try IReconcilingStrategyExtension. This adds an initialReconcile() method where you can do an … well, you get the idea.

What about the incremental reconciler?

If you poke around in the reconciler interfaces a bit you’ll notice there are actually two modes of operation. The non-incremental mode simply tells you that the document has been modified with little additional information. The incremental mode tells you about what’s changed in the document each time that reconcile() is called. It tells you when text has been added or removed and from where in the document. That sounds pretty useful!

On my last Eclipse editor project, I wanted to take advantage of this. If I knew which part of the document has changed, I could just reparse that section and update the affected model elements. I actually foolishly went through all the trouble of implementing this logic and then gave it a try. Things did not work as I expected. There is a fatal flaw in the incremental mode: By the time the reconciler is called, the document may have been modified further so all the modification information is provides is basically useless!

I believe this is caused by two factors. First, because it is multi-threaded, it’s hard to lock the document and still maintain the “update in the background” semantics of the reconciler. Second, the incremental reconcile() method only provides information about a single modification, i.e. an insert or delete in the document. So if the user does the classic “insert character + down arrow” editing technique to say comment out a bunch of lines, the reconciler will get called for each individual change, but the document will already contain all the modifications when the first reconcile call is made. D’oh.

When I realized it works like this, I did a bunch of searches on Eclipse newsgroups, google code, etc. I came to the conclusion that either no one has ever actually used the incremental reconciler, or they have and then silently slunk back to the non-incremental version when the found this fatal flaw.

If I’m wrong about this, I’d love to hear why!

Categories: eclipse, java Tags: