Node.js project

Node.js portal for filling law questionnaire and export the results to PDF.

Failed to load the JNI shared library jvm.dll Eclipse error

If your OS is Windows 7 and you try to run Eclipse you might see this error.
If you do a google search you will see some advices suggesting incompatibility between the jdk,jvm,eclipse versions. In some cases instaling proper versions of them all(x32 or x86) might fix your issue but in my case it didn't.
All the software on my pc i 32 bit. My Windows is 32bit,jdk and eclipse helios too.
What I did to fix the issue was to change in the properties of the eclipse exe and set to run it as administrator.

Blackberry debugging notes

If you are a java developer who has written code in J2SE/J2EE and you are coming to the J2ME world here are some useful tips on debugging for Blackberry applications.
Note: All the notes are are based and tested on the BB Eclipse IDE. Its way better than the other IDE available.
However everything could easily done with the other IDE I suppose.

Here are some facts which are really useful for you to know to avoid frustration:

• System.out.println() will output something to the console screen only if you debug(Debug As...) your application in a simulator or with attached device.
• You can't get the strack trace for exception i.e. there is no getStackTrace() method
• You can't redirect the output i.e. you can't do something like System.setOut
• Calling e.printStackTrace() on java.lang.Exception won't print stacktrace
• For optimization purposes for mobile devices stack traces are generated only if there is uncaught exception and in this case the trace will go to the device log. In this way your program crashes and you get dialog with information about the error. The device log is usually accessed by holding ALT button and pressing the keys LGLG.
• Another way to view exception trace is to catch java.lang.Throwable and then call printStackTrace, note that despite Exception is a subclass of Throwable only catching a Throwable and then calling printStackTrace will actually output the stacktrace to the console.

So if you need to debug your app  you can use println on various places in your code. This could get pretty annoying because when you give your app to clients you will need to remove those prints. Also you don't want everybody to view debug info for your app - everyone could attach the device to a pc and run in debug mode.

A possible solutions is to make some method and maintain a flag which you can change manually in the code.Based on the value of this flag  you will determine whether to print or not. But still you will have more compiled code than you need and the jvm will have to check the value of this flag every time. This approach isn't that bad - it gets the job done.

Personally I prefer to use the preprocess directives which are available. This concept is taken from languages like C/C++. I define a directive and just remove it when I will package the final version. Here is the code:

//#preprocess
package mypackage;

public class Debug {

    public static void log( String msg ){
        //#ifdef DEBUG
        System.err.println( msg );
        //#endif
    }
    
    public static void log( Throwable t ){
        //#ifdef DEBUG
        System.err.println( t.getMessage() );
        t.printStackTrace();
        //#endif
    }
}

You can use this log methods to print information on the console screen and when you create your final version there is no need to remove the calls to these methods from your code. Then the lines where you actually print something won't be compiled. Just remove the directive DEBUG from the Application Descriptor file. The downside of this approach is that you will still have empty method call but method invocation is really fast in the jvm so this isn't a big issue.

Determine if device has touch screen support in J2ME

I had to write some code to determine whether a Blackberry device supports touch screen events. There are APIs from RIM to do this but they are availble for devices with os v4.7 or later and I needed to support os 4.6 also.
So I used the pure j2me approach:
Using javax.microedition.lcdui.Canvas you can determine whether a device has touch screen support by calling the hasPointerEvents() method. Because Canvas is abstract class you should provide a dummy implementation similar to the one I offer. The following code is tested and works on actual Blackberry devices and it should also work on other devices but I haven't tested it.

import javax.microedition.lcdui.Canvas;
import javax.microedition.lcdui.Graphics;

public class TouchSupportInfo extends Canvas {

    private static TouchSupportInfo instance;
    
    private TouchSupportInfo(){
        
    }
    
    public static TouchSupportInfo getInstance(){
        if( instance == null ){
            instance = new TouchSupportInfo();
        }
        return instance;
    }
    
    protected void paint(Graphics g) {
        //leave empty
    }
    
    public boolean isTouchScreenDevice(){
        return hasPointerEvents();
    }

}

Code highlighting

Use this site to generate highlighted code: http://tohtml.com/

class C{
 public static void main(String[] args){
 System.out.println("asd");
}

}

Open Hashtable Java Implementation

The third and last(for now) data structure I would like to present is hashtable with open addressing.Again I won't bother to explain in detail what is hashing, hashtable, chaining, open addressing. If these terms aren't familiar to you please take a look at these articles:

Hash Function

Hash table

When I read these articles I wondered how "good" can a hashtable implementing open addressing be?
Since Java provides hashtable with chaining I had the opportunity to compare the two types of tables. The implementation I am offering uses quadratic probing for collision resolution. It also stores its elements in nodes of a double linked list which provides faster iteration through keys/values.

Performance:
Again there is a set of tests comparing both hashtables.
Well the results aren't as good as I wanted them to be.
The chaining implementation is more consistent in its performance.

-Insert is almost equal for both implemetations
(Data type: integer)

table/num elements	10,000	50,000	250,000	500,000
Chaining	0ms	60ms	290ms	1122ms
Open Addressing	10ms	80ms	340ms	881ms

Testing with 1000000 elements and different load factors:

	0.75	0.5	0.4	0.3
Chaining	1221	1192	1132	2093
Open Addressing	1882	1672	1543	1552

As you can see in order to perform better than a chained hashtable open addressing needs bigger table.This can be done by setting smaller load factor or bigger size of the table.

Searching:
For up to 50,000 elements both tables perform equally.For 500, 000 elements chaining has slight advantage.

Delete:
Again the same situation but for 500, 000 this time the advantage is bigger for chaining - about 2 times faster.

Get all keys/values:
This time Open Addressing is better due to the fact that each element is a node in double linked list so if you have n elements you'll need exactly n steps to get all keys/values.
For getting all values open addressing runs about two times faster.

Search for a value:
Although I don't think this is a typical operation for a hashtable both implementations offer it. In both implementations it is slow and you should use it with caution.
However in open addressing it runs much faster - 14.5 sec. vs 46sec in chaining for searching 20,000 values.

Conclusion:
In order to be as fast as chaining implementation open addressing needs much more space than the actual number of elements.Thus a lot of memory is wasted.
Open addressing cannot store more elements than its table size, while chaining has no such limitation.
If you check the wikipedia article some advantages of open addressing are mentioned there but for general purpose usage chaining is more robust and consistent.
Not to mention what a pain in the ass is to implement open addressing based hashtable :P
Of course there are cases where this implementation could be useful too.

Here is the source + tests

AA-Tree Java Implementation

The next data structure presented is called AA tree.
Briefly this is a self balancing binary tree.Its performance is comparable with the performance of red-black trees though it is slightly slower during tests.


The wikipedia article explains this type of trees well enough:
AA-Tree

AA Tree demo


The Java implementation I offer follows the algorithms explained in the article above so I didn't prepare any additional documentation. The standard search/insert/delete functionality is provided. The tests provided in the package compare this implementation with Java's TreeSet which keeps elements in red-black tree. The performance tests show that both implementations have similar running times:
- searching is similar(barely noticeable advantage for aa-tree)
- insert is slightly faster for red-black trees
- delete is faster for red-black trees(my tests show about two times advantage for TreeSet)

So as you can see Red-Black Tree is clearly the winner here.
This is not surprising - after all this is one of the most popular trees in many libraries in different languages.

So what is the advantage of AA tree over Red-Black tree?
Besides the slight advantage in searching maybe the biggest advantage is that AA trees are simple to implement.The implementation I offer is about 170 lines which is less than any red-black tree implementation I've seen so far.

Java source + tests