Mix topics - AOP, Ajax & WebServices

Q1. What is AOP i.e. aspect oriented programming and what is the need for same?

Ans. AOP is a new technology for separating crosscutting concerns into single units called aspects. It encapsulates behaviours that affect multiple classes into reusable modules. It entails breaking down program logic into distinct parts known as crosscutting concerns that are usually hard to do in object-oriented programming. These units/concerns are termed aspects; hence the name aspect oriented programming.

For ex: Logging. It crosscuts all logged classes and methods. Suppose we do logging at both the beginning and the end of each function body. This will result in crosscutting all classes that have at least one function. Other typical crosscutting concerns include context-sensitive error handling, performance optimization, and design patterns.

With AOP, we start by implementing our project using our OO language (for example, Java), and then we deal separately with crosscutting concerns in our code by implementing aspects. Finally, both the code and aspects are combined into a final executable form using an aspect weaver.

Above figure explains the weaving process. You should note that the original code doesn't need to know about any functionality the aspect has added; it needs only to be recompiled without the aspect to regain the original functionality. In that way, AOP complements object-oriented programming and doesn't replace it.

Q2. What are the differences between OOP and AOP?
Ans:

OOP	AOP
OOP looks at an application as a set of collaborating objects. OOP code scatters system level code like logging, security etc with the business logic code.	AOP looks at the complex software system as combined implementation of multiple concerns like business logic, data persistence,   logging, security, and so on. Separates business logic code from the system level code. In fact one concern remains unaware of other concerns.
OOP nomenclature has classes, objects, interfaces etc.	AOP nomenclature has join points, point cuts, advice, and aspects.
Provides benefits such as code reuse, flexibility, improved maintainability, modular architecture, reduced development time etc with the help of polymorphism, inheritance and encapsulation.	AOP implementation coexists with the OOP by choosing OOP as the base language. Ex: AspectJ uses Java as the base language. AOP provides benefits provided by OOP plus some additional benefits.

Q3. How many different types of JDBC drivers are present? Discuss them.
Ans. There are four JDBC driver types. 

Type 1: JDBC-ODBC Bridge plus ODBC Driver: The first type of JDBC driver is the JDBC-ODBC Bridge. It is a driver that provides JDBC access to databases through ODBC drivers. The ODBC driver must be configured on the client for the bridge to work. This driver type is commonly used for prototyping or when there is no JDBC driver available for a particular DBMS.

Type 2: Native-API partly-Java Driver: The Native to API driver converts JDBC commands to DBMS-specific native calls. This is much like the restriction of Type 1 drivers. The client must have some binary code loaded on its machine. These drivers do have an advantage over Type 1 drivers because they interface directly with the database.

Type 3: JDBC-Net Pure Java Driver: The JDBC-Net drivers are a three-tier solution. This type of driver translates JDBC calls into a database-independent network protocol that is sent to a middleware server. This server then translates this DBMS-independent protocol into a DBMS-specific protocol, which is sent to a particular database. The results are then routed back through the middleware server and sent back to the client. This type of solution makes it possible to implement a pure Java client. It also makes it possible to swap databases without affecting the client.

Type 4: Native-Protocol Pure Java Driver: These are pure Java drivers that communicate directly with the vendor’s database. They do this by converting JDBC commands directly into the database engine’s native protocol. This driver has no additional translation or middleware layer, which improves performance tremendously. 

Q4. What is Ajax.
Ans: There is a lot of hype surrounding the latest Web development Ajax (Asynchronous JavaScript And XML). The intent of Ajax is to make Web pages more responsive and interactive by exchanging small amounts of data with the server behind the scenes without refreshing the page, so that the entire Web page does not have to be reloaded each time the user makes a change. Ajax technique uses a combination of JavaScript, XHTML (or HTML) and XMLHttp.

Q5. Web services
Ans. Web service is an implementation technology and one of the ways to implement SOA (Service Oriented Architecture). You can build SOA based applications without using Web services – for example by using other traditional technologies like Java RMI, EJB, JMS based messaging, etc. But what Web services offer is the standards based and platform independent service via HTTP, XML, SOAP, WSDL and UDDI, thus allowing interoperability between heterogeneous technologies such as J2EE and .NET. 

Web services are language and platform independent. Web service uses language neutral protocols such as HTTP and communicates between disparate applications by passing XML messages to each other via a Web API (Messages must be in XML and binary data attachments). Interfaces must be based on Internet protocols such as HTTP, FTP and SMTP. There are two main styles of Web services: SOAP and REST.

A service is an application that exposes its functionality through an API (Application Programming Interface). A service is a component that can be used remotely through a remote interface either synchronously or asynchronously. The term service also implies something special about the application design, which is called a service-oriented architecture (SOA). One of the most important features of SOA is the separation of interface from implementation. A service exposes its functionality through interface and interface hides the inner workings of the implementation.

For ex: Google also provides a Web service interface through the Google API to query their search engine from an application rather than a browser. 

Q6. SOAP
Ans: SOAP stands for Simple Object Access Protocol. It is an XML based lightweight protocol, which allows software components and application components to communicate, mostly using HTTP (can use SMTP etc). SOAP sits on top of the HTTP protocol. SOAP is nothing but XML message based document with pre-defined format. SOAP is designed to communicate via the Internet in a platform and language neutral manner and allows you to get around firewalls as well. Let’s look at thr structure of a SOAP message:

• A SOAP message MUST be encoded using XML
• A SOAP message MUST use the SOAP Envelope namespace
• A SOAP message MUST use the SOAP Encoding namespace
• A SOAP message must NOT contain a DTD reference
• A SOAP message must NOT contain XML Processing Instructions

Q7. WSDL
Ans: WSDL stands for Web Services Description Language. A WSDL document is an XML document that describes how the messages are exchanged. Let’s say we have created a Web service. Who is going to use that and how does the client know which method to invoke and what parameters to pass? There are tools that can generate WSDL from the Web service. Also there are tools that can read a WSDL document and create the necessary code to invoke the Web service. So the WSDL is the Interface Definition Language (IDL) for Web services. 

Q8. UDDI
Ans: UDDI stands for Universal Description Discovery and Integration. UDDI provides a way to publish and discover information about Web services. UDDI is like a registry rather than a repository. A registry contains only reference information like JNDI etc.

So far we have looked at some open standards/protocols relating to Web services, which enable interoperability between disparate systems (e.g. Between .Net and J2EE etc). These standards provide a common and interoperable approach for defining (WSDL), publishing (UDDI) and using (SOAP) Web services. 

Q9. SAX Vs DOM Parser
Ans. Main differences between SAX (Simple API for XML) and DOM (Document Object Model), which are the two most popular APIs for processing XML documents in Java, are:-

• Read v/s Read/Write: SAX can be used only for reading XML documents and not for the manipulation of the underlying XML data whereas DOM can be used for both read and write of the data in an XML document.
• Sequential Access v/s Random Access: SAX can be used only for a sequential processing of an XML document whereas DOM can be used for a random processing of XML docs. So what to do if you want a random access to the underlying XML data while using SAX? You got to store and manage that information so that you can retrieve it when you need.
• Call back v/s Tree: SAX uses call back mechanism and uses event-streams to read chunks of XML data into the memory in a sequential manner. A SAX parser does not create any internal structure. Instead, it takes the occurrences of components of an input document as events (i.e., event driven), and tells the client what it reads as it reads through the input document, whereas a DOM parser creates a tree structure in memory from an input document and then waits for requests from client and facilitates random access/manipulation of the underlying XML data.
• API: From functionality point of view, SAX provides a fewer functions which means that the users themselves have to take care of more, such as creating their own data structures. A DOM parser is rich in functionality. It creates a DOM tree in memory and allows you to access any part of the document repeatedly and allows you to modify the DOM tree. 
• XML-Dev mailing list v/s W3C: SAX was developed by the XML-Dev mailing list whereas DOM was developed by W3C (World Wide Web Consortium).
• Information Set: SAX doesn't retain all the info of the underlying XML document such as comments whereas DOM retains almost all the info. New versions of SAX are trying to extend their coverage of information.

Usual Misconceptions

SAX is always faster: this is a very common misunderstanding and one should be aware that SAX may not always be faster because it might not enjoy the storage-size advantage in every case due to the cost of call backs depending upon the particular situation, SAX is being used in.

DOM always keeps the whole XML doc in memory: it's not always true. DOM implementations not only vary in their code size and performance, but also in their memory requirements and few of them don't keep the entire XML doc in memory all the time. Otherwise, processing/manipulation of very large XML docs may virtually become impossible using DOM, which is of course not the case.

Q10. How to choose one between SAX & DOM?
Ans. It primarily depends upon the requirement. If the underlying XML data requires manipulation then almost always DOM will be used as SAX doesn't allow that. Similarly if the nature of access is random (for example, if you need contextual info at every stage) then DOM will be the way to go in most of the cases. But, if the XML document is only required to be read and that too sequentially, then SAX will probably be a better alternative in most of the cases. SAX was developed mainly for pasring XML documents and it's certainly good at it. Use DOM when your application has to access various parts of the document and using your own structure is just as complicated as the DOM tree. If your application has to change the tree very frequently and data has to be stored for a significant amount of time.

Q11. What is a socket? How do you facilitate inter process communication in Java?
Ans: A socket is a communication channel, which facilitates inter-process communication (ex: communicating between two JVMs). A socket is an endpoint for communication. There are two kinds of sockets, depending on whether one wishes to use a connectionless or a connection-oriented protocol. 
1. The connectionless communication protocol of the Internet is called UDP
2. The connection-oriented communication protocol of the Internet is called TCP. 

UDP sockets are also called datagram sockets. Each socket is uniquely identified on the entire Internet with two numbers. First number is a 32-bit (IPV4 or 128-bit is IPV6) integer called the IP address is the location of the machine, which you are trying to connect to. Second number is a 16-bit integer called the port of the socket, port on which the server you are trying to connect is running. The port numbers 0 to 1023 are reserved for standard services such as e-mail, FTP, HTTP etc.

Q12. Memory map file.
Ans. Memory-mapping a file uses the OS virtual memory to access the data on the file system directly, instead of using normal I/O functions. Most modern OS that support virtual memory also run each process in its own dedicated address space, allowing a program to be designed as though it has sole access to the virtual memory. Use mmap to make a connection between your address space and the file on the disk. Memory mapped files are loaded into memory one entire page at a time. The page size is selected by the operating system for maximum performance.While memory mapped files offer a way to read and write directly to a file at specific locations, the actual action of reading/writing to the disk is handled at a lower level. Consequently, data is not actually transferred at the time the above instructions are executed. Instead, much of the file input/output (I/O) is cached to improve general system performance. You can override this behavior and force the system to perform disk transactions immediately by using the memory-mapped file function FlushViewOfFile.

Note: jmap prints shared object memory maps or heap memory details of a given process or core file or a remote debug server.

Benefits:

1. Increased I/O Performance: Especially when used on large files. For small files, memory-mapped files can result in a waste of slack space as memory maps are always aligned to the page size, which is mostly 4 KB. Therefore a 5 KB file will allocate 8 KB and thus 3 KB are wasted. Accessing memory mapped files is faster for two reasons. Firstly, it does not involve a separate system call for each access. Secondly, in most OS the memory region mapped actually is the kernel's page cache (file cache), meaning that no copies need to be created in user space. It does not require copying data between buffers – the memory is accessed directly.
2. Faster read/write operations: Applications can access and update data in the file directly and in-place, as opposed to seeking from the start of the file or rewriting the entire edited contents to a temporary location. Since the memory-mapped file is handled internally in pages, linear file access requires disk access only when a new page boundary is crossed, and can write larger sections of the file to disk in a single operation.
3. Lazy Loading: It uses small amounts of RAM even for a very large file. Trying to load the entire contents of a file that is significantly larger than the amount of memory available can cause severe thrashing.

Drawbacks:

1. The memory mapped approach has its cost in minor page faults - when a block of data is loaded in page cache, but is not yet mapped into the process's virtual memory space. In some circumstances, memory mapped file I/O can be substantially slower than standard file I/O.
2. Another drawback relates to a given architecture's address space - a file larger than the addressable space can have only portions mapped at a time, complicating reading it. For ex: a 32-bit architecture such as Intel's IA-32 can only directly address 4 GB or smaller portions of files.

Common uses

1. Most common use is the process loader in most modern OS (including Windows & Unix). When a process is started, OS uses a memory mapped file to bring the executable file, along with any loadable modules, into memory for execution. 
2. Another common use is to share memory between multiple processes. In modern OS, processes are generally not permitted to access memory space that is allocated for use by another process. There are a number of techniques available to safely share memory, and memory-mapped file I/O is one of the most popular. Two or more applications can simultaneously map a single physical file into memory and access this memory.

Platform support

Most modern OS or runtime environments support some form of memory mapped file access. The function mmap(), which creates a mapping of a file given a file descriptor, starting location in the file, and a length, is part of the POSIX specification. So, POSIX-compliant systems, such as Unix, Linux, Mac OS etc. support a common mechanism for memory mapping files. The mmap() function establishes a mapping between a process' address space and a stream file.
The Microsoft Windows operating systems also support a group of API functions for this purpose, such as CreateFileMapping(). Java provides classes and methods to access memory mapped files, such as FileChannel.

Q13. MemoryMapFile Usage example.
Ans. We used the FileChannel class along with the ByteBuffer class to perform memory-mapped IO for data of type byte. These byte is then retrieved by using get() method of ByteBuffer class.
FileChannel: An abstract class used for reading, writing, mapping, and manipulating a file.
ByteBuffer: An abstract class which provides methods for reading and writing values of all primitive types except Boolean.
map() method: This method maps the region of the channel's file directly into memory.
size() method: This method returns the current size of this channel's file.

Usage Modes:
FileChannel.MapMode.PRIVATE: Mode for a private (copy-on-write) mapping.
FileChannel.MapMode.READ_ONLY: Mode for a read-only mapping.
FileChannel.MapMode.READ_WRITE: Mode for a read/write mapping.

Usage example:
File file = new File("filename");

// Create a read-only memory-mapped file
FileChannel roChannel = new RandomAccessFile(file, "r").getChannel();
ByteBuffer roBuf = roChannel.map(FileChannel.MapMode.READ_ONLY, 0,  (int)roChannel.size());

// Create a read-write memory-mapped file
FileChannel rwChannel = new RandomAccessFile(file, "rw").getChannel();
ByteBuffer wrBuf = rwChannel.map(FileChannel.MapMode.READ_WRITE,0,(int)rwChannel.size());

// Create a private (copy-on-write) memory-mapped file.
// Any write to this channel results in a private copy of the data.
FileChannel pvChannel = new RandomAccessFile(file, "rw").getChannel();
ByteBuffer pvBuf = roChannel.map(FileChannel.MapMode.READ_WRITE,0,(int)rwChannel.size());
Although the return value from map() is assigned to a ByteBuffer variable, it's actually a MappedByteBuffer. Most of the time there's no reason to differentiate, but the latter class has two methods that some programs may find useful - load() and force().
The load() method will attempt to load all of the file's data into RAM, trading an increase in startup time for a potential decrease in page faults later. This is a form of premature optimization. Unless your program constantly accesses those pages, OS may choose to use them for something else, meaning that you'll have to fault them in. To flush dirty pages to disk, call the buffer's force() method.

buf.putInt(0, 0x87654321);
buf.force();Above two lines of code are actually an anti-pattern: you don't want to flush dirty pages after every write. Take a lesson from database developers, and group your changes into atomic units.

Q14. Mapping Files Bigger than 2 GB
Ans. Depending on your filesystem, you can create files larger than 2GB. But ByteBuffer uses an int for all indexes, which means that buffers are limited to 2GB, which means that you need to create multiple buffers to work with large files.

Sol1: Create those buffers as needed. The same underlying FileChannel can support as many buffers as you can create, limited only by the OS and available virtual memory; simply pass a different starting offset each time. The problem with this approach is that creating a mapping is expensive, because it's a kernel call (and you're using mapped files to avoid kernel calls). In addition, a page table full of mappings will mean more expensive context switches. As a result, as-needed buffers aren't a good approach unless you can divide the file into large chunks that are processed as a unit.

Sol2: Create a “super buffer” that maps the entire file and presents an API that uses long offsets. Internally, it maintains an array of mappings with a known size, so that you can easily translate the original index into a buffer and an offset within that buffer:
public int getInt(long index) {
      return buffer(index).getInt();
}

private ByteBuffer buffer(long index) {
      ByteBuffer buf = _buffers[(int)(index / _segmentSize)];
      buf.position((int)(index % _segmentSize));
      return buf;
}

What's a good value for _segmentSize? Your first thought might be Integer.MAX_VALUE, since this is the maximum index value for a buffer. While that would result in the fewest number of buffers to cover the file, it has one big flaw - you won't be able to access multi-byte values at segment boundaries. Instead, you should overlap buffers, with the size of the overlap being the maximum sub-buffer that you need to access.

NOTE: Buffer will persist after the channel is closed, it's removed by the garbage collector (and this explains the reason that MappedByteBuffer doesn't have its own close() method).

Q15. Garbage Collection of Direct/Mapped Buffers
Ans. How does the non-heap i.e. virtual memory for direct buffers and mapped files get released? After all, there's no method to explicitly close or release them. The answer is that they get garbage collected like any other object, but with one twist: if you don't have enough virtual memory space, that will trigger a full collection even if there's plenty of heap memory available. Normally, this won't be an issue: you probably won't be allocating and releasing direct buffers more often than heap-resident objects. If, however, you see full GC's appearing when you don't think they should, take a look at your program's use of buffers.

Memory management & Garbage collection

Q1. How does Java allocate stack and heap memory?

Ans. Each time an object is created in Java it goes into the area of memory known as heap. The primitive variables like int and double are allocated in the stack (i.e. Last In First Out queue), if they are local variables and in the heap if they are member variables (i.e. fields of a class). In Java methods and local variables are pushed into stack when a method is invoked and stack pointer is decremented when a method call is completed. In a multi-threaded application each thread will have its own stack but will share the same heap. This is why care should be taken in your code to avoid any concurrent access issues in the heap space. The stack is thread-safe because each thread will have its own stack.

Q2. Is there any possible memory leak in Java?

Ans. Memory leak is unused but referenced part of the memory. Though GC takes care of cleaning up your memory/heap, but if you have used some native objects and forgot to reclaim the memory explicitly because that's anyway not going to be taken care by the GC (which takes care of heap memory management only).

Similarly, using 'static' also can be one of the potential reasons for memory leaks in Java. 'static' can't straightway be blamed for causing memory leaks; but if programmer has not taken care of the setting the references to 'null' explicitly after using the static objects then they can definitely cause memory leaks. Since 'static' members will by default live for the entire life of an app unless they are explicitly set to 'null'. So, always make it a point to nullify the references as soon as you reach at a point in your code where the use of the static member is over.

Ex: Suppose you have created a 'Statement' object from a DB Connection and the connection is a pooled one. Now as you know calling close() method on a pooled connection will not actually close the connection instead it will return the Connection object to the pool to be re-used. So, in such a case unless you explicitly close the 'Statement' object, it would keep consuming precious memory space for no real use. Now if you have declared the 'Statement' object as a static member, it'll be maintained in the memory for the entire life time of the app even when the control is out of the scope. Now that if your Statement object is non-static, it will eligible for garbage collection, once it is out-of-scope. However, there is still wastage of memory after using the Statement last and before reaching the end of the local scope.

Therefore, in summary we can say that one should/must :-

• Always think if you really need to make this variable/member a 'static'.
• Always try to confine the scope of an object to restrict its usage only to the section it's actually needed.
• Always make a conscious effort to explicitly nullify objects once you finish using them (especially the large objects) 

Q3. Explain memory management in java.

Ans. In java, memory is managed via garbage collector. Few techniques for memory management are:

1. Reference Counting: A count of references to each object is maintained. When garbage collector runs, it deletes objects with zero reference count. 

Drawback: Circular references are maintained in memory.

2. Tracing collectors/Copy Collector/Stop and copy collector: Start from a root object and keep a track of all references which have direct/indirect reference to the root object. Then all the live objects are moved to another heap, taking care of references properly.

Drawback: At each point of time, you will have 2 heaps thus consuming twice the memory.

3. Mark sweep collectors/Stop and work collector: Similar to tracing collector except that instead of copying the references to the new heap, they are swept out of memory, after a list of live and dead objects is known.

Mark and sweep is a stop-the-world garbage collection technique; that is all application threads stop until garbage collection completes or until a higher-priority thread interrupts the garbage collector. If the garbage collector is interrupted it must restart which can lead to application thrashing with little apparent result.

http://www.ibm.com/developerworks/java/library/j-jtp10283/

Q4. Does Java have destructors?

Ans. Garbage collector does the job working in the background. Java does not have destructors; but it has finalizer that does a similar job. Syntax is 

      public void finalize() { } 

If an object has a finalizer, the method is invoked before the system garbage collects the object.

Q5. Does the finalize method in subclass invoke finalize method in super class?

Ans. Finalize is not implicitly chained. A finalize method in sub-class should call finalize in super class explicitly as its last action for proper functioning. Compilers don’t enforce this check.

Q6. Can finalize method be overloaded?
Ans. Yes but only the following version is called by garbage collector:
           protected void finalize() throws Throwable { };

Q7. Should I override finalize method?
Ans. Unlike C++ destructors, the finalize() method in Java is unpredictable, often dangerous and generally unnecessary. Use try and finally blocks while implementing finalize method. The finalize() method should only be used in rare instances as a safety net or to terminate non-critical native resources. If you do happen to call the finalize() method in some rare instances then remember to call the super.finalize() as shown below:

protected void finalize() throws Throwable {
      try {
            //finalize subclass state
      }

      finally {
            super.finalize();
      }
}

Q8. An object is resurrected by making other object refer to the dying object in finalize method. Will this object be ever garbage collected?

Ans. Resurrection can happen in finalize method which will prevent GC to reclaim the object memory. However this could be done only once. Next time GC will not invoke finalize method before garbage collection.

Well, the problem is that an object which overrides finalize() must now be determined to be garbage in at least two separate garbage collection cycles in order to be collected. When the first cycle determines that it is garbage, it becomes eligible for finalization. Because of the (slim, but unfortunately real) possibility that the object was "resurrected" during finalization, the garbage collector has to run again before the object can actually be removed. And because finalization might not have happened in a timely fashion, an arbitrary number of garbage collection cycles might have happened while the object was waiting for finalization. This can mean serious delays in actually cleaning up garbage objects, and is why you can get OutOfMemoryErrors even when most of the heap is garbage.

Q9. Explain types of references in Java? java.lang.ref package can be used to declare soft, weak and phantom references.

Ans. There are actually four different degrees of reference strength: strong, soft, weak, and phantom, in order from strongest to weakest:

Strong Reference: By default.

Weak references: A weak reference is a reference that isn't strong enough to force an object to remain in memory. Weak references allow you to leverage the garbage collector's ability to determine reachability for you, so you don't have to do it yourself. You create a weak reference like this:

WeakReference<Widget> weakWidget = new WeakReference<Widget>(widget);
weakWidget.get() // get the actual Widget

Of course the weak reference isn't strong enough to prevent garbage collection, so you may find (if there are no strong references to the widget) that weakWidget.get() suddenly starts returning null.

Soft references: A soft reference is exactly like a weak reference, except that it is less eager to throw away the object to which it refers. An object which is only weakly reachable (the strongest references to it are WeakReferences) will be discarded at the next garbage collection cycle, but an object which is softly reachable will generally stick around for a while. Soft References aren't required to behave any differently than WeakReferences, but in practice softly reachable objects are generally retained as long as memory is in plentiful supply. This makes them an excellent foundation for a cache, since you can let the garbage collector worry about both how reachable the objects are and how badly it needs the memory they are consuming.

Phantom references

A phantom reference is quite different than either SoftReference or WeakReference. Its grip on its object is so tenuous that you can't even retrieve the object -- its get() method always returns null. The only use for such a reference is keeping track of when it gets enqueued into a ReferenceQueue, as at that point you know the object to which it pointed is dead. How is that different from WeakReference, though?

The difference is in exactly when the enqueuing happens. WeakReferences are enqueued as soon as the object to which they point becomes weakly reachable. This is before finalization or garbage collection has actually happened. In case of Weak Reference, object could even be "resurrected" by an finalize() method, but the WeakReference would remain dead. PhantomReferences are enqueued only when the object is physically removed from memory, and the get() method always returns null specifically to prevent you from being able to "resurrect" an almost-dead object.

Use of Phantom Reference:

1. They allow you to determine exactly when an object was removed from memory. They are in fact the only way to determine that. This isn't generally that useful, but might come in handy in certain very specific circumstances like manipulating large images: if you know for sure that an image should be garbage collected, you can wait until it actually is before attempting to load the next image, and therefore make the dreaded OutOfMemoryError less likely.

2. PhantomReferences avoid a fundamental problem with finalization – resurrection. With PhantomReference, resurrection is impossible. When a PhantomReference is enqueued, there is absolutely no way to get a pointer to the now-dead object.Arguably, the finalize() method should never have been provided in the first place. PhantomReferences are definitely safer and more efficient to use, and eliminating finalize() would have made parts of the VM considerably simpler. But, they're also more work to implement, so I confess to still using finalize() most of the time. The good news is that at least you have a choice.

Q10. Talk about garbage collector for various references.
Ans. If an element is determined to be eligible for processing, GC must determine if it is eligible for collection. The first criterion here is simple. Is the referent marked? If it is marked, the reference object is not eligible for collection and GC moves onto the next element of the list. However, if the referent is not marked and is eligible for collection, the process differs for each reference type. 

Soft references are collected if their referent has not been marked for the previous 32 garbage collection cycles. You adjust the frequency of collection with the -Xsoftrefthreshold option. If there is a shortage of available storage, all soft references are cleared. All soft references are guaranteed to have been cleared before the OutOfMemoryError is thrown.

Weak and phantom references are always collected if their referent is not marked. 

Soft vs Weak vs Phantom References
Type	Purpose	Use	When GCed	Implementing Class
Strong Reference	An ordinary reference. Keeps objects alive as long as they are referenced.	normal reference.	Any object not pointed to can be reclaimed.	default
Soft Reference	Keeps objects alive provided there’s enough memory.	to keep objects alive even after clients have removed their references (memory-sensitive caches), in case clients start asking for them again by key.	After a first gc pass, the JVM decides it still needs to reclaim more space.	java.lang.ref.SoftReference
Weak Reference	Keeps objects alive only while they’re in use (reachable) by clients.	Containers that automatically delete objects no longer in use.	After gc determines the object is only weakly reachable	java.lang.ref.WeakReference  java.util.WeakHashMap
Phantom Reference	Lets you clean up after finalization but before the space is reclaimed (replaces or augments the use of finalize())	Special clean up processing	After finalization.	java.lang.ref.PhantomReference

Q11. Explain garbage collection on Remote Objects or Distributed Garbage collection. 

Ans. In a distributed system, just as in the local system, it is desirable to automatically delete those remote objects that are no longer referenced by any client. This frees the programmer from needing to keep track of the remote objects' clients so that it can terminate appropriately. RMI uses a reference-counting garbage collection algorithm for the same. 

To accomplish reference-counting garbage collection, the RMI runtime keeps track of all live references within each Java virtual machine. When a live reference enters a Java virtual machine for first time, it sends a "referenced" message to the server for the object. Going forward, whenever a live reference enters JVM, its reference count is incremented and is decremented as soon as it leaves the JVM. When the last reference has been discarded, an unreferenced message is sent to the server. Many subtleties exist in the protocol; most of these are related to maintaining the ordering of referenced and unreferenced messages in order to ensure that the object is not prematurely collected. 

When a remote object is not referenced by any client, the RMI runtime refers to it using a weak reference. The weak reference allows the Java virtual machine's garbage collector to discard the object if no other local references to the object exist. As long as a local reference to a remote object exists, it cannot be garbage-collected and it can be passed in remote calls or returned to clients. Remote objects are only collected when no more references, either local or remote, still exist. The distributed garbage collection algorithm interacts with the local Java virtual machine's garbage collector in the usual ways by holding normal or weak references to objects. 

In addition to the reference counting mechanism, a live client reference has a lease with a specified time. When the client is done with the reference and allows the remote stub to go out of scope, or when the lease on the object expires, the reference layer on the host automatically deletes the record of the remote reference and notifies the client's reference layer that this remote reference has expired. The lease time is controlled by the system property java.rmi.dgc.leaseValue. The value is in milliseconds and defaults to 10 minutes. The concept of expirable leases, as opposed to strict on/off references, is used to deal with situations where a client-side failure or a network failure keeps the client from notifying the server that it is done with its reference to an object.

A remote object needing unreferenced notification must implement the java.rmi.server.Unreferenced interface. When those references no longer exist, the unreferenced method will be invoked.

Q12. Does OutOfMemoryError and StackOverFlowError cause JVM crash?

Ans. Any problem in PURE Java code throws a Java exception or error. Java exceptions or errors will NOT cause a core dump (on UNIX systems) or a Dr.Watson error (on WIN32systems). Any serious Java problem will result in an OutOfMemoryError thrown by the JVM with the stack trace and consequently JVM will exit. An OutOfMemoryError (not jvm crash) can be thrown due to one of the following 4 reasons:

1. JVM may have a memory leak due to a bug in its internal heap management implementation. But this is highly unlikely because JVMs are well tested for this.

2. The application may not have enough heap memory allocated for its running. You can allocate more JVM heap size (with –Xmx parameter to the JVM) or decrease the amount of memory your application takes to overcome this. You can increase heap size as below:

          java -Xms1024M -Xmx1024M

Care should be taken not to make the –Xmx value too large because it can slow down your application.

3. Another not so prevalent cause is the running out of a memory area called the “perm” which sits next to the heap. All the binary code of currently running classes is archived in the “perm” area. The ‘perm’ area is important if your application or any of the third party jar files you use dynamically generate classes.

For example: “perm” space is consumed when XSLT templates are dynamically compiled into classes, J2EE application servers, JasperReports, JAXB etc use Java reflection to dynamically generate classes and/or large amount of classes in your application. To increase perm space:
     java -XX:PermSize=256M -XX:MaxPermSize=256M

4. The fourth and the most common reason is that you may have a memory leak in your application.

Q13. Different OutOfMemory errors.

Ans. Let’s have a look at the Sun HotSpot JVM and its concrete implementation of OutOfMemoryError errors.

1.    In the heap we get an OutOfMemoryError, if the garbage collector cannot reclaim enough memory for a new object. In such situation the Sun HotSpot JVM shows this error message:

               java.lang.OutOfMemoryError: Java heap space

2.    An alternative for this is as below, it occurs when application tries to create an array on the heap that is bigger than the total heap size.

             java.lang.OutOfMemoryError: Requested array size exceeds VM limit

3.    If there is not enough memory in the method area for creating a new class, the Sun HotSpot implementation gets an error in the permanent generation:

             java.lang.OutOfMemoryError: PermGen space

4.    OutOfMemory errors in thread exclusive memory areas occur less frequently and are identified by the following error messages in the Sun HotSpot JVM:

              java.lang.OutOfMemoryError: unable to create new native thread

This occurs if there are too many threads in the JVM and there is not enough memory left to create a new thread. I’ve seen this because the memory limits of a process have been reached (especially in 32bit operating systems, e.g. on Windows 32bit it is 2GB) or the maximum number of file handles for the user that executes the java process has been reached.

5.    It indicates that a memory allocation error on a native stack (JNI method call) has occured.

               java.lang.OutOfMemoryError: <reason> <stacktrace> (Native method)

6.    It is also interesting that a memory allocation error on the JVM stack (too many frames on the stack) does not throw an Java OutOfMemory error but as the JVM specification mandates.

                java.lang.StackOverflowError

7.    The last variant of the OutOfMemoryError is out of swap space. This error is thrown if there is not enough memory left on the operating system level – which is normally true if other processes are using all of the available memory or the swap space is configured too small.

                 java.lang.OutOfMemoryError: request <size> bytes for <reason>. 

Q14. Why does the JVM crash with a core dump or a Dr.Watson error?

Ans. Both the core dump on UNIX operating system and Dr.Watson error on WIN32 systems mean the same thing. If you define a crash as an unhandled problem (i.e. no Java Exception or Error); then this cannot be done from within Java. The JVM is a process like any other and when a process crashes a core dump is created. A core dump is a memory map of a running process. This can happen due to one of the following reasons:

1. Using JNI (Java Native Interface) code containing a fatal bug in it. Typical crashes in native code happen by dereferencing pointers to wrong memory areas (like Nullpointer) or illegal opcodes.

For ex: using Oracle OCI drivers, which are written partially in native code or JDBC-ODBC bridge drivers, which are written in non Java code. Using 100% pure Java drivers (communicates directly with the database instead of through client software utilizing the JNI) instead of native drivers can solve this problem.

2. The OS on which your JVM is running might require a patch or service pack.

3. The JVM implementation may have a bug in translating system resources like threads, file handles, sockets etc from the platform neutral Java byte code into platform specific operations. If this JVM’s translated native code performs an illegal operation then the operating system will instantly kill the process and mostly will generate a core dump file.

The core dump files are generated by the operating system in response to certain signals. The JVM can also intercept certain signals like SIGQUIT which is kill -3 <pid> from the operating system and it responds to this signal by printing out a Java stack trace and then continue to run. On the other hand signals like SIGSTOP (kill -23 <pid>) and SIGKILL (kill -9 <pid>) will cause the JVM process to stop or die. The JVM argument "java –Xsqnopause" will indicate JVM not to pause on SIGQUIT signal from OS.

4. On Linux/Unix, it is easy to crash JVM crash by sending it a Signal to the running process.

Note: You should not use "SIGSEGV" for this, since JVM catches this signal and re-throws it as a NullPointerException in most places. So it is better to send a SIGBUS.

Nested and Inner classes

Q1. What is static class? Why would you need a static class?
Ans. First of all, a top level class can't be static. The compiler will detect and report this error. Thus only an inner class can be declared static, which is known as nested class.

Nested top-level classes are typically used as a convenient way to group related classes without creating a new package. If your main class has a few smaller helper classes that can be used outside the class and make sense only with your main class, it's a good idea to make them nested (top-level) classes.

NOTE: A static class can have non-static members and methods.

Q2. What is the difference b/w a nested class and inner class.

Ans. Static inner classes are known as nested classes and non-static inner classes are known as inner class.

Nested class:
As with class methods and variables, a static nested class is associated with its outer class. Nested class cannot refer directly to instance variables or methods defined in its enclosing class — it can use them only through an object reference. Static nested classes are accessed using the enclosing class name, i.e. OuterClass.StaticNestedClass

For example, to create an object for the static nested class, use following:
    OuterClass.StaticNestedClass nestedObject = new OuterClass.StaticNestedClass();

Inner class:
As with instance methods and variables, an inner class is associated with an instance of its enclosing class and has direct access to that object's methods and fields. Also, because an inner class is associated with an instance, it cannot define any static members itself.

Objects that are instances of an inner class exist within an instance of the outer class. Consider the following classes:class OuterClass {
     ...
     class InnerClass {          ...
     }
}
To instantiate an inner class, you must first instantiate the outer class. Then, create the inner object within the outer object with this syntax:
     OuterClass.InnerClass innerObject = outerObject.new InnerClass()

Q3. How do you get a reference to outer class in inner class and declare an object of inner class.
Ans. Using .this and .new.

Inside inner class, this would refer to inner class itself, so you access the outer class as “OuterClassName.this”

And to create an object of inner use .new i.e “o.new Iclass”
     where o is object of outer class Oclass and Iclass is inner class of outer class Oclass.

Q4. What are various types of inner classes?
Ans.
1. Anonymous: Anonymous classes are declared and instantiated within the same statement. They do not have names, and they can be instantiated only once. Since an anonymous class doesn't have a normal class declaration where it's possible to use static, it cannot be declared static.

2. Local: Local classes are the same as local variables, in the sense that they're created and used inside a block. Once you declare a class within a block, it can be instantiated as many times as you wish within that block. Like local variables, local classes aren't allowed to be declared public, protected, private, or static.

3. Member: Member classes are defined within the body of a class. You can use member classes anywhere within the body of the containing class. You declare member classes when you want to use variables and methods of the containing class without explicit delegation.

The member class is the only class that you can declare static (which when declared static is known as nested class). 

4. Nested top-level: A nested top-level class is a member classes with a static modifier. 

Q5. How is local inner class different from anonymous class and which one you should chose?
Ans. Local inner class has a name associated (inside a method only), whereas anonymous class doesn't. Since the name of the local inner class is not accessible outside the method, the only justification for using a local inner class instead of an anonymous inner class is if you need a named constructor and/or an overloaded constructor, since an anonymous inner class can only use instance initialization.

Another reason to make a local inner class rather than an anonymous inner class is if you need to make more than one object of that class. 

NOTE: Arguments passed to a method are accessible to local inner or anonymous class only if argument is being passed as final.

Q6. Anonymous inner class, 
            as return new Contents { ......};
Ans. What this strange syntax means is "Create an object of an anonymous class that’s inherited from Contents." The reference returned by the new expression is automatically upcast to a Contents reference.

Q7. Can inner classes be overridden?
Ans. There isn’t any extra inner-class magic going on when you inherit from the outer class. The two inner classes are completely separate entities, each in its own namespace. So, it’s still possible to explicitly inherit from the inner class.

Q8. Can you define constructors for inner classes?
Ans. Yes, but only when inner class has a name. Since anonymous classes don’t have a name, it is not possible to have a constructor. In such cases, instance initializer acts as constructor ( i.e code inside curly braces in class body). The only drawback in this case is that you can't have overloaded constructors, which is possible in case of named inner classes.

Q9. Can inner class have static members?
Ans. No

Q10. Where should you use inner classes?

Ans. Code without inner classes is more maintainable and readable. When you access private data members of the outer class, the JDK compiler creates package-access member functions in the outer class for the inner class to access the private members. This leaves a security hole. In general we should avoid using inner classes. Use inner class only when an inner class is only relevant in the context of the outer class and/or inner class can be made private so that only outer class can access it. Inner classes are used primarily to implement helper classes like Iterators, Comparators etc which are used in the context of an outer class.

Q11. Why do we need inner classes?
Ans.In case of multiple inheritance, you can inherit from only one implementation (class) and rest has to be interface.

Inner classes solve this issue, when Outer class O extends an implementation (class A) and inner class I extends other one (class B). Each inner class can independently inherit from an implementation. Thus, the inner class is not limited by whether the outer class is already inheriting from an implementation.

Interfaces solve part of the problem of multiple inheritance, but inner classes effectively allow "multiple implementation inheritance." That is, inner classes effectively allow you to inherit from more than one non-interface. Also, inner classes help us to have closure and callback functionality. 

A closure is a callable object that retains information from the scope in which it was created. An inner class is an object-oriented closure, because it doesn’t just contain each piece of information from the outer-class object ("the scope in which it was created"), but it automatically holds a reference back to the whole outer-class object, where it has permission to manipulate all the members, even private ones.

With a callback, some other object is given a piece of information that allows it to call back into the originating object at some later point. One of the most compelling arguments made to include some kind of pointer mechanism in Java was to allow callbacks.