SCJA Exam Breakup

This post from Javaranch is sort of helpful in understanding the structure of the exam

http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=84&t=000067

SCJA - Fundamental object oriented concepts 1.1

In my next few blogs i'll be preparing notes on each objective in the Sun Certified Java Associate Beta exam, which i'm planning to take on July 1st.

1.1)Describe, compare, and contrast primitives (integer, floating point, boolean, and character), enumeration types, and objects
____________________________________________________________________

The first important step is to break down the classification of integral types:

---------Integral -> (Integer)byte, short,int,long(Character) char
Primitive Types in Java -----------Float ->Float,Double
---------Boolean --> boolean

Primitive data types represent a range of values in the programming language. If you want to represent these types as objects, then there are corresponding wrapper types viz. Integer,Float,Long etc.

The range of primitive data type is worth memorizing, (I used the table from Mughal and Rassmussen)

ENUMERATION TYPES:

The enumerated type is a new introduction in J2SE 5.0 . Its a type whose legal values consist of a set of constants:

Eg: enum cars(MCLAREN,RENAULT,FERRARI,TOYOTA,BMW,HONDA,SAUBER,JORDAN);

You would use enum types whenever you would want to represent a fixed setof constants (known to you at compile type). Unlike C++ enum in Java is a Class!! Not convincing enough right?! Ok Check this out:

public enum FormulaTeams{
MCLAREN (Raikkonen,Montoya);
RENAULT (Alonso,Fisichella);
FERRARI (Schumacher,Barrichelo);
TOYOTA (Trulli,Schumacher);
BMW (Webber,Heidfeld);
HONDA (Button,Sato);
SAUBER(Villnueave,Massa);
JORDAN (Karthikeyan,Montiero);

private final String driver1;
private final String driver2;

//Note that the constructor is private, it has to be!
FormulaTeams(String driver1,String driver2)
{
this.driver1=driver1;
this.driver2=driver2;
}

public String d1() {return driver1;}
public String d2() {return d2;}

}

public static void main(String args[])
{
for(FormulaTeams f: f.values()){
System.out.println("Standings at the End of 2005");
System.out.println("Driver 1"+f.d1()+"Driver 2"+f.d2());
}
}

Pretty cool huh? try doing the same in 1.4 (I know you'll be using a data structure from java.util.*) . Ok you'll find a better more Object Oriented example here:
http://java.sun.com/docs/books/vmspec/2nd-edition/html/Concepts.doc.html#24465


}




A Few Caveats:

a) Integer datatypes are signed integers and are represented by their 2's complement.
b) character values are all unsigned integers that denote 2^16 characters in the unicode character set.
c)Floating point representation can be 32 or 64 bit in width, due to size for representation being finite, most results of floating point computations are finite. To ensure consistency for these approximations across all JVM implementations you can use the "strictfp " modifier.
http://java.sun.com/docs/books/vmspec/2nd-edition/html/Concepts.doc.html#24465
d)There's one limitation of enum types: although enum types are classes, you cannot define a hierarchy of enums. In other words, it's not possible for one enum type to extend another enum type (That wouldn't make sense anyhow)

Random Playlist

My recent Playlist:

Boulevard of Broken Dreams - Greenday
American Idiot-Greenday
B.Y.O.B-System of a down
Sittin here waitin wishin- Jack Johnson
Learning to Fly-Foo Fighters
Somewhere only we Know- Keane
Speed of sound - Coldplay

Data Dictionaries and Metadata:

Its amazing how many J2EE companies these days are building on the concept of Data Dictionaries generating components, the paradigm always existed in .NET and preceding object based technologies released by Microsoft. These data dictionaries seek to capture most of the UI elements that would be required on an application, into the database. These UI elements would include Lookups, Dropdowns, Typeahead lookups, Text Feilds, Users, User Roles from LDAP/AD, Labels and so on. Now if i develop a huge enterprise J2EE application which is not hosted but deployed at different locations, it makes sense for me to persist definitions for these commonly used UI elements and other Business objects on the Database and sort of call it the metadata, generate components from them and have a CRUD interface to edit this metadata and customise these components. This reduces application development to a Metadata editing process. This approach helps a lot of organizations that develop apps like CRM, ERP and so on which are based on J2EE. The engineering team can develop applications and let loose professional service people to generate their applications by editing the metadata and bringing these components to life.

Well the biggest drawback to this widely used approach? More complex the application, more humongous will be the Metadata/Data Dictionary, Plus since its assume to be a simple CRUD operation, I haven't seen engineers impose any rules to configure the metadata based on some Grammar. This creates a huge burden on the person trying to edit the compoents through the metadata in trying to build the application.