Rihanna (Caribbean Queen)
15 years ago
Monday, April 16, 2012
Starting Terracotta Server as a Windows service
Wednesday, January 7, 2009
BlanK Finals,Reflection in java
Blank Finals:-
As we know that local variables, method parameters, and exception parameters of catch statements may be declared final. A related change is that final fields do not require initializers. In Java 1.0, any final field had to be initialized as part of the field declaration. In Java 1.1, this restriction has been relaxed. A field or local variable can be declared final without specifying an intial value as part of the declaration. These "blank finals," as they are called, must have a value assigned to them before they are ever used, of course. And, once a value has been assigned to a blank final, that value can never be changed. This allows you, for example, to use an instance initializer or a constructor to compute a value for a final field.
Blank finals are particularly useful in defining immutable data types. They allow a class to have immutable fields that are initialized based on run-time arguments to a constructor. Once assigned, these fields cannot be accidentally or maliciously changed.
Reflaction:-
Reflection in Java 1.1 refers to the ability of Java classes to reflect upon themselves, or to "look inside themselves." The java.lang.Class class has been greatly enhanced in Java 1.1. It now includes methods that return the fields, methods, and constructors defined by a class. These items are returned as objects of type Field, Method, and Constructor, respectively. These new classes are part of the new java.lang.reflect package, and they each provide methods to obtain complete information about the field, method, or constructor they represent. For example, the Method object has methods to query the name, the parameter types, and the return type of the method it represents.
Besides allowing a program to inspect the members of a class, the java.lang.reflect package also allows a program to manipulate these fields and methods. The Field class defines methods that get and set the value of the represented field for any given object of the appropriate type. Similarly, the Method object defines an invoke() method that allows the represented method to be invoked, and the Constructor class defines a newInstance() method that creates a new object and invokes the represented constructor on it. java.lang.reflect also defines an Array class. It does not represent a specific array, but defines static methods that read and write array elements and dynamically create new arrays.
With the addition of reflection, the Class class has been expanded to represent not just Java classes, but any Java type, including primitive types and array types. There is a special Class object that represents each of the eight Java primitive types, and another special Class object that represents the void type. These special Class objects are available as constants in the wrapper objects for the primitive types. Integer.TYPE is a Class object that represents the int type, for example, and Void.TYPE is a Class object that represents the void type.
As we know that local variables, method parameters, and exception parameters of catch statements may be declared final. A related change is that final fields do not require initializers. In Java 1.0, any final field had to be initialized as part of the field declaration. In Java 1.1, this restriction has been relaxed. A field or local variable can be declared final without specifying an intial value as part of the declaration. These "blank finals," as they are called, must have a value assigned to them before they are ever used, of course. And, once a value has been assigned to a blank final, that value can never be changed. This allows you, for example, to use an instance initializer or a constructor to compute a value for a final field.
Blank finals are particularly useful in defining immutable data types. They allow a class to have immutable fields that are initialized based on run-time arguments to a constructor. Once assigned, these fields cannot be accidentally or maliciously changed.
Reflaction:-
Reflection in Java 1.1 refers to the ability of Java classes to reflect upon themselves, or to "look inside themselves." The java.lang.Class class has been greatly enhanced in Java 1.1. It now includes methods that return the fields, methods, and constructors defined by a class. These items are returned as objects of type Field, Method, and Constructor, respectively. These new classes are part of the new java.lang.reflect package, and they each provide methods to obtain complete information about the field, method, or constructor they represent. For example, the Method object has methods to query the name, the parameter types, and the return type of the method it represents.
Besides allowing a program to inspect the members of a class, the java.lang.reflect package also allows a program to manipulate these fields and methods. The Field class defines methods that get and set the value of the represented field for any given object of the appropriate type. Similarly, the Method object defines an invoke() method that allows the represented method to be invoked, and the Constructor class defines a newInstance() method that creates a new object and invokes the represented constructor on it. java.lang.reflect also defines an Array class. It does not represent a specific array, but defines static methods that read and write array elements and dynamically create new arrays.
With the addition of reflection, the Class class has been expanded to represent not just Java classes, but any Java type, including primitive types and array types. There is a special Class object that represents each of the eight Java primitive types, and another special Class object that represents the void type. These special Class objects are available as constants in the wrapper objects for the primitive types. Integer.TYPE is a Class object that represents the int type, for example, and Void.TYPE is a Class object that represents the void type.
Tuesday, January 6, 2009
Applets in JAVA
Applet class can be used to enhance the way your applet works. Recall that the Applet class provides the foundation for creating applets-Java applications that run in a browser environment. Besides launching your applet, the Applet class provides many useful services. It can be used to load image and audio files, work with URLs, and access the native browser environment. Since the Applet class is also a component of the AWT package .Applet objects provide many of the visual features that are part of the standard AWT repertoire, especially using the Graphics class for painting text, shapes, and images. Since The Applet class is a subclass of the AWT Component class, it can handle events such as mouse events and keystrokes.
Four often misunderstood Applet methods are overridden to manage the life cycle of an applet. None of these methods are required to be overridden, although their use will generally give you a more stable applet. These are the four methods:
init() This is used to initialize an applet whenever it is loaded. You typically override this method to set up resources that will be used throughout an applet, such as fonts, or to initialize variables. This method is called once and only once during the lifetime of your applet. However, if the applet is reloaded for some reason or another, the init() method will be called again. Some Java literature may lead you to believe that you have to always override this method. This is not true! You need to override init() only when your applet's circumstances dictate that you should. A good example of this is initializing resources, such as AWT components.
start() This is called whenever the HTML document on which an applet resides becomes the current page of a browser. When an applet is first run, the start() method is called after init(). Unlike the latter, however, start() will be called whenever the user visits the applet's page. Two very important types of activities should be located in the start() method. The show() method of instances of the Frame class are best called in the start() method. Since Frames occur outside the confines of an applet page, they will stay onscreen even after you have left the page. Consequently, they should be shown when you enter the page and hidden when you leave (see the stop() description method that follows). There will be an example in the upcoming listings. The start() method is also a good place to begin threads since their existence is also not confined to the page where they began.
stop() This method is called whenever the user leaves a page-it is the converse of the start() method. Therefore, it's a good place to hide frames and terminate threads.
destroy() The destroy() method is called whenever the applet is being shut down. Typically, this will occur when the browser is being closed, although there could be other circumstances that could lead to destroy() being invoked. This method is a good place to do some cleanup. However, since it's unpredictable when destroy() will be called, it should be used with some discretion.
Wednesday, December 31, 2008
Inner classes in JAVA
The Java programming language allows you to define a class within another class. Such a class is called a nested class.
Inner classes nest within other classes. A normal class is a direct member of a package, a top-level class. Inner classes, which became available with Java 1.1, come in four flavors:
- Static member classes
- Member classes
- Local classes
- Anonymous classes
a static member class is a static member of a class. Like any other static method, a static member class has access to all static methods of the parent, or top-level, class.
Static nested classes are accessed using the enclosing class name:
For example, to create an object for the static nested class, use this syntax:OuterClass.StaticNestedClass
OuterClass.StaticNestedClass nestedObject = new OuterClass.StaticNestedClass();
Like a static member class, a member class is also defined as a member of a class. Unlike the static variety, the member class is instance specific and has access to any and all methods and members, even the parent's this reference.
Local classes are declared within a block of code and are visible only within that block, just as any other method variable.
an anonymous class is a local class that has no name.
Why Use Nested Classes?
There are several compelling reasons for using nested classes, among them:
Logical grouping of classes—If a class is useful to only one other class, then it is logical to embed it in that class and keep the two together. Nesting such "helper classes" makes their package more streamlined.
Increased encapsulation—Consider two top-level classes, A and B, where B needs access to members of A that would otherwise be declared private. By hiding class B within class A, A's members can be declared private and B can access them. In addition, B itself can be hidden from the outside world.
More readable, maintainable code—Nesting small classes within top-level classes places the code closer to where it is used.
Monday, December 22, 2008
JAVA and Internet
Hi All...
in this age of Internet, java and Internet are very closely related.java made web interactive. now a days lot of web applications are made in java/j2ee.java is very much secure that's the main reason behind the usage of java in web.J2EE provides lot of APIs to make highly secure enterprise application.
in this age of Internet, java and Internet are very closely related.java made web interactive. now a days lot of web applications are made in java/j2ee.java is very much secure that's the main reason behind the usage of java in web.J2EE provides lot of APIs to make highly secure enterprise application.
Sunday, December 21, 2008
Garbage Collection in java
One of the ideas behind Java's automatic memory management model is that programmers be spared the burden of having to perform manual memory management. In some languages like C,C++, the programmer allocates memory for the creation of objects stored on the heap and the responsibility of later deallocating that memory also resides with the programmer. If the programmer forgets to deallocate memory or writes code that fails to do so, a memory leak occurs and the program can consume an arbitrarily large amount of memory. Additionally, if the program attempts to deallocate the region of memory more than once, the result is undefined and the program may become unstable and may crash. Finally, in non garbage collected environments, there is a certain degree of overhead and complexity of user-code to track and finalize allocations. Often developers may box themselves into certain designs to provide reasonable assurances that memory leaks will not occur.
In Java, this potential problem is avoided by automatic garbage collection. The programmer determines when objects are created, and the Java runtime is responsible for managing the object's lifecycle. The program or other objects can reference an object by holding a reference to it (which, from a low-level point of view, is its address on the heap). When no references to an object remain, the Java garbage collector automatically deletes the unreachable object, freeing memory and preventing a memory leak. Memory leaks may still occur if a programmer's code holds a reference to an object that is no longer needed—in other words, they can still occur but at higher conceptual levels.
The use of garbage collection in a language can also affect programming paradigms. If, for example, the developer assumes that the cost of memory allocation/recollection is low, they may choose to more freely construct objects instead of pre-initializing, holding and reusing them. With the small cost of potential performance penalties (inner-loop construction of large/complex objects), this facilitates thread-isolation (no need to synchronize as different threads work on different object instances) and data-hiding. The use of transient immutable value-objects minimizes side-effect programming.
In Java, this potential problem is avoided by automatic garbage collection. The programmer determines when objects are created, and the Java runtime is responsible for managing the object's lifecycle. The program or other objects can reference an object by holding a reference to it (which, from a low-level point of view, is its address on the heap). When no references to an object remain, the Java garbage collector automatically deletes the unreachable object, freeing memory and preventing a memory leak. Memory leaks may still occur if a programmer's code holds a reference to an object that is no longer needed—in other words, they can still occur but at higher conceptual levels.
The use of garbage collection in a language can also affect programming paradigms. If, for example, the developer assumes that the cost of memory allocation/recollection is low, they may choose to more freely construct objects instead of pre-initializing, holding and reusing them. With the small cost of potential performance penalties (inner-loop construction of large/complex objects), this facilitates thread-isolation (no need to synchronize as different threads work on different object instances) and data-hiding. The use of transient immutable value-objects minimizes side-effect programming.
Tuesday, December 2, 2008
Java Database connectivity and it's Drivers
Why should you consider Java Database Connectivity (JDBC) drivers apart from the JDBC-ODBC Bridge? What level of JDBC driver is suited for your application? What parameters should you use for evaluating a JDBC driver? This article evaluates various JDBC drivers and answers these questions.
While writing JDBC applications, developers generally start with JDBC-ODBCBridge to connect to databases. But when an application reaches some advanced stage, for example, when it needs to support multithreading, the JDBC-ODBCBridge poses a few problems. So, the need arises for a robust JDBC driver. In that case, the type of driver depends on quite a few parameters: whether the application is Internet or intranet based, whether it needs to support heterogeneous databases, the number of concurrent users, and so on.
JDBC driver types
JDBC drivers are divided into four types or levels. Each type defines a JDBC driver implementation with increasingly higher levels of platform independence, performance, and deployment administration. The four types are:
Type 1: JDBC-ODBC Bridge
Type 2: Native-API/partly Java driver
Type 3: Net-protocol/all-Java driver
Type 4: Native-protocol/all-Java driver
Type 1: JDBC-ODBC Bridge
The type 1 driver, JDBC-ODBC Bridge, translates all JDBC calls into ODBC (Open DataBase Connectivity) calls and sends them to the ODBC driver. As such, the ODBC driver, as well as, in many cases, the client database code, must be present on the client machine.
Pros
The JDBC-ODBC Bridge allows access to almost any database, since the database's ODBC drivers are already available. Type 1 drivers may be useful for those companies that have an ODBC driver already installed on client machines.
Cons
The performance is degraded since the JDBC call goes through the bridge to the ODBC driver, then to the native database connectivity interface. The result comes back through the reverse process. Considering the performance issue, type 1 drivers may not be suitable for large-scale applications.
The ODBC driver and native connectivity interface must already be installed on the client machine. Thus any advantage of using Java applets in an intranet environment is lost, since the deployment problems of traditional applications remain.
Type 2: Native-API/partly Java driver
JDBC driver type 2 -- the native-API/partly Java driver -- converts JDBC calls into database-specific calls for databases such as SQL Server, Informix, Oracle, or Sybase. The type 2 driver communicates directly with the database server; therefore it requires that some binary code be present on the client machine.
Pros
Type 2 drivers typically offer significantly better performance than the JDBC-ODBC Bridge.
Cons
The vendor database library needs to be loaded on each client machine. Consequently, type 2 drivers cannot be used for the Internet. Type 2 drivers show lower performance than type 3 and type 4 drivers.
Type 3: Net-protocol/all-Java driver
JDBC driver type 3 -- the net-protocol/all-Java driver -- follows a three-tiered approach whereby the JDBC database requests are passed through the network to the middle-tier server. The middle-tier server then translates the request (directly or indirectly) to the database-specific native-connectivity interface to further the request to the database server. If the middle-tier server is written in Java, it can use a type 1 or type 2 JDBC driver to do this.
Pros
The net-protocol/all-Java driver is server-based, so there is no need for any vendor database library to be present on client machines. Further, there are many opportunities to optimize portability, performance, and scalability. Moreover, the net protocol can be designed to make the client JDBC driver very small and fast to load. Additionally, a type 3 driver typically provides support for features such as caching (connections, query results, and so on), load balancing, and advanced system administration such as logging and auditing.
Cons
Type 3 drivers require database-specific coding to be done in the middle tier. Additionally, traversing the recordset may take longer, since the data comes through the backend server.
Type 4: Native-protocol/all-Java driver
The native-protocol/all-Java driver (JDBC driver type 4) converts JDBC calls into the vendor-specific database management system (DBMS) protocol so that client applications can communicate directly with the database server. Level 4 drivers are completely implemented in Java to achieve platform independence and eliminate deployment administration issues.
Pros
Since type 4 JDBC drivers don't have to translate database requests to ODBC or a native connectivity interface or to pass the request on to another server, performance is typically quite good. Moreover, the native-protocol/all-Java driver boasts better performance than types 1 and 2. Also, there's no need to install special software on the client or server. Further, these drivers can be downloaded dynamically.
Cons
With type 4 drivers, the user needs a different driver for each database.
Performance evaluation of five specific JDBC drivers
To evaluate the performance of five industry-standard drivers based on parameters such as average connection time, data retrieval time, and record insertion time, I created a sample database in SQL Server 7.0. I picked industry-standard JDBC drivers representing various driver types. Note: I didn't test any type 2 drivers because they are not readily available in the market, and I wanted to stick with pure-Java drivers for this article.
While writing JDBC applications, developers generally start with JDBC-ODBCBridge to connect to databases. But when an application reaches some advanced stage, for example, when it needs to support multithreading, the JDBC-ODBCBridge poses a few problems. So, the need arises for a robust JDBC driver. In that case, the type of driver depends on quite a few parameters: whether the application is Internet or intranet based, whether it needs to support heterogeneous databases, the number of concurrent users, and so on.
JDBC driver types
JDBC drivers are divided into four types or levels. Each type defines a JDBC driver implementation with increasingly higher levels of platform independence, performance, and deployment administration. The four types are:
Type 1: JDBC-ODBC Bridge
Type 2: Native-API/partly Java driver
Type 3: Net-protocol/all-Java driver
Type 4: Native-protocol/all-Java driver
Type 1: JDBC-ODBC Bridge
The type 1 driver, JDBC-ODBC Bridge, translates all JDBC calls into ODBC (Open DataBase Connectivity) calls and sends them to the ODBC driver. As such, the ODBC driver, as well as, in many cases, the client database code, must be present on the client machine.
Pros
The JDBC-ODBC Bridge allows access to almost any database, since the database's ODBC drivers are already available. Type 1 drivers may be useful for those companies that have an ODBC driver already installed on client machines.
Cons
The performance is degraded since the JDBC call goes through the bridge to the ODBC driver, then to the native database connectivity interface. The result comes back through the reverse process. Considering the performance issue, type 1 drivers may not be suitable for large-scale applications.
The ODBC driver and native connectivity interface must already be installed on the client machine. Thus any advantage of using Java applets in an intranet environment is lost, since the deployment problems of traditional applications remain.
Type 2: Native-API/partly Java driver
JDBC driver type 2 -- the native-API/partly Java driver -- converts JDBC calls into database-specific calls for databases such as SQL Server, Informix, Oracle, or Sybase. The type 2 driver communicates directly with the database server; therefore it requires that some binary code be present on the client machine.
Pros
Type 2 drivers typically offer significantly better performance than the JDBC-ODBC Bridge.
Cons
The vendor database library needs to be loaded on each client machine. Consequently, type 2 drivers cannot be used for the Internet. Type 2 drivers show lower performance than type 3 and type 4 drivers.
Type 3: Net-protocol/all-Java driver
JDBC driver type 3 -- the net-protocol/all-Java driver -- follows a three-tiered approach whereby the JDBC database requests are passed through the network to the middle-tier server. The middle-tier server then translates the request (directly or indirectly) to the database-specific native-connectivity interface to further the request to the database server. If the middle-tier server is written in Java, it can use a type 1 or type 2 JDBC driver to do this.
Pros
The net-protocol/all-Java driver is server-based, so there is no need for any vendor database library to be present on client machines. Further, there are many opportunities to optimize portability, performance, and scalability. Moreover, the net protocol can be designed to make the client JDBC driver very small and fast to load. Additionally, a type 3 driver typically provides support for features such as caching (connections, query results, and so on), load balancing, and advanced system administration such as logging and auditing.
Cons
Type 3 drivers require database-specific coding to be done in the middle tier. Additionally, traversing the recordset may take longer, since the data comes through the backend server.
Type 4: Native-protocol/all-Java driver
The native-protocol/all-Java driver (JDBC driver type 4) converts JDBC calls into the vendor-specific database management system (DBMS) protocol so that client applications can communicate directly with the database server. Level 4 drivers are completely implemented in Java to achieve platform independence and eliminate deployment administration issues.
Pros
Since type 4 JDBC drivers don't have to translate database requests to ODBC or a native connectivity interface or to pass the request on to another server, performance is typically quite good. Moreover, the native-protocol/all-Java driver boasts better performance than types 1 and 2. Also, there's no need to install special software on the client or server. Further, these drivers can be downloaded dynamically.
Cons
With type 4 drivers, the user needs a different driver for each database.
Performance evaluation of five specific JDBC drivers
To evaluate the performance of five industry-standard drivers based on parameters such as average connection time, data retrieval time, and record insertion time, I created a sample database in SQL Server 7.0. I picked industry-standard JDBC drivers representing various driver types. Note: I didn't test any type 2 drivers because they are not readily available in the market, and I wanted to stick with pure-Java drivers for this article.
Subscribe to:
Posts (Atom)
