What's new in the SWT for Eclipse 3.7

A lot of Mac stuff but a few items seemed important:

• on Win7, taskbar items show Job image as overlay. We need to attach images to our Jobs even without Win7 because they appear in the Progress view. And we'll be done when we do move to Win7.
• SWT.WRAP now works for Buttons of all styles (e.g. SWT.PUSH, SWT.CHECK, SWT.RADIO).
• can now set preset of duplex when printing. We should test our dusty old Jasper will do this.
• WebKit now default browser if it's installed.
• Touches and Gestures now supported but I don't think we're there yet.

10 Techniques to Test a Plug-in

This guy was full of good ideas. He's putting together a blog that will have code samples and more details on testing:

1. MANIFEST.MF using OSGi PlatformAdmin service for basic identity values and dependencies
2. plugin.xml, e.g. parsing extension points .exsd files to determine attributes then testing extensions for valid values
3. commands and handlers using ICommandListener and IExecutionListener
4. views and editors using IWorkbench and reflection
5. a PropertyTester by parsing its extension to drive tests using IEvaluationService with various values
6. a SourceProvider, testing its variable is the same when obtained from the extension, the implementation class, and from its current state
7. expressions as used in a plugin.xml using the IEvaluationService with various contexts
8. dialogs and wizards using Display.timerExec()
9. unwanted messages using an ILogListener and replacing the default system.out stream

His blog is at http://blog.rcp-company.com/ and I will definitely be checking back with this guy.

Getting Eclipse Preferences Under Control in Teams

An exploration of free tools that aid in maintaining preferences in a team environment. Three solutions were described:

1. "Eclipse Team Etceteras" - a feature that prompts the user on startup of a new workspace to install preferences from the location specified in a fragment. Also allows when switching workspace to copy preferences in the switch. More information here.
2. "Workspace Mechanic" - a more invasive but capable feature that is task oriented and can manage preferences, java files, and plugins. File-based with HTTP function not yet released.
3. "Common Preferences" aka bug 334016 - an eclipse project than handles preferences and can optionally lock them down.

I think #2 sounds like work to maintain. I think #3's capability of locking down preferences is too heavy handed but we wouldn't need to use it and it is an eclipse project so the future is probably good. #1 sounds quite simple and probably does the job needed. I'd like to hear what the rest of the team has to say on this.

Commands in Eclipse 4: Understanding who does what

Complementary to Commands in Eclipse 3.x: the 10 most common pattern.

A description of the Command Framework in Eclipse 4.x. Much of it remains the same; the command is still an abstraction for a semantic operation, still declared as an extension as are the handlers and menus that reference it. Expressions are still used for visibleWhen, activeWhen and enabledWhen statements.

The big difference is in the handler implementation and its supporting API:

• An @Execute annotation is used on the method to be invoked.
• Optionally, an @CanExecute annotation can be used on a method called by the framework to determine enablement.
• Most objects needed by the handler are to be injected using:
  
  • @Inject (for service by interface)
  • @Named (for variables, e.g. selection)
  • @Preference (for the handler's plugin's preference store)
• An IEclipseContext is used extensively.

I missed how the IEclipseContext is to be obtained but it is core to the Eclipse 4.x Workbench model and most Eclipse 4.x development, not just the handlers. It's hierarchical and can be traversed. The handler executes in the last active context, usually a ViewPart. In the model it is a leaf under a Perspective which is under a Window which is under the Application root. The effect of this hierarchy is that a command's state, which was global in 3.x, is contextual in 4.x and can be one of many. In 3.x a command was either enabled or disabled and if there were two menu items in two separate views for a single command, e.g. print, they were both either enabled or disabled... which often made no sense. In 4.x they are separate contexts and so individual states.

It's comforting that plugin.xml extensions can probably be left as they are and that only the handlers need migration. Though the injection and context use is radically different, it is also apparent it is leaner code and that, once learned, is portable to the rest of RCP development.

Commands in Eclipse 3.x: the 10 most common patterns

A description of the different ways of using the Command Framework in Eclipse 3.x. I think our group has used them all and I believe we've done so properly. They are:

1. Simple command with a default handler and a simple menu contribution for it.
2. Providing static parameters to commands.
3. Specifying a toggle state for a command.
4. Specifying a radio state for a command.
5. A pulldown command with sub-menu items.
6. Dynamic menu contribution.
7. Using "activeMenuSelection" in an expression.
8. Adding a control to a toolbar - not sure if we've done this but I've seen it.
9. PropertyTester.
10. Calling Command Framework API, e.g. programmatic invocation.

The Java Renaissance

A announcement by an Oracle architect and an IBM engineer that IBM will be joining OpenJDK. IBM promised to bring significant bugfixes and performance improvements. Oracle stated Java is their highest priority because they have so much invested into and depending on it. They also stated they are still very much in competition with each other and that Java's future is secure.

Some details on Java 7:

• to be released end of July 2011 - developer release available now
• introduces switch on String
• the initialization of a new genericized variable need not specify the generic, e.g. Collection<Foo> c = new ArrayList<>();
• I/O simplification, e.g. ResourceStream automatically closes
• improved fork/join operations when developing for multiple core CPUs