|
Java Interview Questions and Answers
What is a marker interface ?
An interface that contains no methods. E.g.: Serializable, Cloneable,
SingleThreadModel etc. It is used to just mark java classes that support
certain capability. What are tag interfaces?
Tag interface is an alternate name for marker interface.
What are the restrictions placed on static method ?
We cannot override static methods. We cannot access any object variables
inside static method. Also the this reference also not available in
static methods.
What is JVM?
JVM stands for Java Virtual Machine. It is the run time for java
programs. All are java programs are running inside this JVM only. It
converts java byte code to OS specific commands. In addition to
governing the execution of an application's byte codes, the virtual
machine handles related tasks such as managing the system's memory,
providing security against malicious code, and managing multiple threads
of program execution.
What is JIT?
JIT stands for Just In Time compiler. It compiles java byte code to
native code. What are ClassLoaders?
A class loader is an object that is responsible for loading classes. The
class ClassLoader is an abstract class. Given the name of a class, a
class loader should attempt to locate or generate data that constitutes
a definition for the class. A typical strategy is to transform the name
into a file name and then read a "class file" of that name from a file
system.
Every Class object contains a reference to the ClassLoader that defined
it.
Class objects for array classes are not created by class loaders, but
are created automatically as required by the Java runtime. The class
loader for an array class, as returned by Class.getClassLoader() is the
same as the class loader for its element type; if the element type is a
primitive type, then the array class has no class loader.
Applications implement subclasses of ClassLoader in order to extend the
manner in which the Java virtual machine dynamically loads classes.
What is Service Locator pattern?
The Service Locator pattern locates J2EE (Java 2 Platform, Enterprise
Edition) services for clients and thus abstracts the complexity of
network operation and J2EE service lookup as EJB (Enterprise JavaBean)
Interview Questions - Home and JMS (Java Message Service) component factories. The Service
Locator hides the lookup process's implementation details and complexity
from clients. To improve application performance, Service Locator caches
service objects to eliminate unnecessary JNDI (Java Naming and Directory
Interface) activity that occurs in a lookup operation.
What is Session Facade pattern?
Session facade is one design pattern that is often used while developing
enterprise applications. It is implemented as a higher level component
(i.e.: Session EJB), and it contains all the iteractions between low
level components (i.e.: Entity EJB). It then provides a single interface
for the functionality of an application or part of it, and it decouples
lower level components simplifying the design. Think of a bank
situation, where you have someone that would like to transfer money from
one account to another. In this type of scenario, the client has to
check that the user is authorized, get the status of the two accounts,
check that there are enough money on the first one, and then call the
transfer. The entire transfer has to be done in a single transaction
otherwise is something goes south, the situation has to be restored.
As you can see, multiple server-side objects need to be accessed and
possibly modified. Multiple fine-grained invocations of Entity (or even
Session) Beans add the overhead of network calls, even multiple
transaction. In other words, the risk is to have a solution that has a
high network overhead, high coupling, poor reusability and
mantainability.
The best solution is then to wrap all the calls inside a Session Bean,
so the clients will have a single point to access (that is the session
bean) that will take care of handling all the rest.
What is Data Access Object pattern?
The Data Access Object (or DAO) pattern: separates a data resource's
client interface from its data access mechanisms adapts a specific data
resource's access API to a generic client interface
The DAO pattern allows data access mechanisms to change independently of
the code that uses the data.
The DAO implements the access mechanism required to work with the data
source. The data source could be a persistent store like an RDBMS, an
external service like a B2B exchange, a repository like an LDAP
database, or a business service accessed via CORBA Internet Inter-ORB
Protocol (IIOP) or low-level sockets. The business component that relies
on the DAO uses the simpler interface exposed by the DAO for its
clients. The DAO completely hides the data source implementation details
from its clients. Because the interface exposed by the DAO to clients
does not change when the underlying data source implementation changes,
this pattern allows the DAO to adapt to different storage schemes
without affecting its clients or business components. Essentially, the
DAO acts as an adapter between the component and the data source.
Can we make an EJB singleton?
This is a debatable question, and for every answer we propose there can
be contradictions. I propose 2 solutions of the same. Remember that
EJB's are distributed components and can be deployed on different JVM's
in a Distributed environment
i) Follow the steps as given below
Make sure that your serviceLocator is deployed on only one JVM.
In the serviceLocator create a HashTable/HashMap(You are the right judge
to choose between these two)
When ever a request comes for an EJB to a serviceLocator, it first
checks in the HashTable if an entry already exists in the table with key
being the JNDI name of EJB. If key is present and value is not null,
return the existing reference, else lookup the EJB in JNDI as we do
normally and add an entry into the Hashtable before returning it to the
client. This makes sure that you maintain a singleton of EJB.
ii) In distributed environment our components/Java Objects would be
running on different JVM's. So the normal singleton code we write for
maintaining single instance works fine for single JVM, but when the
class could be loaded in multiple JVM's and Instantiated in multiple
JVM's normal singleton code does not work. This is because the
ClassLoaders being used in the different JVM's are different from each
other and there is no defined mechanism to check and compare what is
loaded in another JVM. A solution could be(Not tested yet. Need your
feedback on this) to write our own ClassLoader and pass this classLoader
as argument, whenever we are creating a new Instance and make sure that
only one instance is created for the proposed class. This can be done
easily.
Page Numbers :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
Have a Question ?
post your questions here. It
will be answered as soon as possible.
Check
Structs Interview
Questions for more Structs Interview Questions with answers
|
