Bytecrack’s Blog

A friendly place for J Tech savvy’s

New forums arrival

Hello all , New forum arrival at for coldfusion programmers.


March 27, 2009 Posted by | Material | , | Leave a comment

Introduction to the Android Open Source Project

An introduction to android project by google.Android is an joint venture of T-Mobiles,HTC and google.

For more information about android check the following portals

February 24, 2009 Posted by | Material | , , | Leave a comment

Android OS for mobiles

Android is a mobile operating system meant to be run on a wide array of devices, with very different hardware configurations. Some devices, like the T-Mobile G1, can change their hardware configuration at runtime. For instance, when you open the keyboard, the screen change from the portrait orientation to the landscape orientation. To make Android applications development easier, the OS automatically handles configuration changes and restart the current activity with the new configuration. This is the default behavior that lets you declare resources like layouts and drawables based on the orientation, screen size, locale, etc. If you are not familiar with the way Android handles resources, We highly suggest you to read the official documentation on resources.

While this behavior is really powerful, since your application adapts automatically to the device’s configuration at runtime, it is sometimes confusing for new Android developers who wonder why their activity is destroyed and recreated. Facing this “issue,” some developers choose to handle configuration changes themselves which is, in my opinion, a short-term solution that will complicate their life when other devices come out or when the application becomes more complex. The automatic resource handling is a very efficient and easy way to adapt your application’s user interface to various devices and devices configurations. It sometimes comes at a price though.

When your application displays a lot of data, or data that is expensive to fetch, the automatic destruction/creation of the activities can be lead to a painful user experience. Take the example of Photostream, a simple Flickr browsing application I wrote for the release of Android 1.0. After you launch the application and choose a Flickr account, the application downloads a set of 6 photos (on a T-Mobile G1) from the Flickr servers and displays them on screen. To improve the user experience, I also use slightly different layouts and drawables in portrait and landscape, and this is what the result looks like:


Source –

Source –

February 20, 2009 Posted by | Material | 1 Comment

Java FX – Rich Internet Application

JavaFX Production Suite simplifies the interaction between graphic designers and developers that is needed to create applications with expressive content.

Production Suite contains plugins for Adobe Illustrator and Photoshop, which enable graphic designers to export their artwork to JavaFX graphics format. This new format was designed to facilitate the ability of designers and developers to work concurrently on the graphics and the application, merely dropping in new versions of the graphic as they become available. Graphic objects in the artwork can be exported with IDs that are picked up by the JavaFX application, so developers can write code based on those IDs before the graphic even exists. The look of the graphic can change substantially as long as the IDs remain the same.

Source –

February 19, 2009 Posted by | Material | Leave a comment

JVM details

JVM Details  The Architecture of the Java Virtual Machine

Some runtime data areas are shared among all of an application’s threads and others are unique to individual threads. Each instance of the Java virtual machine has one method area and one heap. These areas are shared by all threads running inside the virtual machine. When the virtual machine loads a class file, it parses information about a type from the binary data contained in the class file. It places this type information into the method area. As the program runs, the virtual machine places all objects the program instantiates onto the heap. See Figure 1 for a graphical depiction of these memory areas.


The Class Loader Subsystem

Every Java virtual machine implementation has a bootstrap class loader, which knows how to load trusted classes, including the classes of the Java API. The Java virtual machine specification doesn’t define how the bootstrap loader should locate classes.

In 1.2, the bootstrap class loader of Sun’s Java 2 SDK only looks in the directory in which the system classes (the class files of the Java API) were installed. The bootstrap class loader of the implementation of the Java virtual machine from Sun’s Java 2 SDK does not look on the CLASSPATH. In Sun’s Java 2 SDK virtual machine, searching the class path is the job of the system class loader, a user-defined class loader that is created automatically when the virtual machine starts up. The Method Area

Inside a Java virtual machine instance, information about loaded types is stored in a logical area of memory called the method area. When the Java virtual machine loads a type, it uses a class loader to locate the appropriate class file. The class loader reads in the class file–a linear stream of binary data–and passes it to the virtual machine. The virtual machine extracts information about the type from the binary data and stores the information in the method area. Memory for class (static) variables declared in the class is also taken from the method area. The following information is stored in the method area:

  • Type Information 
    • The fully qualified name of the type
    • The fully qualified name of the type’s direct superclass (unless the type is an interface or class java.lang.Object, neither of which have a superclass)
    • Whether or not the type is a class or an interface
    • The type’s modifiers ( some subset of` public, abstract, final)
    • An ordered list of the fully qualified names of any direct superinterfaces


  • The Constant PoolFor each type it loads, a Java virtual machine must store a constant pool. A constant pool is an ordered set of constants used by the type, including literals (string, integer, and floating point constants) and symbolic references to types, fields, and methods.
  • Field InformationFor each field declared in the type, the following information must be stored in the method area:
    • The field’s name
    • The field’s type
    • The field’s modifiers (some subset of public, private, protected, static, final, volatile, transient)


  • Method InformationFor each method declared in the type, the following information must be stored in the method area:
    • The method’s name
    • The method’s return type (or void)
    • The number and types (in order) of the method’s parameters
    • The method’s modifiers (some subset of public, private, protected, static, final, synchronized, native, abstract)
    • An exception table


  • Class VariablesClass variables are shared among all instances of a class and can be accessed even in the absence of any instance. These variables are associated with the class–not with instances of the class–so they are logically part of the class data in the method area. Before a Java virtual machine uses a class, it must allocate memory from the method area for each non-final class variable declared in the class.Constants (class variables declared final) are not treated in the same way as non-final class variables. Every type that uses a final class variable gets a copy of the constant value in its own constant pool. As part of the constant pool, final class variables are stored in the method area–just like non-final class variables. But whereas non-final class variables are stored as part of the data for the type that declares them, final class variables are stored as part of the data for any type that uses them.
  • A Reference to Class ClassLoaderFor each type it loads, a Java virtual machine must keep track of whether or not the type was loaded via the bootstrap class loader or a user-defined class loader. For those types loaded via a user-defined class loader, the virtual machine must store a reference to the user-defined class loader that loaded the type. This information is stored as part of the type’s data in the method area.
  • A Reference to Class ClassAn instance of class java.lang.Class is created by the Java virtual machine for every type it loads. The virtual machine must in some way associate a reference to the Class instance for a type with the type’s data in the method area.
  • Method TablesFor each non-abstract class a Java virtual machine loads, it could generate a method table and include it as part of the class information it stores in the method area. A method table is an array of direct references to all the instance methods that may be invoked on a class instance, including instance methods inherited from superclasses. A method table allows a virtual machine to quickly locate an instance method invoked on an object.

The Heap

No matter what object representation an implementation uses, it is likely that a method table is close at hand for each object. Method tables, because they speed up the invocation of instance methods, can play an important role in achieving good overall performance for a virtual machine implementation. Method tables are not required by the Java virtual machine specification and may not exist in all implementations. Implementations that have extremely low memory requirements, for instance, may not be able to afford the extra memory space method tables occupy. If an implementation does use method tables, however, an object’s method table will likely be quickly accessible given just a reference to the object. 

All content from 

February 19, 2009 Posted by | Material | Leave a comment