Java Locale class: Bug, Feature, or?

Multilingual support is one of the basic features of our Eclipse application. We give to user the opportunity to choose his language and country. For example, language can be English (en), and country may be United Kingdom (UK), United States (US) or Canada (CA). Java code, performing this functionality, uses standard Java Locale class. The Eclipse resource file, corresponding such Locale class instance, we named using Locale class toString() method as file name extension. That is, for above example of Canadian English, the extension was en_CA, for France' French - fr_FR, for Russia' Russian - ru_RU, and so on. Similarly, we suppose to get the obvious he_IL extension for Israeli Hebrew language. For our great surprise, we got iw_IL instead!! When I opened Locale class code, I've found the special hard coded snippet, changing the "he" string to "iw". Very strange, and so far it is not clear why it was done.

ClearCase inside! - Eclipse interface

Our Eclipse application upholds hundreds of resources. As usual for good team work, all these resources are controlled by IBM Rational ClearCase. Usually, each user, going to work with some resource, opens ClearCase Explorer, checkouts this resource file, returns to our application and keeps doing his mission. If another user has to work with the same resource and try to checkout this resource in the ClearCase Explorer, he gets the message informing that this resource is checked out by named user and he can to work with unreserved copy of this resource. In practice, most of our users just change the "read-only" property of this resource and make their changes as well. Furthermore, such "careless" user usually does not keep in mind to merge his work with results of the another one. A lot of times I was called to help to such "duffers" to save theirs day (or week) work and to restore lost information.

Naturally, the best way to stave off such bad practice is to add the ClearCase functionality to our application - to add proper GUI action and to implement at least checkout and checkin operations.
Unfortunatly, I could not find any Java interface to the IBM Rational ClearCase Eclipse plug-ins. The standard Eclipse plug-ins we use do not contain the source code.
The solution, with "little help of" Cavaj Java Decompiler see below:

1. First of all, let us add the standard "Connect ot Rational ClearCase" action to your perspective:


2. To get connection to ClearCase call:

This variable can be used as a handle to ClearCase plug-in. All known ClearCase operations can be executed using this handle.
For example, to check if application is connected to ClearCase, use method:

3. To checkout resource:

4. To checkin:


Now it's trivial to add all ClearCase actions (Checkin, Checkout, Hijack, Add to Source control, and so on, to each application resources.
The attempt to edit checked-in resource brings to standard "Checkout Element(s)" dialog:

Warning: A handler conflict occurred. This may disable some commands.

It irritated me more then a year: each time when I tried to leaf through number of opened GEF editors or to open a new one, both zoom action stopped to work with this warning. Solutions from Internet deal with more then one different but similar actions and recommend to add different conditions for these different action handlers. Besides, these actions were definded by actionSet extension point. But in our case the actions are standard GEF zoom actions!

My solution is very simple - make action handlers static editor class members and to diactivate and then to reactivate them in the setFocus() editor method:

Link with Editor versus Drag and Drop

Standard Navigator view has the "Link with Editor" action button. If this button checked, each click on Navigator view element should open (or activate) proper resource editor.

And this feature is implemented and works perfect in all cases, but...
In our application we have to implement another very useful feature: user should have an opportunity to drag any elements of Navigator view and drop it on the proper editor. In our specific case this is the Graphical Editor and drag and drop the similar element to opened editor have to create a proper "call" graphical node.

This requirement conflicts with "link" one.

It seems to be simple: add to the editor drop() method line that disables the "link" functionality, complete the drop operation and enable "link" backward. Unfortunately,
this solution does not work, the "drop" is too late! Certainly, user can uncheck link button temporarily, but he wants them both!

The solution is a little bit sophisticated: we have to enter to the drag operation.
This is a proper startDrag() method of CommonDragAdapter class, so we have to extent this class and override it's startDrag() method... But this class is final!

Then we have to take a code of this class and copy it to our own, let us say MyDragAdapter. We have to extend the CommonViewer class to override it's initDragAndDrop() method. But this new MyViewer class' createCommonActionGroup() method does not except this class instance as parameter, and so on... So this is final design:

1. Take the Eclipse CommonNavigatorManager, CommonNavigatorActionGroup, LinkEditorAction, CommonViewer and CommonNavigator classes code and copy it to your own classes.
2. Change proper fields, constructors and methods to get your own classes instances.
3. Take the CommonDragAdapter code to your own MyDragAdapter class.
Change startDrag()method:



4. Override initDragAndDrop() method in your MyViewer class:



5. Then, in NavigatorLinkHelper class add code below to the activateEditor() method:



6. And, finally, do not forget to add call setLinkEditorEnabled(true) in your editor' handleDrop() method!

Add Actions according conditions

It is known how to add some actions to an Eclipse application. Also, it is known that to remove unwanted actions is more complicated task.In our case we had to add "Migrate to new version" action according the condition that application was not migrated to this new version yet.First of all, as usual, we've added the actionSet extension to the basic project MANIFEST.MF (plugin.xml) file:




Then, in the application starting code, when all application resources are loaded (for example, in application Navigator view), we try to read the application resource version property:



Where getApplication() method returns application instance and isMigrated() method returns true if application version property is higher or same as specified. In this case the “Migrate” action became invisible.