Drag this javascript on to your bookmarks toolbar and click when viewing a youtube video. It will give you the thumbnail of the video. I wrote it to get thumbnails for my blog.
javascript:var vid=location.href.split(“?”)[1].split(“v=”)[1].split(“&”)[0];var thumburl=”http://i.ytimg.com/vi/”+vid+”/default.jpg”;alert(thumburl);
Enjoy!
Long time since I’ve posted on this blog. So, planned to write on a small topic – string interns.
If you are a Java programmer, you already know that strings are immutable. Also, all string literals are interened in Java. That means no literal is duplicated.
String s1 = "satya"; String s2 = "satya";
In the above code snippet, both s1 and s2 have reference to the same object, which is a string in the string table (pool) that JVM maintains.
String s1 = new String("satya");
String s2 = new String("satya");
In the above code snippet, s1 and s2 have reference to different objects because they are not literals.
In the firt case (literals), if you need to compare s1 and s2, just s1==s2 would suffice because both refer to the same object. This is much faster than s1.equals(s2).
What if you want to compare all the strings in your application with == instead of String.equals()?
What you need to do is:
String s1 = new String("satya").intern();
String s2 = new String("satya").intern();
String.intern() would push the string to string table if it’s not already present, otherwise return the existing equivalent string which is in string table. By calling intern() on each and every string that’s created in your application, you can safely use == instead of String.equals() on strings. But is this approach good? Definetely not in all cases.
The obvious dangers with intern() are:
The only case where intern can help you is: when your application has a small set (few hundreds) of highly repeating strings (one string repeated a million times in different objects) and those strings are created in run-time. In this case, you can call intern on all the strings that you create in run time. This would give the reference to a string from the string pool and when you want to compare two strings (with in that set), you can use == instread of .equals()
This strictly depends on how many different strings you are going to intern, for, all interned strings are pushed to string table, and this table is present in permanent generation of JVM. When you start pushing too many strings into permanent generation, this gets full and a full gc is triggered, which is exactly not what you want if your application has a response time SLA.
So, in this case, you would save a lot of memory and can stop multiple strings with same content from getting promoted to tenure generation. And remember a string has a good amount of overhead due to the fields that it maintains. So, if you think “satya” is 5 bytes – you are clean bowled; if you thing “satya” is 10 bytes – you are stumped. Just look at the fields in String class to know what’s the real size. (4 for size, 4 for hash code, 4 for offset, and 16 for array? and 8 or 4 for the object depending on jvm architecture)
So, if you have small set of repeating strings, intern them. (when optimizing for memory)
Hope that helps!
Jar file can be packaged with a INDEX.LIST which contains a list of classes and their locations. If you see this exception in your logs when the application is starting up, the culprit is corrupt INDEX.LIST file.
Read it from the jar file specification:
Once the class loader finds a INDEX.LIST file in a particular jar file, it always trusts the information listed in it. If a mapping is found for a particular class, but the class loader fails to find it by following the link, an InvalidJarIndexException is thrown. When this occurs, the application developer should rerun the jar tool on the extension to get the right information into the index file.
So, just patch your jar file with the latest INDEX.LIST or remove it 
to fix the error.
The jar file specification is here.
Many a time, need for simple LRU cache arises. Instead of reinventing the wheel, Java provides an easy way to implement a LRU cache. Java collections framework has a LinkedHashMap which does almost what we need for LRU cache.
LinkedHashMap maintains a doubly linked list of the entries. The list is structurally modified by a put or get depending on the type of the map. If the map is access-order oriented, get() modifies it structurally. If the map is insertion-order oriented, put() and putAll() modify it structurally.
The class provides a method removeEldestEntry() which can be overridden to say if the map has to remove its oldest entry. The oldest entry can be the least recently used or oldest inserted entry in the map or any thing else. Just override this method to tell if the entry is to be deleted or not. This method would be called by put() and putAll() after an entry is inserted in the map. This method should(need) not attempt to change the map by itself, it just has to say if the oldest entry is to be deleted or not.
How to build a fixed size cache (insertion-order oriented)?
package com.example;
import java.util.LinkedHashMap;
import java.util.Map.Entry;
public class Cache<K, V> extends LinkedHashMap<K, V> {
/**
* Default value
*/
private static final long serialVersionUID = 1L;
private int mMaxEntries;
public Cache(int maxEntries) {
// removeEldestEntry() is called after a put(). To allow maxEntries in
// cache, capacity should be maxEntries + 1 (for the entry which will be
// removed). Load factor is taken as 1 because size is fixed. This is
// less space efficient when very less entries are present, but there
// will be no effect on time complexity for get(). The third parameter
// in the base class constructor says that this map is
// insertion-order oriented.
super(maxEntries + 1, 1, false);
mMaxEntries = maxEntries;
}
@Override
protected boolean removeEldestEntry(Entry<K, V> eldest) {
// After size exceeds max entries, this statement returns true and the
// oldest value will be removed. Behaves like a queue, the first
// inserted value will go away.
return size() > mMaxEntries;
}
}
How to build a fixed size LRU cache (access-order oriented)?
package com.example;
import java.util.LinkedHashMap;
import java.util.Map.Entry;
public class LRUCache<K, V> extends LinkedHashMap<K, V> {
/**
* Default value
*/
private static final long serialVersionUID = 1L;
private int mMaxEntries;
public LRUCache(int maxEntries) {
// removeEldestEntry() is called after a put(). To allow maxEntries in
// cache, capacity should be maxEntries + 1 (+1 for the entry which will
// be removed). Load factor is taken as 1 because size is fixed. This is
// less space efficient when very less entries are present, but there
// will be no effect on time complexity for get(). The third parameter
// in the base class constructor says that this map is access-order
// oriented.
super(maxEntries + 1, 1, true);
mMaxEntries = maxEntries;
}
@Override
protected boolean removeEldestEntry(Entry<K, V> eldest) {
// After size exceeds max entries, this statement returns true and the
// oldest value will be removed. Since this map is access oriented the
// oldest value would be least recently used.
return size() > mMaxEntries;
}
}
A small program to test the cache.
package com.example;
import java.util.Map;
public class Main {
public static void main(String[] args) {
Map<Integer, String> cache = new Cache<Integer, String>(100);
Map<Integer, String> lruCache = new LRUCache<Integer, String>(100);
// Fill the cache with 100 entries
for (int i = 0; i < 100; i++) {
cache.put(i, String.valueOf(i));
lruCache.put(i, String.valueOf(i));
}
// This should remove entry with key 0, because it is the oldest by
// insertion-order
cache.put(999, "999");
if (cache.containsKey(0)) {
System.out.println("0 still exists! Something wrong.");
} else {
System.out.println("Great! Your cache works. 0 is removed.");
}
// Now access keys 0 to 49 and 51 to 99, so key 50 becomes the least
// recently used.
for(int i=0; i<50; i++) {
lruCache.get(i);
}
for(int i=51; i<100; i++) {
lruCache.get(i);
}
lruCache.put(999, "999");
if (lruCache.containsKey(50)) {
System.out.println("50 still exists! Something wrong.");
} else {
System.out.println("Great! Your LRU cache works. 50 is removed.");
}
}
}
Long before, I told my friends that I would be maintaining a technical blog, but failed to do. Today is the start of it, I’ll target one post a week at least. I will try to blog the technical things I learn in a way that readers will understand.
That’s all for now, will start soon.
