'final' is used for defining constants. Constants always have pre-determined specific values. No point in having a constant with a default value which you do not know unless you open language manuals. So we agree that a final variable(so to say) must be explicitly initialized.
This is in contrast with non-final member variables where explicit initialization is not required. Don't forget that a variable must be initialized before use. Non final member variables are by default initialized. Local varibales are not default-initialized.
So we have to find a way to ensure that our final varibales are always explicitly initialized before use.
Instance final variables -
This can be done in constructors, instance blocks or inline. This ensures that the variable always initailized before use.
Class final variables -
These are not owned by instances. So there is no way you can ensure that these are initialized before use except it initializing it inline or thru static block.
Local final variables -
Only one way, assign a value before use. Not very different from non-final local variables except that the former is a constant.
3/19/2005
What is J2EE
J2EE defines standards for developing, building and deploying multitiered enterprise applications. The runtime environment of J2EE applications are provided by Containers which is typically a part of the J2EE server where the application is deployed. J2EE also defines what services the container must support for the application to make use of. J2EE is thus a specification for both container and the application.
The runtime environment provided by containers includes JRE for the J2SE that the J2EE container/server supports.
The J2EE specification describes a minimum set of facilities that all J2EE products (servers) must provide. Most J2EE products will provide facilities beyond the minimum required by this specification. This specification includes only a few limits to the ability of a product to provide extensions. In particular, it includes the same restrictions as J2SE on extensions to Java APIs. A J2EE product may not add classes to the Java programming language packages included in this specification, and may not add methods or otherwise alter the signatures of the specified classes.
However, many other extensions are allowed. A J2EE product may provide additional Java APIs, either other Java optional packages or other (appropriately named) packages. A J2EE product may include support for additional protocols or services not specified here. A J2EE product may support applications written in other languages, or may support connectivity to other platforms or applications. In short, if the application doesn't depend on extensions provided by a J2EE server, it would be deployable (as per specification) in any other J2EE compliant server. On the other hand, J2EE servers must pass the Compatibility Test Suite to be labelled J2EE compliant.
The J2EE API specifications define the contract between the J2EE application components and the J2EE platform. The contract specifies both the runtime and deployment interfaces.
The J2EE Service Provider Interfaces (SPIs) API specifications define the contract between the J2EE platform and service providers that may be plugged into a J2EE product. The Connector APIs define service provider interfaces for integrating resource adapters with a J2EE application server. Resource adapter components implementing the Connector APIs are called Connectors. The J2EE Authorization APIs define service provider interfaces for integrating security authorization mechanisms with a J2EE application server.
Standards services that J2EE mandates are
JNDI, Java Mail, Deployment, JAAS-JACC (security), Management, Corba, JTA, JMS, EJB, Servlets/JSP, WebServices, JCA
J2EE 1.4 includes JAX-RPC, SAAJ, JAXR (supports web services) and JMX as J2EE management API and JACC SPI.
J2EE 1.3 included JCA, JMS, JAXP, JAAS and IIOP for EJBs (2.0) and Local Interfaces.
The runtime environment provided by containers includes JRE for the J2SE that the J2EE container/server supports.
The J2EE specification describes a minimum set of facilities that all J2EE products (servers) must provide. Most J2EE products will provide facilities beyond the minimum required by this specification. This specification includes only a few limits to the ability of a product to provide extensions. In particular, it includes the same restrictions as J2SE on extensions to Java APIs. A J2EE product may not add classes to the Java programming language packages included in this specification, and may not add methods or otherwise alter the signatures of the specified classes.
However, many other extensions are allowed. A J2EE product may provide additional Java APIs, either other Java optional packages or other (appropriately named) packages. A J2EE product may include support for additional protocols or services not specified here. A J2EE product may support applications written in other languages, or may support connectivity to other platforms or applications. In short, if the application doesn't depend on extensions provided by a J2EE server, it would be deployable (as per specification) in any other J2EE compliant server. On the other hand, J2EE servers must pass the Compatibility Test Suite to be labelled J2EE compliant.
The J2EE API specifications define the contract between the J2EE application components and the J2EE platform. The contract specifies both the runtime and deployment interfaces.
The J2EE Service Provider Interfaces (SPIs) API specifications define the contract between the J2EE platform and service providers that may be plugged into a J2EE product. The Connector APIs define service provider interfaces for integrating resource adapters with a J2EE application server. Resource adapter components implementing the Connector APIs are called Connectors. The J2EE Authorization APIs define service provider interfaces for integrating security authorization mechanisms with a J2EE application server.
Standards services that J2EE mandates are
JNDI, Java Mail, Deployment, JAAS-JACC (security), Management, Corba, JTA, JMS, EJB, Servlets/JSP, WebServices, JCA
J2EE 1.4 includes JAX-RPC, SAAJ, JAXR (supports web services) and JMX as J2EE management API and JACC SPI.
J2EE 1.3 included JCA, JMS, JAXP, JAAS and IIOP for EJBs (2.0) and Local Interfaces.
What is J2SE
Java 2 Platform, Standard Edition (J2SE) platform for applications development on desktops and servers. It also serves as the foundation for J2EE and JWS.
J2SE consists of the J2SE class library, JVM (platform specific byte code interpretor), and other development tools and APIs (which are shipped with JDK).
The J2SE application programming interface (API) defines the prescribed manner by which an applet or application can make requests to and use the functionality available in the compiled J2SE class libraries
The JRE provides the Java APIs, Java virtual machine, and other components necessary to run applets and applications written in the Java programming language. And this JRE is also the foundation of the J2EE runtime environment.
JDK = JRE + Development tools
J2SE consists of the J2SE class library, JVM (platform specific byte code interpretor), and other development tools and APIs (which are shipped with JDK).
The J2SE application programming interface (API) defines the prescribed manner by which an applet or application can make requests to and use the functionality available in the compiled J2SE class libraries
The JRE provides the Java APIs, Java virtual machine, and other components necessary to run applets and applications written in the Java programming language. And this JRE is also the foundation of the J2EE runtime environment.
JDK = JRE + Development tools
Subscribe to:
Posts (Atom)