Aug 17

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

Tagged with:
Aug 14

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.

 

Tagged with:
Aug 11

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);

Tagged with:
Aug 07

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.

Tagged with:
Aug 04

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 :)

Tagged with:
Aug 01

Let’s have a closer look on method get() due to the error-proness during runtime:

For non-generics the return-value of get() is a reference to java.lang.Object, for generics a reference of the determined object-type. This means that for non-generics a turn into a primitive value can not take place since unboxing is only refereing to a wrapper (respectively their class-reference). A cast can help out in this case:

List <Integer> a= new ArrayList<Integer>(); // generic
a.add(3);
int b = a.get(0);
//assignemnt to int-value without problems due to Wrapper


List c = new ArrayList ();
// non-generic
c.add(3);


int d = (Integer)c.get(0);
// assignment is only possible with explicit cast since reference of java.lang.Object was returned

Tagged with:
Jul 28

Especially for certification it is necessary to distinguish if a warning, a CompilerError or a RuntimeError will appear. Therefore here a short comprehension:

CompilerErrors appear within others while explizit assignment of not allowed values to generics

warnings appear at mixture of (non-)generics in order to give the programmer the possibility to fix the code if necessary.

RuntimeError appear during runtime of the program, eg in case if processing should be continued with a unexpected type

Tagged with:
Jul 25

we know now that everything which is in context of mixing (non-)generics will be running as long as it is (although with warning) compilable. Under this circumstances also not really allowed object types can be added to the collection, but how does it work in the further context of the program? Although the object can be added it is still a String and not an Integer. Therefore the problems are foreseeable:

List <Integer> a= new ArrayList<Integer>();

a.add(1);
a.add(2);
a.add(3);

Insert e = new Insert();
e.add(a);
// adding String without problems
e.add(a); // adding another String without problems

a.remove(4);
// deletion of a a String is also no problem

for (int x= 0; x<a.size(); x++)

System.out.print(a.get(x)+” “); // output is also not a problem

int z=a.get(3); // assignment is a problem since a String can not be assigned to an int (ClassCastException during runtime)

Tagged with:
Jul 22

We already learned that during compilation a mixture of (non-)generic Collections is working – also for originally not allowed data-types. The next might be now: Is it running without problems?

The answer is yes.

Every generic possibility is checked during compilation. In case a compiler sees some problems, it is giving a warning. During runtime a generic collections is threated as a non-generic collection – JVM does not see any difference.

To make the point: Everything which can be compiled (with warning) can also run.

Tagged with:
Jul 19

As already explained mixing (non-)generics Collections is not a problem at all as long as we are dealing the same object-type, but what happens when we are dealing with different objects while mixing (non-)generic collections?

Let’s take our last example and change method

void add (List a){

a.add(5);

}

to

void add (List a){

a.add(“5″);

}

Now instead of the allowed Integer-Value a String is added. After all we have learned it should not work, what do you think?

Surprisingly the Compiler is making an exception; compilation and run are working without problems, only a warning is given.

So why is it so? The reason lies in the history of generics; since they came only with version 5 the code written in previous versions needed to be integrated. Therefore a mixture was made possible and tagged with a warning in order to give the programmer the possibility to decide if and how he wants to change the code.

Tagged with:
preload preload preload
http://www.wikio.de Blog Top Liste - by TopBlogs.de Blogverzeichnis - Blog Verzeichnis bloggerei.de Bloggeramt.de Software
Webbhotell Top Blogs