JIT compiler - Nice Idea

JIT Compiler: 

Taking the best of two worlds - results in interpreting(converting to machine code) machine independent byte code at the cost of  dynamic compilation (generates optimized code based on target machine) + caches translated code to minimize performance degradation

JDK vs JRE

JDK: The JDK includes the compiler and other tools needed to develop Java applications

JRE: JRE is a subset of JDK(light weight), it contains java.exe which is used to run an already compiled java application. Unlike JDK, JRE does not include java tools like compiler or other tools. 

JDK vs JRE: JDK is a superset of JRE, it can be used to develop java applications, compiling and running java applications. JRE is just for running already compiled application. 

Why is char[] preferred over String for passwords?

1) Strings are immutable in Java if you store password as plain text it will be available in memory until Garbage collector clears it and since Strings are used in String pool for re-usability there is pretty high chance that it will be remain in memory for long duration, which pose a security threat. Since any one who has access to memory dump can find the password in clear text

2) Java recommendation using getPassword() method of JPasswordField which returns a char[] and deprecated getText() method which returns password in clear text stating security reason.

3) toString() there is always a risk of printing plain text in log file or console but if use Array you won't print contents of array instead its memory location get printed.

String strPwd="Java1234";
char[] charPwd= new char[]{'J','a','v','a','1','2','3','4'};

System.out.println("String password: " + strPwd);
System.out.println("Character password: " + charPwd);

String password: Unknown Character password: [C@52c8c6d9

Final thoughts: Though using char[] is not just enough you need to erase content to be more secure. I also suggest working with hash'd or encrypted password instead of plaintext and clearing it from memory as soon as authentication is completed.

Singleton pattern is tricky

1)  Singleton that every body knows

class Foo {

     private static Helper helper = null;     

     public static Helper getHelper() {         

     if (helper == null) { 

             helper = new Helper(); 

        }         

 return helper;

     }

    private Foo(){} 

}

Analyzing point 1: Pros: Good for single threaded application

Cons: Gets real bad in multithreaded programs. Ex: Threads 1,2 will start at the same time and create two instances defeating the purpose. Proof: try syso(getHelper());

2) Basic fix:

 
class Foo {
     private static Helper helper = null;     
     public static synchronized Helper getHelper() {         
     if (helper == null) { 
             helper = new Helper(); 
        }         
 return helper;
     }
    private Foo(){} 
}
 
Analyzing technique 2:

Pros: Wow!! fixes the cons of technique 1

Cons: Expensive. Imagine 50 Threads in your application and every time they invoke getHelper you pay the cost of synch and reduces application speed. 
 

3) Lazy Fix:

 
class Foo {
     private static Helper helper = new Foo();     
     public static Helper getHelper() {         
         return helper;
      }
    private Foo(){} 
}
 
Pros: Fixed it for MultiThreading. Loading static pieces once owned by class 

Cons: UnNecessary creation of objects if not needed. Imagine you have a lot of classes with this fix and you want to create objects on meeting certain conditions, but this will all objects irrespective of conditions met

More techniques coming soon!!!

Index for a table - Factors to consider

• Creating an index Consider indexing keys that are used frequently in WHERE clauses.

• Consider indexing keys that are used frequently to join tables in SQL statements.

• Choose index keys that have high selectivity. The selectivity of an index is the percentage of rows in a table having the same value for the indexed key. An index's selectivity is optimal if few rows have the same value. Note: Oracle automatically creates indexes, or uses existing indexes, on the keys and expressions of unique and primary keys that you define with integrity constraints. Indexing low selectivity columns can be helpful if the data distribution is skewed so that one or two values occur much less often than other values.

• Do not use standard B-tree indexes on keys or expressions with few distinct values. Such keys or expressions usually have poor selectivity and therefore do not optimize performance unless the frequently selected key values appear less frequently than the other key values. You can use bitmap indexes effectively in such cases, unless the index is modified frequently, as in a high concurrency OLTP application.

• Do not index columns that are modified frequently. UPDATE statements that modify indexed columns and INSERT and DELETE statements that modify indexed tables take longer than if there were no index. Such SQL statements must modify data in indexes as well as data in tables. They also generate additional undo and redo.

• Do not index keys that appear only in WHERE clauses with functions or operators. A WHERE clause that uses a function, other than MIN or MAX, or an operator with an indexed key does not make available the access path that uses the index except with function-based indexes.

Truth about Java string pool and Intern

public static void main(String[] args)

{

String literalstr = "ABC";

String literalstr2 = "ABC";

String str = new String("ABC");

String str2 = new String("ABC");

if (literalstr == literalstr2)

{

System.out.println("Literal String... I use String Pooling");

}

if (str != str2)

{

System.out.println("Object String... I dont use String Pooling");

}

if (str.intern() == str2.intern())

{

System.out.println("Interning ... I use String Pooling");

}

// System.out.println(ric2);

}

Java string pool and intern

Two ways of creating string are

1) String s ="hello"; No. of string literal = 1 i.e. "hello" - No. of String objects on heap = 0

2) String s= new String("hello"); - No. of string literals =1 and No. of string objects =1

Java maintains a string pool of "LITERALS" and not of objects.

Advantage of string pooling: 1) Reduced memory usage*(PermGenSpace Issue) 2) Faster Comparision i.e == comparision 3) Faster lookup

Disadvantages: 1) Overhead maintaining pool

How to pool String objects? Use Intern() on a string to add it to the pool. Downside of interning: 1) You may forget to intern some strings and compare them by == leading to unexpected results.

*Interning large number of strings is a problem again. The internalized strings go to the Permanent Generation, which is an area of the JVM that is reserved for non-user objects, like Classes, Methods and other internal JVM objects. The size of this area is limited, and is usually much smaller than the heap. Calling intern() on a String has the effect of moving it out from the heap into the permanent generation, and you risk running out of PermGen space.