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!

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:

1. Each time you call intern(), it has to look up for an equivalent string in string table.
2. intern() might be costlier than equals()
3. equals() might be infrequently used compared to intern() in your application.

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!

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.

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.");
        }
    }

}

That’s all for now, will start soon.