Entries by abhi

It's a lazy Friday afternoon in Reno, Nevada and we suddenly have a power outage. This is the perfect time to get together and have one of those meetings which might seal the fate of Java at PC-Doctor. An executive decision needs to be taken if we will move our User Interface from Java to C# and .Net. The storm has been brewing for quite some time now. We have been using Java along with SWT/Eclipse RCP/JFace for our UI for past 3 years and Java is making us immobile. The JRE size is dragging us down. We have a very pretty UI and we had a highly agile and automated system in place to get the job done but Java (specially the JRE, which needs to be shipped with our product) is becoming a bottle neck.

How it all started


PC-Doctor is the leading vendor for Hardware Diagnostic solutions and all our diagnostics are in C++. To present it to the end user we use Java/SWT/JFace. We use Excelsior's Jet to compile our SWT/Java code and even poor excelsior (they have an excellent product and great customer service though) could not get us what we desired. Sun has a stupid clause which does not allow to strip off unwanted components from the JRE and you are forced to ship all of it which is a whooping about 15 Megs. Imagine trying to sell your product to a person in one of the third world country (where internet bandwidth matters ). Someone just wanted to test his system and we can test all darn things possible in the machine with just few megs of our efficient C++ code, but just to present it to the user we have to add another 20 Megs which doesn't make any sense. C# comes in handy due to it inter-operating very nicely (generating wrappers using SWIG was a breeze which was a lot of work to get it to work correctly with Java) with our engine code which is in C++. Moreover with C# we now have many system specific resources at our disposal which previously we would have to use C++ to accomplish and implement.

Opinions

I am a die-hard avid Java supporter and it's hard for me to push for C#, but C# comes out as a better language because they had the advantage of stealing all good things from Java and C++ and when you have the muscle and money power of Microsoft you could hire some sensible developers to get something right. It seems they almost got C# right. But with the kind of products we make we need to be highly agile and have a UI which could be easily developed and C# just fits in perfect. SWT/JFace/Eclipse RCP is the best thing to have happened to the UI world in last 10 years but it still lacks a good visual studio editor support and when agility is needed it is a tad little extra work.

Anyways after some initial hiccups i decided to join the evil side and we decided to port our UI to C#.

I will keep you posted on how it feels to be on the evil side and how the grass looks from the evil world (hopefully greener ).

The backbone of any UI toolkits are threads. The most basic aspect of UI toolkits is to provide a nice event driven architecture, as events are the most integral part of any UI.

The underlying operating system maintains a queue of application events and if that event is long running and is blocked it will freeze your UI.

In SWT when a user presses a mouse a mouse pressed event is generated. Determining which window is supposed to receive the event and placing it in an event queue is done by the underlying OS.

SWT has a single UI thread which creates the display and from which all other widgets are created. When writing a SWT app the most common piece of code existing in all programs is

while (!shell.isDisposed())

{

if (!display.readAndDispatch())

display.sleep();

}

display in SWT is the class which interacts with the underlying operating system. In the above code readAndDispatch() is the call which reads events from the event queue and dispatches them to the correct place.

Since there is only one UI thread, if we try and process events in the same thread the UI will freeze. This is where threads come to our rescue. But again when working with UI's the most tricky and dangerous thing to do would be access UI components from non UI threads. If you spawn a new thread and try to update UI components from that non UI thread you will be in for a bummer. When your UI toolkit is SWT, it will nicely point out to you your chivalry and throw an SWTException.

How do we handle it then? Not much to worry. SWT comes to our rescue. SWT says that all your calls to the UI code must be done by providing a Runnable which should call the UI components and deal if need be. The two calls SWT provides and we should be using are syncexec(Runnable r) and asyncexec(Runnable r).

syncexec is the one which provides a Guarantee of a blocking call. It will go ahead and do the task provided in the run method of your runnable and block the execution of the main UI thread from which it was spawned.

asyncexec is used when your code in the runnable doesn't need to block the background thread or more appropriately when the code in Runnable can run on its own and is not dependent on any return value being provided from the UI. This is more of an asynchronous update and UI code will be updated from the runnable if and when this runnable gets executed.

The most common mistake people make when calling syncexec and asyncexec is using

Display.getCurrent().syncExec(...........)

When trying to retrieve the display the most important check is to make sure that has not been disposed and is not null. So make sure Display.getCurrent() != null before you go ahead and make the above call.

A safe approach i have used is retrieving the default display using

Display.getDefault().syncExec(............)

which has always worked for me as long as my main UI is running.

Now that might create an illusion that you can create a new Runnable and use it for long running tasks when working with RCP applications by invoking asyncexec, but my friend that is not going to help. Remember asyncexec is not providing you any guarantees and is not the same as running a new background thread to process blocking long running tasks. These two are most importantly mechanisms to update UI code from non UI thread and thats all they should be used for.

So how do we do that treacherous I/O processing from our RCP applications. How do we synchronize our DB tables from our RCP app. How do we work with resources without locking our programs. Doesn't eclipse provide some way of doing it? Well here comes in a new Job. Don't panic you are not being offered a job.

Since eclipse 3.0, eclipse comes with a new Job API which is the most astonishing and useful addition.

Job class provides the support for performing long running operations in the background. Not only that there is a rich set of other classes which can be used to provide for smooth deadlock free operation. The most important one being the

ISchedulingRule interface which is used to decide scheduling rules for your jobs. You can implement this to determine what jobs can run concurrently and what cannot.

The other one is the ILock which provides support to handle deadlock detection and recovery.

Together with these we can handle any real life challenges of any scalable systems possible.

The simplest way to run a background thread in RCP app without the scheduling and locking is

Job helloWorldJob = new Job("Hello World Job") {

protected IStatus run (IProgressMonitor monitor) {

............

//all your background job will be done by me here

..............

return Status.OK_STATUS; //return whatever status based on your job success.

}

} ;

helloWorldJob.schedule();

We can also set the jobs priority (default is Job.Long), deal with deadlocks provide scheduling rules etc.

The above gives a basic idea of threads in general in the RCP/swt world. I will in a later post cover the astonishing Progress monitors and pitfall associated with it. Till then keep reading.

string or String? object or Object?

string is just an alias for System.String class which as we all know represent a sequence of characters. It is annoying for someone switching over
from the Java universe to have this confusion. It looks like Microsoft could not find a better way to differ and improvise on Java then come up with these
stupid aliases. Anyways Microsoft would probably call it "Syntactic Sugar". Poor old programmers might catch Programming Diabeties with too much of
stupid syntactic sugar.

There used to be a great debate on how use of Java in college curriculum was more productive, but, was aiding in creating poor programmers. I would love to see what these people have to say about C#. Microsoft which tried very hard to make their language as simplistic as possible, but its annoying at the very least.

Anyways best practices state to use String when referring to the System.String class and when dealing with objects of type String use "string". Some people will
argue about the convenience (that's all i could think of) of not being worried about holding the CTRL key to capitalize the ubiquitos "S" but it's just stupid. I am hoping someone can explain the reasoning to me.

override and new

Another syntactic sugar candy. As though programmers will have tough time figuring out if you are overriding or just hiding. In Java functions with same method signature in children classes automatically override the parent, but C# you can make it very obvious by putting an override keyword. This probably was needed because Java assumes all your methods to be virtual. The use of new and override might be handy in situations where the programmer doesn't know if he wanted to hide or override or inadvertently modifies the signature of the functions. C# would show a nice compile time warning or error depending on whether you tried to override or hide.

C# is more of a Microsoft way of implementing Java as per there standards. If we look at the initial specs for C# we would see how closely they were trying to imitate Java. I will crib about that in another blog.

We always end up working with files when writing a meaningful application. Java has a tremendous API for handling files and they do the job most of the times. This post is to point out one of the most common reasons we get java .io.FileNotFoundException.

A call to new FileOutputStream(file) throws either a security exception or a FileNotFoundException.

Ideally when you created a file using

File file = new File(fileName) you will hope a error to be thrown, but that will not happen as this call doesn't actually create a physical file on the disk (you need to call createNewFile()) to create a physical file.

Now if you are chaining this file reference and passing it to FileOutputStream hoping all to work like dream, you might be in for a surprise if the File you provided has INVALID characters in the file name. If you have invalid characters the call to new FileOutputStream(file) will throw a file not found exception and you will be wasting precious time debugging what went wrong.

So the rule of thumb is to have a static function somewhere to check for your file name for invalid characters, and make sure to run your file name by this function to prevent the i/o errors.

Invalid file name characters

The following are not allowed as file name characters in windows world

\ / : * ? " < > |

For more information check the following link:

http://support.microsoft.com/kb/177506

Sample File Name Purifier Program

public class FileNamePurifier {

final String[] invalidChars = new String[]{"/","\",":","*","?","<",">","|"};

public static final String purifyFileName(String name) {

if (name == null || name=="") return;

String returnName = name;

for(String str : invalidChars) {

returnName = returnName.replace(str,' ');

}

return returnName;

}

}

The above is just a sample implementation and you can come up with better and more efficient implementations of your own.