KONKNNI ULËY KONKNNI XIKËY - is the program currently being conducted by the Maharashtra Konkani Association. Translated it means "Speak Konkani, Teach Konkani".

Konkani people are dispersed throughout the world. In the past generations they have migrated and occupied most of the coastal belt of western India - from Ratnagiri to Kerala; some moved as far away as Kenya. In recent generations, they've moved even further - from Delhi to Dublin and from Australia to California.

Its very difficult for a scriptless language to survive. There has been a lot of discussion/controversy over the script used for Konkani. The reson for this is the use of various different scripts for the language - based on the regions where its spoken. Its written in Roman and Nagari scripts in Goa, Kannada script in Karnataka, Malayalam script in Kerala.

Most of the languages in India has about five to seven basic vowels excluding long vowels and diphthongs. But Konkani language has 16 basic vowels excluding equal number of long vowels and lots of diphthongs. Different types of nasal vowels are the speciality and greatness of Konkani language. Hence it is very diffecult to represent Konkani language as it is pronounced using any existing scripts in India.

The above program is trying to promote the use of Roman script - with a few modifications - for the Konkani language. Thomas Stephen Konkani Kendr in Goa has formulated a new Orthography for writing Konkani in Roman script by modifying the existing Roman script orthography used by Goan Catholics. This script is so simple that Konkani can be written by representing exact sounds using the normal computer keyboard keys. This script is the result of their research in of number of years.

"Kannada script can not be accepted as a universal script for Konkani as it is not popular outside Karnataka. Devnagiri script has the potential to unite all Konkani people at least at the national level. But it is sad that our people have not accepted it for Konkani even after trying for so many years. Now for the survival of Konkani the only option we have is Roman script that could be also used at the International level. People should come forward to make extensive use of this script for Konkani so that the language may be promoted to our next generation." said Rev. Dr. Pratap Naik S.J., director of Thomas Stephen Konkani Kendr Goa.

Comments

Ended the year with a new release of Kaprekar - version 3.0.

There are two main changes in this release - a) Parameterized the classes based on Java 5 Generics and b) Added a pause and resume option.

The pause and resume option holds only for the current run of Kaprekar. I plan to allow a "save state" feature in a future version where the user can save the current state of the Kaprekar run in a file and exit the application. Later, the user may "load the state" and resume the Kaprekar run.

For more info on the Kaprekar Series Generater, check its web site at http://kaprekar.sourceforge.net

Eclipse Bug - Encapsulate Field

Found this bug in Eclipse today while using the Encapsulate field functionality.

Eclipse Version: Version: 3.1.0 Build id: 200412162000

Create this simple class in eclipse -

public class TestEncapsulate {

     String a, b;
}

1) Select the Field a.
2) Right-click and select Refactor -> Encapsulate Field.
3) Click Ok.
4) The following code is generated -

public class TestEncapsulate {

     String b;
    private int a;

     /**
     * @param a The a to set.
     */
    void setA(String a) {
        this.a = a;
    }

     /**
     * @return Returns the a.
     */
    String getA() {
        return a;
    }
}

Problems
a) The field was changed to a private field even though it was package-private earlier.
This is ok by me, since I typically keep the fields as private.

b) The data type was changed from String to int!!!
This is crazy!

The encapsulate field works fine when there is only one package-private field delared in one line (String a;)
It breaks in the above code for both fields 'a' & 'b'.

I have reported this Encapsulate field bug.

Java 5.0 Crash

I was using the Eclipse Profiler Plugin to launch my application when the 5.0 JVM crashed.

Here's the information -

java version "1.5.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08)
Java HotSpot(TM) Client VM (build 1.5.0_01-b08, mixed mode, sharing)

 Eclipse Version: 3.1.0
Build id: 200412162000

 Plugin: Eclipse Profiler
http://eclipsecolorer.sourceforge.net/index_profiler.html
Plugin Version: 0.5.33

 And here's the crash message -
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  Internal Error (455843455054494F4E530E43505000FF), pid=2116, tid=2268
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_01-b08 mixed mode)
# An error report file with more information is saved as hs_err_pid2116.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

It created the log file in the project workspace folder. It contained Thread, Stack, Native frames, Heap, Dynamic Libraries, VM, Environment and System information.

Java Code: Boolean Fun

Over time I've encountered Java code that I feel could have been written better. I'll list out a few example that I encountered recently.

If you do code review you'll want to check PMD, JLint, FindBugs and some such tools [I've mentioned these before while talking of Eclipse Plugins.]

Boolean Fun

Cosider this code

if(str.length() > len) {
      return true;
} else {
      return false;
}

The Boolean Expression need not be kept in an if-else block, the output of the boolean expression could have easily been returned as

return (str.length() > len);

A more advanced form of this problem was using a ternary operator -

return (str.length() > len ? true : false);

Yes, the ternary operator is absolutely unnecessary here.

This one was really funny!

if(!(x == y))

I wonder why the developer thought of such a convoluted way to write x != y.

Another common problem I have come across when Boolean objects are used. Invariably you'll see

Boolean b = new Boolean(true);

There is no need to create a new instance here, you could just write -

Boolean b = Boolean.TRUE;