jeanlaurent.getBlog()

I was very frustrated, so I’m sharing this in case it helps someone using the latest stable Eclipse (3.3.1.1) on MacOSX Leopard.

I have frequent “bus error” crashes (1 out of 5 use of ctrl-shift-t or r) to load file or resource from the classpath…

Due to the crashes and the manual browsing of classes (since open type won’t work) It’s almost impossible to be productive.

The error log (not in Eclipse, it’s in MacOSX Report bug window) looks like :

Current thread (0x005014c0): JavaThread "main" [_thread_in_native, id=-1604722848]
Stack: [0xbf800000,0xc0000000)
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j org.eclipse.swt.internal.carbon.OS.DisposeWindow(I)V+0
j org.eclipse.swt.widgets.Shell.destroyWidget()V+88
J org.eclipse.swt.widgets.Widget.release(Z)V
v ~RuntimeStub::alignment_frame_return Runtime1 stub
j org.eclipse.swt.widgets.Widget.dispose()V+23
j org.eclipse.jface.window.Window.close()Z+65
j org.eclipse.jface.dialogs.Dialog.close()Z+26
j org.eclipse.jface.dialogs.TrayDialog.close()Z+12
j org.eclipse.ui.dialogs.FilteredItemsSelectionDialog.close()Z+33
j org.eclipse.jface.dialogs.Dialog.okPressed()V+6

But today I stumbled upon this message from the eclipse mailing list stating that since version 3.4M3 (download link) a fix is available. This fix is not in the main trunk as for now.
I just tested it, and my eclipse looks more stable than ever.

I was looking for Eric Lefevre blog post for a pointer on an Eclipse plugin which performs an “optimize imports” (ctrl-shift-o) and “format source code”(ctrl-shift-f) each time you save a file (ctrl-s).

But I just discovered today that Eclipse is doing it natively, at least in the version I’m using (3.3m3 Build id: I20070222-0951). And it’s doing a little bit more things (including removing those pesky trailing whitespace) :

No need for a plugin for now on, and if you’re like, quite parano?�d when it comes to install plugin in your Eclipse install, this is a good news.

Apache Maven is great for building java application, it is especially good at dealing at project dependencies and the way they are used and packaged with a project. In the world of the Java applications there is also the guys who play it differently. OSGI based applications don’t deal with dependencies like any other “classical” java projects. For instance when you have a dependency in OSGI you can’t access all the classes of this dependency but only those for which the package has been exposed… This difference between classical and osgi app make difficult building an Eclipse RCP application 100% with maven. More exactly it was so easy to build it with their specific generated ant script, that it was rarely worth it.

This lengthy article at Eclipse Corner, is describing in great details how to build/test an Eclipse plugin with maven. It covers in depth how maven2 works, how eclipse works and what to do to make them work together effectively.

I’ve yet to try their solution which is almost solely based on custom plugins they have written to perform this specific task. I know that the maven team is also working towards supporting OSGI’s way of handling dependencies out of the box. There is also a plugin at codehaus which handles building Eclipse application from maven 2.

Links :

• Building Eclipse Plugins with Maven 2, Eclipse Corner Article
• Codehaus Eclipse PDE plugin

There is a short movie introducing the basics of test first development with eclipse (Eclipse 3.2) which is worth to see if you don’t know what test first is. It’s only 12 minutes long and only the first 7 minutes actually speaks about test first.

Test first development is actually an excuse to show Eclipse refactoring capabilities, (oh wait, it’s from Eclipse Evangelism web site…), but anyway it’s a good video to show to people wondering what Test First is, and how it works visually.

I didn’t know one of the eclipse hint shown during the demo, so even if you’re a seasoned eclipse user, you could learn something

07/09/2006: link was down, I corrected it.

How irritating is it each time when creating a new class in a fresh eclipse install to have to change manually the code template to match your name, since by default it uses you OS user name in the @author javadoc tag in front of each class.
It’s even worst when you look at someone else code, which I tend to do a lot these days. I see things like @author X8932398 or @author UV330993. ( Why on earth Windows Admin gives this kind of username is beyond my knowledge ( maybe a limit of the platform =X )
The base idea is smart, to fetch the name of the user who write the code. I tend to really like to know the author(s) of the code I read.

There is a small “hack” which can put anything you want in this ${user} variable.
Rather than having to change the template manually, add -vmargs -Duser.name="cleverUserNameIWantToUseInSourceCode" to the shortcut you use to run Eclipse ( by right clicking on it, selecting properties and editing the target input field) :

C:/java/eclipse/eclipse.exe -vmargs -Duser.name="cleverUserNameIWantToUseInSourceCode"

Have not seen any side effects since it’s uses
Thx Mat for the tip.