Tuesday, May 12, 2020

java puzzlers from oca part 7


In this part of the Java Puzzlers from OCA series, I will show multiple ways of defining Strings and potential surprises related to that. Two basic types of creating Strings are creation with new keyword, and by just using the string literal.
String strWithNew = new String("hey");
String strWithLiteral = "ho";
As Strings are frequently used JVM uses a string pool and use the values in it so it won't have to create new objects for same values again and again. So seeing that the object address of same string literals are same should not be a surprise.
public class Puzzler {

    public static void main(String[] args) {

        String s1 = "myString";
        String s2 = "myString";

        System.out.println(s1 == s2); // true
    }
}
Ok then, this should be the same also right?
public class Puzzler {

    public static void main(String[] args) {


        String s1 = new String("myString");
        String s2 = new String("myString");

        System.out.println(s1 == s2);
    }
}
Not really. This will print "false". So if I create a new string with literal "myString" it is placed in the string pool. If I create it with new keyword then it's not searched in the pool, and when it's created it's also not placed in the string pool.
public class Puzzler {

    public static void main(String[] args) {


        String s1 = new String("myString");
        String s2 = new String("myString");
        String s3 = "myString";
        String s4 = "myString";

        System.out.println(s1 == s2);
        System.out.println(s2 == s3);
        System.out.println(s3 == s4);
        System.out.println(s1 == s4);
    }
}
I hope you can guess what happens above. s1 creates a new string and does not put it in the pool, s2 does the same thing. s3 takes a look to string pool does not see myString and creates it and places in the pool. s4 says "ah ok it is in the pool". So if we count how many strings are created, it is 3 and if we count what's placed in the pool it's 1 (myString). false, false, true, false are what's printed to the console.

Saturday, May 9, 2020

java puzzlers from oca part 6


Even for new Java developers, constructors are probably no big mystery. In essence, when you create an instance of a class, the constructor of this class is started. In the 6th part of Java Puzzlers series, we will see a case related to constructors.
public class Puzzler {

    public Puzzler(){
        System.out.println("Puzzler no arg constructor");
    }

    public static void main(String[] args){
        Puzzler puzzler = new Puzzler();
    }
}
In the example above Puzzler() constructor will start and "Puzzler no arg constructor" will be printed to the screen. Now lets see a new example.
public class Puzzler {

    public void Puzzler(){
        System.out.println("Puzzler no arg constructor?");
    }

    public static void main(String[] args){
        Puzzler puzzler = new Puzzler();
    }
}
As you can see we added a return value to the constructor of Puzzler and you may expect that "Puzzler no arg constructor?" will get printed but this is not right. When we add a return value to the constuctor, it stops being a constructor. So it won't get started when a new instance is created.

java puzzlers from oca part 5

In the fifth part of the Java Puzzlers series, we will see something related to X.parseX(String s) methods.


You can see what we expect from X.parseX() methods.
public class Puzzler {

    public static void main(String[] args){
        int i = Integer.parseInt("2"); 
        System.out.println(i); // prints 2
    }
}

We give the methods a String that can be converted to the primitive representation and hope for the best. Now lets check another example which will give us a NumberFormatException.
public class Puzzler {

    public static void main(String[] args){
        int i = Integer.parseInt("integer"); // java.lang.NumberFormatException: For input string: "integer"
    }
}

As the input is a word and not something that can be parsed to an integer, we get NumberFormatException. What happens above is consistent for each number type. So Integer, Byte, Short, Long, Double, Float won't surprise you when you call their parse methods with some random String. You'll get a NumberFormatException.
Now lets check what happens with boolean.
public class Puzzler {

    public static void main(String[] args){
        final boolean b1 = Boolean.parseBoolean("boolean?");
        System.out.println(b1);
    }
}
Can you guess what happens? The parse call will probably throw java.lang.BooleanFormatException, right? Not really. If you run that, it'll print "false" to the screen. The reason is Boolean.parseBoolean() just accepts anything and if it can't parse it, it just returns "false" value. Now lets see the other example.
public class Puzzler {

    public static void main(String[] args){
        final boolean b2 = Boolean.parseBoolean("TrUe");
        System.out.println(b2);
    }
}
You probably expect false again? That's not the case because parseBoolean is case insensitive and will return "true" in this case.

Saturday, May 2, 2020

java puzzlers from oca part 4

In the fourth part of Java Puzzlers, we have something related to char type.


public class Puzzler {

    public static void main(String[] args){
        char myChar = 'a';
        myChar++;

        System.out.println(myChar);
    }
}

You may have guessed it. It will print "b" and the reason for it is that char type is unsigned numeric primitive in the disguise of a character. So if I add one then I'll get the next character in unicode representation.

Then let's take a look at that one


public class Puzzler {

    public static void main(String[] args){
        char myChar = 'a';

        System.out.println(myChar + myChar);
    }
}
Will this print "aa"? Or  which's 97 + 97 = 194 (where 97 is value of 'a'). I don't know if you guessed it right but the result is neither. It's "194". When Java sees plus it tells "hmm that's an addition not a concat" and adds myChars up and returns the int value for it.

java puzzlers from oca part 3

In this third part of Java puzzlers, we will see a surprise in variable naming restrictions.


If I show you this, I'm sure you won't be surprised that this does not compile. static is one of the reserved keywords so why should it work?
public class Puzzler {

    public static void main(String[] args){

        int static = 2;
    }

}
Now I'll ask you a more difficult one. What you think about the below code. Will this compile?
public class Puzzler {

    public static void main(String[] args){
        int bool = 0;
        int integer = 1;
        int const = 2;
        int goto = 3;
    }
}

None of these should be reserved keyword. This is not C right? If you thought that it will compile, you're wrong. const and goto are reserved keywords, but bool and integer are fine.