Wednesday, December 03, 2008

Issue with latest Jawr 2.6

I have been using JAWR library for past six months in my project and found it very well documented and very stable too. But, yesterday I was surprised to find an issue with its latest (2.6) release.

A new configuration feature jawr.csslinks.flavor has been added to configure how <link> CSS tag is rendered. But, by default, <link>tag is not terminated with "/>" as claimed in the jawr taglib docs. With 2.6 release (Nov 25,2008), my CSS links which worked fine earlier, started to render as follows:
<link rel="stylesheet" type="text/css" media="screen" 
href
="/xxx/gzip_N173773858/bundles/base.cssnull
This broke my screen layout.

Adding jawr.csslinks.flavor = xhtml in jawr.properties solves this issue.

Tuesday, November 18, 2008

Eclipse update manager not launching

Recently I faced an unusual issue with Eclipse. The update manager would not launch. When I clicked on Help -> Software Updates -> Find and Install nothing happened. The issue was similar to the one reported here.

I started the eclipse with -debug option. On the launcher console, it logged something like bookmarks.xml file could not be read due to premature end of file. Checked file C:\eclipse\configuration\org.eclipse.update\bookmarks.xml, it was indeed 0 (zero) bytes!! How did that happen? Probably, a scandisk run truncated the damaged file after power failure which is common in Pune these days :-(

Anyways, I restored the bookmarks.xml file with some update sites that I could remember:

<?xml version="1.0" encoding="UTF-8"?>
<bookmarks>
<site name="Regex tester" url="http://brosinski.com/regex/update" web="false" selected="false" local="false">
<site name="Code Style checker" url="http://eclipse-cs.sourceforge.net/update" web="false" selected="false" local="false">
<site name="Find bugs" url="http://findbugs.cs.umd.edu/eclipse/" web="false" selected="false" local="false">
<site name="ByteCode viewer" url="http://download.forge.objectweb.org/eclipse-update/" web="false" selected="false" local="false">
<site name="Multi-project plug-in" url="http://eclipse-tools.sourceforge.net/updates/" web="false" selected="false" local="false">
<site name="PyDev python IDE" url="http://pydev.sourceforge.net/updates/" web="false" selected="false" local="false">
<site name="Jboss tools" url="http://download.jboss.org/jbosstools/updates/stable/" web="false" selected="false" local="false">
<site name="Eclipse Europa" url="http://download.eclipse.org/releases/europa/" web="false" selected="true" local="false">
</bookmarks>
Eclipse is now starting fine and launching the update. Only issue is that I have lost some update sites bookmarked earlier. Probably by restoring the damaged bookmarks.xml file with an empty content, something like given below, might also help eclipse to launch the update manager and the bookmarks can be added back later from Eclipse update manager.

<?xml version="1.0" encoding="UTF-8"?>
<bookmarks>
</bookmarks>

Thursday, November 06, 2008

My next phone will not be a Nokia

I have formed this opinion after my latest experience with Nokia phone and their customer service. Before this experience I had been a great fan of Nokia for over a decade . I have owned one of the first models (5110) they launched in India back in 1998. Call rates then were as high as Rs 9/- per minute for out going and Rs 6/- per minute for incoming on BPL Mobile, Mumbai. Over the years I bought and owned several other Nokia models like 3130, 3610, N72 etc and had a pleasant experience with all of them.

My latest phone is a Nokia e61i. I was gifted this phone by wifey last Diwali. We bought this phone from Croma @ Hadapsar. It was working fine until sometime last month when I noticed its keypad back-light was not working even in a dark room. I know e61i has a "light sensitive" back-light and it would light up only when needed.

Not sure when and how did it stop working as I do not use phones in the dark very often. Anyways since, phone was still under warranty I thought it prudent to show it to a NokiaCare. I took the phone to Akshay Telecom on F C Road. They examined the phone and said it was due to water seepage and will not be done under warranty. I was shocked. The phone was never ever mishandled, dropped or drenched in my possession and is working absolutely fine otherwise. Probably it is just a manufacturing defect which I failed to notice sooner. As a pricey gift and some emotional attachment to it, I agreed to bear the cost of repairing and left the phone with them. They promised to come back to me in three to four days.

Days passed but they never called back or bothered to answer my phone calls. In between I made four visits to their center- always crowded and people huddling to get an attention from dorky attendants. The volume of crowd tells the quality of phones that Nokia is churning out these days. Every time I went I had to wait for at least half an hour to get my turn. They would say they are still "looking into" it. Fed up with their unprofessional ways and after so many days without my primary phone, at last, I decided to take back the phone. They returned it un-repaired still they billed me Rs 112/- as "testing charges". After this, I followed up with couple of emails and calls to NokiaCare directly. None of these helped. They just defended the action of their care center instead of advising me how to get the issue resolved.

My phone remains un-repaired, working w/o back-light. NokiaCare says it will not be fixed under warranty or otherwise as it is "water-logged". They know, after so many months it is difficult for me to prove that I am not responsible for "water-logging" or whatever and it is a genuine manufacturing defect. It does not hurt them. It hurts me. For no fault of mine I would have to live with an ailing phone for which I spent my hard earned 17k. It hurts more when it is from such a reliable and a big brand like Nokia.

I do not know why Nokia has such a ridiculous warranty and customer support policy in India! When the hard-disk on my four years old PC conked off Seagate immediately replaced it with a new one without asking any question.

Nokia are you listening?

You have just lost a loyal customer. I am not surprised by your concerns of loosing market share !

Sunday, October 19, 2008

Greasy Sunday

My Bullet had not been running well lately. Valve train clatter, flat battery, starting issues etc. Replaced the battery two days ago. Fellow there managed to break the lock on the box. Needed to replace it ASAP to protect new battery worth 1600/-. Got the replacement lock. Realized, it was just a psychological deterrent. Thankfully not many bullet thieves around! Also, suspecting they were bent and needed replacement, bought a spare push-rod kit. At ~10400 kilometers and over two and half years it was about time to replace the air filter too. Dark (oil damped ?) spots on paper element plus it is not very expensive (130/-).

Job-list:
1. Replace lock
2. Replace push-rods
3. Replace air filter
4. Replace inlet manifold
5. Replace Carburetor hose
6. Clean oil-catch can
7. Clean Carb

Item #1 looked easy. But, turned out most difficult. Broke the +ve lead clamp which was corroded and needed to buy a new one. Lost more than half an hour to find a simple crimp-able clamp. Found one made for Pulsar. Too rickety and fragile for Bullet. Probably I will have to replace this before summer again. I had estimated two hours work and would be ready for badminton session at noon. But, it was about 4pm when I was done with all these. Missed badminton session. Too bad.

Now bike is starting fine. Firing and idling also well. Push-rods were not as much bent as I had imagined. Anyways new pair feels good and 'freer' to turn. Old would be retained for emergency. Still need to fix petrol overflow from float bowl. Probably some dirt during reassembly causing needle to stay loose? Was too tired and hungry. May be I will fix this tomorrow and oil change is due soon... recipe for another busy Sunday.

Wednesday, August 06, 2008

Feels nice to earn respect from intelligent people...

More so, if they are your colleagues who have known your craft and contributions closely.



Wednesday, April 09, 2008

java.util.ConcurrentModificationException

Often, while working with maps and other collection utilities in Java you may come across this exception:

Exception in thread ... java.util.ConcurrentModificationException
at java.util.Hashtable$Enumerator.next(Unknown Source)
at ...


A quick look at the API documentation of ConcurrentModificationException says:
"This exception may be thrown by methods that have detected concurrent modification of an object when such modification is not permissible. For example, it is not generally permissible for one thread to modify a Collection while another thread is iterating over it..."
Now this may not be very useful for newbies. They may be left wondering about multi-threading, concurrent access etc. Given below is a sample code which is single threaded, yet, it fails with ConcurrentModifcationAccess. In this code I am trying to remove keys that end with digit "5" from a Map:

public class MapTest {

public static void main(String[] args) {
//create a sample Map
Map<String, String> map = new Hashtable<String,String>();
map.put("key1", "value100");
map.put("key2", "value200");
map.put("key3", "value300");
map.put("key4", "value400");
map.put("key5", "value500");
map.put("key55", "value550");
map.put("key6", "value600");

System.out.println("mappings before: "+map);

//retrieve the set of Keys in the map
Set<String> keySet = map.keySet();

//iterate over keys and remove
// those which ends with "5"
for(String key : keySet) {
if(key.endsWith("5" )) {
keySet.remove(key);
}
}

System.out.println("mappings after: "+map);
}

}

When you run this code it will throw concurrent modification exception. Now try the following sample. Changed code is highlighted.

public class MapTest {

public static void main(String[] args) {
//create a sample Map
Map<String, String> map = new Hashtable<String,String>();
map.put("key1", "value100");
map.put("key2", "value200");
map.put("key3", "value300");
map.put("key4", "value400");
map.put("key5", "value500");
map.put("key55", "value550");
map.put("key6", "value600");

System.out.println("mappings before: "+map);

//retrieve the set of Keys in the map

Iterator<String> keySetItr = map.keySet().iterator();
while( keySetItr.hasNext()) {
String key = keySetItr.next();
if(key.endsWith("5" )) {
keySetItr.remove();
}
}

System.out.println("mappings after: "+map);
}

}
This code runs fine. Why?

The evil is in the code:
for(String key : keySet) {
...
keySet.remove(key);

The for(...) actually opens an iterator internally and when we remove the key from KeySet this iterator logic breaks, throwing the ConcurrentModificationException. To avoid this one should use the second example given above, where same Iterator (keySetItr) is used both for iteration and removing the keys.