May 14

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

  • Print
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • Add to favorites
  • RSS
  • Blogosphere
  • email
  • PDF
  • Wikio
  • Technorati
  • Digg
  • DZone
Tagged with:
May 07

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.

  • Print
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • Add to favorites
  • RSS
  • Blogosphere
  • email
  • PDF
  • Wikio
  • Technorati
  • Digg
  • DZone
Tagged with:
Apr 28

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:

  • primitive data types can be taken in complex dta structures (containers)
  • primitive data type is capsulated through the wrapper class
  • functions are used to access the values as well as for transfer – functions

More … and especially examples will follow within the next posts

  • Print
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • Add to favorites
  • RSS
  • Blogosphere
  • email
  • PDF
  • Wikio
  • Technorati
  • Digg
  • DZone
Tagged with:
Apr 21

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

}

}

}

  • Print
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • Add to favorites
  • RSS
  • Blogosphere
  • email
  • PDF
  • Wikio
  • Technorati
  • Digg
  • DZone
Apr 14

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 {}

  • Print
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • Add to favorites
  • RSS
  • Blogosphere
  • email
  • PDF
  • Wikio
  • Technorati
  • Digg
  • DZone
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

  • Print
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • Add to favorites
  • RSS
  • Blogosphere
  • email
  • PDF
  • Wikio
  • Technorati
  • Digg
  • DZone
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.

 

  • Print
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • Add to favorites
  • RSS
  • Blogosphere
  • email
  • PDF
  • Wikio
  • Technorati
  • Digg
  • DZone
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);

  • Print
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • Add to favorites
  • RSS
  • Blogosphere
  • email
  • PDF
  • Wikio
  • Technorati
  • Digg
  • DZone
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.

  • Print
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • Add to favorites
  • RSS
  • Blogosphere
  • email
  • PDF
  • Wikio
  • Technorati
  • Digg
  • DZone
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 :)

  • Print
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • Add to favorites
  • RSS
  • Blogosphere
  • email
  • PDF
  • Wikio
  • Technorati
  • Digg
  • DZone
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