Java Programming Tips

Java Virtual Machine maintains an internal list of references for interned Strings ( pool of unique Strings) to avoid duplicate String objects in heap memory. Whenever the JVM loads String literal from class file and executes, it checks whether that String exists in the internal list or not. If it already exists in the list, then it does not create a new String and it uses reference to the existing String Object. JVM does this type of checking internally for String literal but not for String object which it creates through 'new' keyword. You can explicitly force JVM to do this type of checking for String objects which are created through 'new' keyword using String.intern() method. This forces JVM to check the internal list and use the existing String object if it is already present. e.g. String obj1 = "hello"; String obj2 = "hello"; String obj3 = "hello"; Here we are declaring three String reference variables and in heap one obj...

Every java program has at least three class loaders. - The bootstrap class loader - The extension class loader. - The system class loader. The bootstrap class loader loads the system classes from the JAR Fle rt.jar(part of JRE System Library) . It is an integral part of the virtual machine and is usually implemented in C. There is no Class loader object corresponding to the bootstrap class loader. For example. String.class.getClassLoade r() will return null since String class is loader by bootstrap loader. The extension class loaders loads "standard extensions "from the jre/lib/ext directory. The system class loader loads the application classes. It locates the classes in the directories and JAR/ZIP files on the class path. The System class loader also called application class loader. In Sun's java implementation , the extension adn system class loaders are implemented in java. Both are instances of URLClass loader. You can just go through the source code of URLCla...

Most of you heard the word 'Encapsulation' while dealing with Java OOPs concepts. What it stands for? We will start with an example. Imagine you have made your class with public instance variables as shown below. public class Sample{ public int height; public int weight; } public class MainClass{ public static void main(String args[]){ Sample sample = new Sample(); sample.height = 170; } You have created this class and think that many of others used this class for setting height and weight variables directly. Now you are really in trouble. Just think a situation that you want to do something when someone set height variable?. Can you do that without breaking everyone's code? Here comes encapsulation. It helps to change your implemented code without breaking the code of others who use your code. You must follow encapsulation if you want maintainability , flex...

Most contend that it's usually a very bad idea to have an empty catch block. When the exception occurs, nothing happens, and the program fails for unknown reasons. Example import java.io.*; import java.util.*; /** How NOT to implement a catch. */ public final class BadCatch { public static void main( String... arguments ) { List quarks = Arrays.asList( "up" , "down" , "charm" , "strange" , "top" , "bottom" ); //serialize the List try { ObjectOutputStream output = new ObjectOutputStream( new FileOutputStream( "quarks.ser" ) ); try { output.writeObject(quarks); } finally { //flush and close all streams output.close(); } } catch (IOException exception){ } } } In general, when a exception occurs, it can be thrown up to the caller, or it can be caught in a catch block. When catching an exception, some ...

Raw types refer to using a generic type without specifying a type parameter. For example, List is a raw type , while List is a parameterized type . When generics were introduced in JDK 1.5, raw types were retained only to maintain backwards compatibility with older versions of Java. Although using raw types is still possible, they should be avoided : they usually require casts they aren't type safe, and some important kinds of errors will only appear at runtime they ar e less expressive, and don't self-document in the same way as parameterized types Example import java.util.*; public final class AvoidRawTypes { void withRawType(){ //Raw List doesn't self-document, //doesn't state explicitly what it can contain List stars = Arrays.asList( "Arcturus" , "Vega" , "Altair" ) ; Iterator iter = stars.iterator(); while (iter.hasNext()) { String star = (String) iter.next(); //cast needed log(star); } ...

Some argue that allowing null into the API of a class, in the form of possibly- null parameters or return values, should be avoided if possible : null references can only be used in a boolean test - any other use will throw a NullPointerException null references always represent special cases, and if these special cases can be removed, the code will be easier to understand null return values are error prone, since there is no way to ensure that the caller always does a check-for- null . methods which accept an explicit null reference as a valid argument are less intelligible at the point of call. The reader will usually need to consult documentation to determine what exactly the null argument means. If null is allowed for a method, then this should be clearly stated in its javadoc. Some follow the convention that all items are assumed to be non- null unless otherwise specified. Such a convention could be explicitly stated once in the javadoc overview.html . There is a v...

One of the most fundamental aspects of a programming language is how it initializes data. For Java, this is defined explicitly in the language . For fields and array components , when items are created, they are automatically set to the following default values by the system: numbers: 0 or 0.0 booleans: false object references: null This means that explicitly setting fields to 0, false, or null (as the case may be) is unnecessary and redundant. Since this language feature was included in order to, in part, reduce repetitive coding, it's a good idea to take full advantage of it. Insisting that fields should be explicitly initialized to 0, false, or null is an idiom which is likely inappropriate to the Java programming language. _______________________________________________