Bytecrack’s Blog

A friendly place for J Tech savvy’s

Open Solaris 11 Launch

Why use the OpenSolaris Operating System? Because only OpenSolaris offers unique features like TimeSlider, ZFS as the default filesystem, an enhanced Image Packaging System (IPS), COMSTAR, DTrace-enabled packages for extreme observability and performance tuning, D-Light, and much more. OpenSolaris provides the ideal open-source platform to develop your next-generation applications. And when you are ready to deploy, OpenSolaris has the world-record performance you want and the reliability you need — all backed by world-class support from Sun.

Download OpenSolaris 2008.11 now and experience it from the Live CD or install it on your favorite system. OpenSolaris supports more than 1000 systems, from laptops to the latest multicore servers. Join the community, share your experiences and start contributing your applications to the package repository. You can also join the OpenSolaris.org community of developers building the systems software you see here.

 

Download OpenSolaris : http://www.opensolaris.com/

 

Source – http://www.opensolaris.com/

February 19, 2009 Posted by | Uncategorized | Leave a 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 – http://blogs.sun.com/javafx/

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.

figure1

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. 
figure2

All content from  http://www.dave-robinson.net/tuning/jvm_details.html 

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