Sunday, October 31, 2010

And here it is - certification summary!


Well, I must admit that it's been some time since the last article but I was really overwhelmed recently – I had to accommodate in a new apartment, settle down all the things at university and finally I have started to work as a Java Software Developer. But anyway, now all the issues are resolved and I'm back to blogging again!

So today I would like to make a summary of OCPJP certification. First of all, I'm really glad that I've taken upon this endeavor. I have learnt many new things about Java that I didn't use before. Actually I'm not sure if I will ever use it but it's good to know it anyway ;-). And as luck would have it, I already have noticed how has my marked value increased. I did mention that I got a job, didn't I? ;-) Alright but you might probably want to know what I did in preparation for this exam. So obviously on the first place there is a book, the only one, don't even think about getting any other - SCJP Sun Certified Programmer for Java 6 Exam. I read it twice. The first time was a quick review of the book and getting familiar with some completely new areas. The second time though was much more careful and full of experiments with the code. And that is really vital! Experiment with the code – without this you will score much lower than you could if you did it. I know, it takes some time but trust me on that, it's really worth it. Ok, so let's assume that you already read the book, as many times as you wanted and you are wondering what next... Well, in my case it was a series of mock tests. Mostly by Whizlab (http://www.whizlabs.com/scjp/certification-exam.html). But in this place I have one more important tip. After solving a mock test also do some experiments with the code in exercises, especially the ones that were not correct. And I guess that's all! If you do more or less what I've described I'm sure you will do well on the exam!

As for me, my next goal on the Oracle Certification path is Oracle Certified Professional, Java EE 5 Web Component Developer! Soon, you will be able to follow my preparation's activities to this exam!

Saturday, September 11, 2010

Oracle Certified Professional Java SE 6 Programmer exam passed!


Yes, that's it! On the 6th of September I made it with 95% score. Not bad at all! It means 57 out of 60 questions answered correctly! Frankly speaking, the exam didn't seem to be easy - many questions required me to think deeply not as it was with the Whizlabs' tests. Even though, I had had some spare time left at the end to review all the questions and afterwards could hit the magic button "end" which surprisingly... ended the exam! But don't worry! The fact that I passed the exam doesn't mean that I will stop posting the articles related to it. I have a list of topics that I want to bring up here and after my short holidays that I'm on right now I will resume writing! I will also say something more about my scores of the exam and add some important notes that might be helpful for other people preparing to become certified!


Friday, August 27, 2010

Utility methods of wrapper classes.

Wrapper classes basically have two purposes: to wrap a primitive and to provide a set of utility functions dealing with some conversions. In this article I will focus on the latter objective.

The first function that I will cover here is a static valueOf() method. It takes as an argument a string and converts it to the desired wrapper object. In most cases you can also provide a second parameter that is an int radix which indicates the base of the first parameter. The valueOf() method is provided in most of the wrapper classes (except Character). It throws a NumberFormatException (it is not checked so you don't have to declare it) if the string provided can't be converted. Here are some legal uses of it:
Integer i1 = Integer.valueOf("3");
Integer i2 = Integer.valueOf(123);
Float f = Float.valueOf("2.2");

The second method is xxxValue() where in the place of xxx we can put any primitive. This function converts the value of a wrapped object to a primitive. The following code shows a few examples of how we should use it:
Float f = Float.valueOf("5.5");
byte b = f.byteValue();
short s = f.shortValue();
double d = f.doubleValue();

The next function that is important to remember is parseXXX(). It is static and takes a string as an argument and parses it into an appropriate primitive. It also throws NumberFormatException in case when the string arument is not well formated. Let's have a look at the following demonstration code:
double d = Double.parseDouble("123.456");
int i = Integer.parseInt("345");
byte b = Byte.parseByte("127");

And that's it! Three useful and important methods that we should know for the exam!

Wednesday, August 25, 2010

No more Sun Certified Java Programmer!

Erm... nearly. If you want to become one you should simply hurry up. You have 7 days for that and starting on 1st September you will be named Oracle Certified Professional Java SE 6 Programmer. That's another outcome of the acquisition Sun by Oracle that has had place at the beginning of this year.

As for me the name of the certificate doesn't really matter but what actually pops up in my mind is the question whether and when the employers will become familiar with the new name. Let's be honest - one of the reasons of why we become certified is the fact that it adds a new valuable element to our CV. But for this, the potential employer must be familiar with the title. Recently I read on a forum that Oracle sends some newsletters about the naming changes for the interested people (you probably need an account in the Oracle's Education Center) but for sure it will take some time to spread the word.

Nevertheless, below is the link to Oracle's website with additional information and names of the other exams. Yes! All the names has been changed!

Oracle Certification Program

Friday, August 20, 2010

Assignments.

By the title I actually mean the 3rd chapter of the K&B SCJP book. I have to admit that it was really surprising. I have learnt many new things that I was completly unaware of. Of course, in the real projects, when you use some IDE it's nearly impossible to make mistakes of this sort but on the exam they can be very savage. So below you will find some important points from this chapter that you really should pay attention to, during the exam.

First, we'll talk about the literals. Remember that every integer literal is an int. So there is no problem if we want to do the following assignments:
int a = 5; (fits well)
long b = 6; (fits well since long is bigger than int)
but what if we try to assign the integer literal (so an int) to the smaller type? Let's have a look!
byte c = 7;
And yeah, there is still no problem. That's of course good for us but basing on the above that shouldn't work. Well, that happens because the compiler makes an implicit cast so in fact, it looks like this:
byte c = (byte)7;
Alright. That's very convenient for us. But this implicit cast is applied only to literals! So this is not going to work:
int a = 5;
byte b = a;
To compile the code consisting of the above assignments you need to do an explicit cast:
int a = 5;
byte b = (byte)a;
Also keep in mind the following rule. The result of any expression involving an int or anything smaller, like byte and short will result in an int! So the following will... not compile!
byte a = 5;
byte b = 1;
byte c = a + b;
You need to put an explicit cast! One more thing about the floating points literals. They are always doubles. And here the compiler won't make an implicit cast, the following code will not compile:
float d = 2.5;
Instead you should write:
float d = (float)2.5;
Or mark that what you mean is really a float by adding and f or F at the end of the literal:\
float d = 2.5f;
Ok, that's it for the literals! Now let's move on to the primitive casting.
First of all, it's important to remember that the implicit cast happens when we assing a smaller to a bigger. So for instance:
int a = 5;
byte b = (byte)a;
long c = 'a' + 'b';

a = b;
c = a;
c = b;
These are all legal assignments. But the followings are not:
b = a;
b = c;
a = c;
And what do we need? An explicit cast!
b = (byte)a;
b = (byte)c;
a = (int)c;
Et voila monsieur! Also the same thing happens with floating points. All the following are legal:
double d = 2.5;
float f = 3.4f;
int i = 12;
long l = 45;

d = l; // assigning long to double
d = f; // assigning float to double
f = i; // assigning integer to float
But in case when a truncation may occur we have to make an explicit cast otherwise our code will produce an error.
The followings are legal but the cast is necessary:
double d = 2.5;
float f = 3.4f;
int i = 12;
long l = 45;

f = (float)d;
i = (int)f;
l = (long)d;
That's a piece of cake but I'm sure that you've found here something new and interesting for you!

Thursday, August 19, 2010

Downcasting and a compiler.

Today I will write shortly about the downcasting and especially about the way the compiler can assist us while doing this. Actually it can't do a lot. It trusts us when we do the downcast that it is actually possible. Let's consider this example:
 class Vehicle {}
class Car extends Vehicle {}
public class Sfield {
public static void main(String[] args) {
Vehicle v = new Vehicle();
Car c = (Car)v;
}
}

This example compiles without any problem. But what will happen is... a java.lang.ClassCastException thrown! However there is one situation, when the compiler can help us. If we try to downcast the class from the different inheritance tree the compiler will let us know about it during the compilation time and not the runtime! For instance:
 class Vehicle {}
class Car extends Vehicle {}
public class Sfield {
public static void main(String[] args) {
String v = new String("Vehicle");
Car c = (Car)v;
}
}

So if the compiler knows that the downcast will not work for sure it will manifest it with:
Exception in thread "main" java.lang.Error: Unresolved compilation problem:
Cannot cast from String to Car
But in the first example it might happen that the v references to the Car object. But it was not possible to verify this at the compilation time.

Monday, August 16, 2010

Inheritance and the default superclass constructor.

In this short article I will write about the situation, when we extend some class but its default constructor is not accesible for us. For example it has a private modifier or a default one and we are in a different package. If this is a case, we have to remember to use another (accessible) superclass constructor in our subclass constructor. If we don't do it, a compiler will try to insert a call to the default constructor super() which obviously will not work. Below is an example of this:
 class U1 {
private U1() { }
public U1(int x) { }
}
class U2 extends U1 {
U2() {
System.out.println("U2 construction...");
}
}

To mitigate the situation we should explicitly use the public but not default constructor as in the following code:
 class U1 {
private U1() { }
public U1(int x) { }
}
class U2 extends U1 {
U2() {
super(5);
System.out.println("U2 construction...");
}
}