Generally (with the exception of char) there are always two possibilities to call a constructor: primitve data type and String.
Therefore we can call the wrapper constructors also in two different ways:
Integer a = new Integer (23); // constructor-call with int-value
Integer b = new Integer (“23″); // constructor-call with String-Value
first of all I have an overview for you:
| primitive data type |
wrapper class |
arguments for constructor |
|---|---|---|
| boolean | Boolean | boolean or String |
| byte | Byte | byte or String |
| char | Character | char |
| double | Double | double or String |
| float | Float | float, double or String |
| int | Integer | int or String |
| long | Long | long or String |
| short | Short | short or String |
| void | Void | void |
since Void is not relevant for certification I will not mention it in the next posts.
First of all a short explanation about wrapper
wrapper take primitive data types in an object.
Aditionally there is a wrapperclass for void which is not a primitive data type.
Advantages of wrapper are:
More … and especially examples will follow within the next posts
An error can also be thrown more than once:
class Shop {
static void test () throws Error {
throw new Error ();
}
public static void main(String args[]) {
try {
test();
}catch (Error e) {
e.printStackTrace();
throw e; // error is thrown again
}
}
}
Although it doesn’t make sense – there is a possibility to throw and catch errors in a controlled way:
class Shop {
static void test () throws Error {
throw new Error ();
}
public static void main(String args[]) {
try {
test();
} catch (Error e) { e.printStackTrace(); }
}
}
errors can be threated like unchecked exceptions – the declarations in the header are as well optional as the try/catch/finally block and can be omitted. Definitions in own error-classes are also possible ie:
class x extends Error {}
We already learned in previous examples that assignment of instances of the subclass to a list of upper classes is working without problems:
a.add(new SalesPerson());
a.add(new ControlingStaff());
Let’s have a look on overwritten methods, eg
class SalesPerson extends Employee{String getName(){ return(“SalesPerson”);}}
class ControlingStaff extends Employee{ String getName(){ return (“ControlingStaff”);}}
Those functions can be called directly without any error/warning since there is during runtime no difference between Array and ArrayList:
System.out.println(a.get(0).getName()); // Output: SalesPerson
System.out.println(a.get(1).getName()); //Output: ControlingStaff
Let’s go even deeper in the tricks of generics in methods and change the definitions therefore a little bit:
List <SalesPerson> a = new ArrayList <SalesPersonr>();
a.add(new SalesPerson());
a.add(new SalesPerson());
SalesPerson i [] = {new SalesPerson(), new SalesPerson ()};
The methods remain unchanged:
public static void checkStatus_array (Employee[] a){ … }
public static void checkStatus_list (List<Employee> a){ … }
Also here we are calling the appropriate functions :+
checkStatus_list(a); // CompilerError
checkStatus_array(b); // compiling and running without problems
In both cases “SalesPerson” is transfered and type “Employee” taken over. For Arrays it is working smoothly, but not for List; a cast does not take place. Therefore always the exact object-type need to be transfered. In contradiction to assignments a explizit cast is not helpful in this case.
Let’s have a look on an 2 similar methods:
public static void checkStatus_array (Employee [] a){ … }
public static void checkStatus_list (List<Employee> a){ … }
Intentionally they should work similar, what do you think?
First of all the definitions:
List <Employee> a= new ArrayList <Employee>();
a.add(new SalesPerson());
a.add(new ControllingStaff());
Employee b [] = {new SalesPerson(), new ControlingStaff ()};
Calling the own methods is smoothly:
checkStatus_list(a);
checkStatus_array(b);
In contradiction calling the methods of each other lead to CompilerError:
checkStatus_list(b);
checkStatus_array(a);
First of all an extended comprehension before we are going into the specials of generics; let’s start with the following declarations:
Employee () { … }
SalesPerson extends Employee () { … }
ControllingStaff extends Employee () { … }
A cast in an upper class is possible without problems:
Employee a = new SalesPerson ();
Employeer b = new ControllingStaff ();
Same is applicable for arrays:
Employee [ ] c = {new SalesPerson(), new ControllingStaff () };
But this is not working for Collections:
List <Employee> b = new ArrayList <SalesPerson>();
What is working is the assignment of sub-classes to the collection of the upper class :
List <Employee> d = new ArrayList <Employee>();
d.add(new SalesPerson());
d.add(new ControllingStaff());
No warning is produced, the code is working fine through the hole program-flow.
As we already know there is no problem in assigning different Collections on the base-object:
List <Integer> a= new ArrayList<Integer>();
It seem to be clear, that it should work with object-types in the same way, but this is not the case:
import java.util.List;
import java.util.ArrayList;
class Employee{
public static void main(String args[])
{
List <Employee> b = new ArrayList <SalesPerson>(); // CompilerError
SalesPerson a = new SalesPerson();
}
}
class SalesPerson extends Employee{ }
The rule behind is quite easy: declaration of types and transfer need to match exactly, although it is different for arrays;
Employee [ ] c = new SalesPerson[3]; is working without problems – so don’t get confused during certification 
