In the earlier post, I have discussed about the Locking
mechanism in IBM J9 VM in Java 5 and Java 6. In this blog post, let us see the
changes that are to be introduced in the new Locking mechanism R626.

We have seen that a thread does spinning in the following
scenarios

-When Flat Lock is Busy

-When Inflated Lock is Busy

-When native level Lock is Busy

As earlier mentioned, spinning
increases efficiency as we are avoiding expensive context switches and also
avoiding the need to immediately move to OS calls to manage Locking. However,
CPU consumption is not free. If the system is already busy, spinning can eat
away some CPU cycles which could otherwise be utilized elsewhere. For locks
that are held for longer time, the spinning does not make sense (say the thread
spins for a period X. And the lock is typically held for X+Y).

The following features are
introduced in regard to the above:

Eliminate multiple spin

Disable excessive spinning. Suppose an object monitor which is in inflated mode. When a thread fails to acquire that lock in inflated mode with a spin, it does a spin again
on JVM system monitor.

We are disabling the secondary spinning that we do on
JVM system monitors.

-Xthr:secondarySpinForObjectMonitors
is the option to disable this feature and enable spin on JVM system monitors.

Adaptive Spinning

This feature decides whether
spinning is beneficial for certain set of locks and disables if not necessary.
This is enabled by default from IBM Java R626.

This feature is achieved by sampling
lock acquiring information, whenever there is contention on the lock. It
collects data related to hold times (the period for which the lock is held) and
Slow percentages (percentage of lock acquires that made the thread wait to the
total lock acquires).

Based on heuristic values obtained
in our labs about the above entities, J9 JVM will disable spinning on that
particular lock, if it is deemed as unnecessary. Once spinning on a lock is
disabled, it is done so for the rest of the application run. Sampling will also
be disabled too on that lock during that period.

-Xthr:adaptSpin/-Xthr:noAdaptSpin
options are used to enable/disable this feature.

Eclipse now has a BETA release that supports Java7 Features. So, if you want to play around with Project Coin or any NIO2 features, updated your existing eclipse install using the instructions given here

The Memory Analyzer is a fast and feature-rich Java heap analyzer that helps us find memory leaks and reduce memory consumption. It works with multi-GB heaps of various formats like IBM core dumps, IBM PHD (Portable Heap Dumps) heapdumps, Sun HPROF heapdumps. The Memory Analyzer provides efficient memory leak detection and footprint analysis with powerful reporting capabilities including memory leak suspects, system overview, top components (by retained heap) and more. Memory Analyzer (MA) is based on the open source tool MAT with IBM value add.The Memory Analyzer is a free tool available through the IBM Support Assistant.

Why do we need to use Memory Analyzer?

Because Java provides automatic memory management, a lot of developers believe that Java applications do not have memory leaks. Garbage Collection in Java does relieve us from the mundane duties of allocating, tracking and freeing objects in the Java heap. But Garbage Collection can only free objects that do not have any reference from the active state of the program (stacks and registers) or other objects – and typical memory leaks are caused by objects that are no longer required in the heap, but persist in the heap due to a reference to them.

Memory leak analysis looks into a few key entities.

–What is the object (e.g. a HashMap) holding all the leaking objects i.e. leak container.

–What are the objects getting added to the leak container i.e. leak unit.

–Who is holding the leak container in memory? What are the object types and package names of objects on the chain of references from a root object to the leak container i.e. owner chain.

Debugging Memory leak is not an exact science, analysis will point out suspects. Likelihood of leak depends upon the size of the leaking data structure, drop size, number of leaking units and the number of instances of objects in the ownership context graph nodes.

Last time, I ended on Parent Delegation model and reasons for "Why you should have a custom classloader for your application". Let me dwell on this a bit:.In the delegation model, all custom classloaders sit beneath the Application Classloader. I mentioned that when there's a classload requested for a classloader, it should ask its parent to try and load it. Well, the guys who wrote all this magic (a.k.a classloading) thought - "how do we improve this process of 'parent delegation'? "Answer to that is the Classloader cache..Every classloader has its own cache - which would hold the "defined class structure" of every successful classload it has performed.So let me change the parent delegation definition a bit now:."when a classload is requested out of a CL, the CL should look for the class structure in its cache . If it finds one, use it. Else, delegate to the parent .. (and they can live happily-ever-after till CNFE doesn't surface!)".How does it help? Well, the very first time for any class - parent delegation is a must .If the parents fail to load the class, it will come down to the current CL itself. If it finds the class, it goes and stores it in its cache.So the next time a classload is requested, and say , you found it in the cache - you can use it because you are assured that a parent delegation 'had' occurred sometime in the past for this class .All is well..So, its handy you remember this when you write your own classloaderLookup sequence:CACHE (this.findLoadedClass()) >>> PARENT(super.loadClass()) >>> DISK(this.findClass() and then this.loadClass()).sample code :.

---->...Class c = findLoadedClass(name); //Used to check if the class is already loaded

.So, the classloader cache certainly pips speed of the classloading sequence a bit (not to be confused with Shared Class Cache, which I hope to blog in few days time).To lessen the tax on the system , the JVM also employs what is called as a Lazy Loading - meaning a classload is initiated at the following times onlyi) creation of the first object of that classii) first instance of any of the subclasses of this classiii) any of this class's static field is initialized.This way you are assured of classloads of only the required classes. Saves space , saves time.(Its opposite number is the Eager classloading - recursive loading of all classes referenced in our application - and I believe is used in Real Time applications.. )..Few things on Class Unloading:Comes into effect ONLY if there's a custom classloader in your application - because the other three classloader loaded classes are never unloaded.A class and its classloader are linked through its JVM internal structures. So only when a classloader is out of scope for the JVM will that classloader's classes will be unloaded.(for more on this, you should attend the webinars on "Understanding Java Memory Management" and "Debugging Classloader Memory Leaks in the WebSphere Application Server" as part of the Java Week)..CNFE , NCDFE and the other usual suspects are coming soon.. and also some of the debugging techniques we use to find " 'em goons" .. .Happy Java Week!

It means a lower Total Cost of Ownership
(TCO) for us and our customers.

Problem determination and resolution has
become a daunting task as more of today’s solutions involve complex
collections of products and applications deployed in heterogenous
environments

Developing and deploying new solutions gets
delayed by maintenance of diverse existing systems

25-50% of time is spent in
problem determination and resolution

The skills needed to do manual cross-product
problem determination are scarce and expensive.

In this age of complex and integrated systems and short cycle times of deployment, the ability to respond to business demands in a timely manner is becoming critical. Pro-active problem determination, quick and easy access to relevant information, reduced turnaround times on interactions with support organizations are key - client "self assist" is the "buzzword"

Java developers frequently
encounter runtime problems during development, migration and post production
stages and spend significant amount of time diagnosing and resolving those
issues. Quick turnaround for problem determination is a key focus area.

In the recent times a wide array
of new tooling has emerged from the IBM Java
Technology Center
and WebSphere Serviceability teams that enable developers to debug Java Runtime
issues in a convenient way. A key focus area for IBM is to make the user experience with these tools a convenient one. Tools should be easy to obtain, available from a single source and easy to update. The IBM Support Assistant (www.ibm.com/software/support/isa)
is a free local workbench that includes rich features and serviceability tools
for quick resolution to problems. All the Java tools delivered through the IBM Support Assistant provide the capabilities of :

- "Visualization" Provide different graphical views for a diagnostic data input (a view of increased java heap usage over time for example)

- "Analysis" Analysis reports based on the data analyzed (analysis of the increased heap usage over time indicating a memory leak for example)

- "Recommendations" Recommendations and suggestions to resolve the observed problem (Analysis of heapdumps to identify the cause of memory leak for example)

Some cool Java Runtime tools to check out are: (all tools available on IBM Support Assistant)

Garbage Collection and Memory
Visualizer ﻿

The Garbage Collection and Memory
Visualizer is available as a plug-in to IBM Support Assistant
(ISA). It analyzes verbose GC output to provide plots, summaries and
recommendations. The tool profiles heap usage, heap sizes, pause times
and many other properties. Flexibility of comparing multiple logs in the same
plots and many views on data (reports, graphs, tables) are available. This is a powerful tool to debug performance bottlenecks in the Java application due to Garbage Collection.

Memory Analysis Tool (MAT)﻿

Memory Leaks in Java are a consequence of non obvious programming errors - and debugging memory leaks is not an exact science. The Eclipse Memory Analyzer is a
fast and feature-rich Java heap analyzer that helps you find memory leaks and
reduce memory consumption. The Memory Analyzer was developed to analyze
productive heap dumps with hundreds of millions of objects. Once the heap dump
is parsed, you can re-open it instantly, immediately get the retained size of
single objects and quickly approximate the retained size of a set of objects.

The IBM® Monitoring and Diagnostic
Tools for Java™ – Health Center™

Health Center
is a lightweight monitoring tool (with a performance overhead of not more than 2-3%) which allows running Java™ Vitual Machines to be observed and
health-checked. The Health
Center enables insights
into general system health, application and garbage collection activity. Developers, performance engineers
and practitioners can use the IBM
Health Center
tool to quickly identify any performance bottlenecks which is specifically
helpful in an agile development environment. Designed to attach to a running
Java process to explore what it is doing, how it is behaving, and what you
could do to make it happier.

This blog series will cover some of the new language features available in Java7. To start with, lets cover some changes that are available under the pseudonym "Project Coin" or in the Community parlance JSR334.The main theme of "Project Coin" according to its Spec Lead Joseph Darcy is "making things programmers do every day easier".

Since Project Coin itself contains a number of small language changes, lets look at them one at a time. The first language change we will be discussing is called "Strings in Switch".

Strings in Switch

To understand this language feature, lets look at a simple use-case - a method that checks the input and prints the matching color.

Prior to Java7, there were generally 2 options available to achieve this. Lets look at them one by one:

Option 1:

This the most obvious and simple way of using multiple if-else blocks to check and validate the input.

But would you really use them to create any enterprise application with them by ignoring Java. Java which is already mature and strong language to develop big big applications. I don't think you will try to do so. Java is widely used language in almost all the platforms and devices. Why should one move from Java to any of these dynamic languages?

So lets see how dynamic languages are better, as they claim to be. Here I will talk about Groovy. Groovy is meant for doing the simple things in simple way. Groovy does not compel you to catch exceptions, its take cares of the types, it provides the wonderful feature of closures and a lot. You need to have look at the blog written by Scott Davis to see how the complicated XML parsing is simple in Groovy.

Now if you get these kind of features from a language like Groovy, would you still prefer coding in Java ? But as I told earlier Groovy is just a baby in front of a mature language like Java. So what should be done ??!!

What if I tell its not Java which is so mature it sounded till now in this blog ?? Yes I am right. Its not the Java which makes the application run in any platform or in any device. Its the JVM. What if I tell that the Groovy is also based on the same JVM which is being used by Java. So it means Groovy is also almost equally mature and you have seen how easy it is to code on the same. Hence Groovy is better than Java.

As Java after compilation gives class, Groovy does the same. As Java gives you JAR, do you know Groovy also gives the JAR ? So if Groovy gives the JAR cant we use that JAR in Java application ?? Cant we write a complicated code in simpler way in Groovy and then use it in Java code; after all its a JAR in the end ???

Yes we can ...... we can very well do it. We can very well write our code in Java and use it in Groovy or write the code in Groovy and use it in Java. The languages over the JVM platform including Groovy, Scala, Jython, etc. can seamlessly be integrated with each other as in the end they all run on JVM.

Loading of dumps from the java process with larger heap size takes more time to load the dump and display the results in GUI mode. To ease the analysis of the larger dumps, Memory Analyzer has the option to use the tool in "Batch" mode which allows us to start the processing of dumps in non-GUI mode on higher-end boxes. It produces standard reports like Leak Suspects, System Overview, Top Components reports. MA generates the "index" files automatically when it parses the dump. We can copy these reports and index files along with the dump to our local machine and we can perform interactive analysis with GUI mode. This helps us to save time on loading and processing larger dumps.

Below is the sample command using which we can invoke MAT in batch mode

Today, all the software applications in the industry are multi-threaded. Multi-threading enables efficient utilization of system resources and decreases over head in switching contexts. However, the application needs to protect the data that is shared, to avoid improper and unsafe access to shared data. Locking is one of the key aspects in Java application programming and helps protect the integrity of shared data in a multi-threaded application.

Locking however can also cause problems if improperly used.Some of the common problems associated

Developers can use "IBM Monitoring and Diagnostic Tools for Java - Health Center" tool that comes with IBM Support Assistant(ISA) to analyse the Locking related issues.

Health Center records all locking activity and identifies the objects with most contention. Health Center analyses this information, and uses it to provide guidance about whether synchronization is impacting performance.

In Java, a lock acquired can be either slow or fast. Fast lock acquire does not wait the thread which is trying to acquire it. Slow lock acquires requires the thread to wait until it becomes free.

In the Monitors view % miss refers to the percentage of slow acquires on a lock against total number of lock acquires whereas Gets refers to the total number of lock acquires. The Monitor View also provides information on the number of recursive lock acquires, average amount of time the lock was held, or owned, by a thread and % util which refers to the amount of time the lock was held, divided by the amount of time the output was taken over. %miss is a good indication about the extent of contention on the lock.

The bar graph indicates all the Java monitors which were acquired slow atleast once. The height of each bar indicates the number of slow acquires. The color indicates the extent of contention based on %miss. Green indicates low contention. Amber indicates high contention and red indicates very high contention.

The contention indicates either a lock is held by a thread for a long time or the application is designed to have a lot of threads waiting (while wasting other system resources) for a thread-safe data.

This is a continuation from the blog post by Rajeev which provided an introduction to the IBM Health Center - Please read more here and the blog post from me which provided an information about Installing and Launching Health Center - Please read more here

Subsystems:The Status Summary page lists the various subsystems profiled by the Health Center which include Classes, Environment, Garbage Collection, I/O data, Locking, Native Memory and Method Profiling. This page provides a summary of the “health” of the various subsystems. The summary will indicate if there are any potential problems with the particular subsystem (indicated in Red color), or tuning suggestions for optimizing the subsystem further (indicated in Amber) and an indication of a healthy subsystem (with no problems) denoted in Green color.

Classes Subsystem:Health Center provides class loading information, showing exactly when a class has been loaded into the Java Virtual Machine (JVM) and whether the class is cached or not (in the Shared Classes Cache). This helps users in determining whether their application is being affected by excessive class loading.

Environment Subsystem:Health Center uses an 'environment perspective' to provide details of the Java version, Java classpath, boot classpath, environment variables, and system properties. This is particularly useful for identifying problems on remote systems or systems where you are not able to access the configuration details. If the Health Center detects mis-configured applications, it will provide recommendations on how to fix it. For example a debug trace option introduced during development cycle may have been left as is with possible performance implications when moved to production. Environment Subsystem will point to such a scenario.

IO Subsystem:Health Center uses an 'I/O perspective' to monitor application input or output (I/O) tasks as they run. Users can use this perspective to monitor how many and which files are open, and to help solve problems such as when the application fails to close files.

Locking Subsystem:Health Center records all locking activity and identifies the objects with most contention. Health Center analyses this information, and uses it to provide guidance about whether synchronization is impacting performance.

Native Memory Subsystem:"Native memory" subsystem gives a view of 'Process Virtual Memory' and 'Process Physical Memory' plotted against time with JVM start time as the reference.

Profiling Subsystem:The Health Center uses a sampling method profiler to diagnose applications showing high CPU usage giving full call stack information for all sample methods. Health Center works without recompilation or bytecode instrumentation and shows where the application is spending its time.

In java programs, the use of pointers is forbidden by virtue of a design strategy or a security policy. Without pointers, functions cannot access objects across stack frames, among many other limitations. The inability to pass objects to and from functions will limit the scope of a programming language at large. To remedy this, in java, user defined objects are inherently passed by address (termed as reference), in contrast to C and C++ where passing arguments by their addresses is a volitional choice.

Conventionally, when arguments are passed by value, what the callee recieves is an isolated copy of the passed object. In C, when passed by address, the callee can manipulate the caller's arguments. In C++ the same applies, along with the call by reference. The user objects are normally created on the stack. In cases of producer functions where the function generates and returns an object, the allocation has to be made in the heap (locally created objects cannot be returned from a function, which causes dangling reference). Such cases are not so often, so one can free the object manually which was 'newed'. Two modes of creating user objects are:

Class obj(); => object and the handle created on the stack.Class *obj = new Class(); => object in the heap, reference on the stack.

In java, without pointers, the language semantics does not allow the above flexibility and we have only one way to create objects – either everything on the stack or in the heap, not both. Creating all the objects on the stack is a bad choice, since objects whose life span is greater than the defining method will be destroyed when the frame is popped off while the function’s return, essentially forbidding methods from returning generated objects, causing java to be an incomplete language. As a workaround, all the objects are created in the heap. Now, as a matter of fact, it is difficult for a programmer to delete all the objects he 'newed' which are quite many, rather most of them.

Hence the garbage and hence the collector.

In a non-java programming paradigm, it is like allocating memory at arbitrary heap locations, and later scanning the entire virtual memory to clean up the filth.

Garbage collection is not a java feature. It is a compromise. A consequence of refraining from pointers. A skillful attempt to mend a defect. An unchecked sun heredity and an unbridled software hypothesis which we carried and dragged all the way along.

In this final post, let us strive to figure out whether Java as a programming language is deficient in carrying out any computational task. We have shown a bunch of examples from Clojure in the previous two posts. Now, let us see whether the functional programming feats that the programmers of Clojure accomplishes can be performed equally well in Java.

Let us start with an example using Google's Guava library. Our main goal is to convert temperatures from Celsius to Fahrenheit in a functional way:

We could have achieved the above task with a simple for loop. Is there anything wrong with for loop? Not really. The only issue is that for any slight modification, we need to manually code another for loop. Reaumur would have forced us to code one more for loop! The point that we would like to make is that everything is possible in Java. However, the question remains is how elegantly we can attain our tasks with Java.

Consequently, there is a lot of discussion of bringing a bunch of functional programming aspects into Java. Check out the references at the end of this post.

Finally, let us look at one more strong aspect of Java. JVM is a very well-tested platform. The languages like Clojure, Scala, Jython, JRuby, ETC. run on this platform. As a result, they all can use the Java libraries very easily in their programs. Here is an example in Clojure:

It does not take that much time for us to understand the above code. The point is clear that JVM and Java libraries are extremely valuable. In other words, Java will not die any time in the near future. In addition to that, none of these new JVM languages do not make our Java skills obsolete.

Let us put an end to our feesting on the functional binge for now. There is a lot to learn in this area. We have barely scratched the surface. Please check out the references listed here and the ones mentioned in the previous posts.

In this blog post, i am talking about deadlocks (while acquring application resources) in Java code that result in application hangs and the common detection approach using IBM diagnostics. Javacores are quite helpful in understanding the scenario that leads to deadlocks. Java cores can be triggered with a user signal.

Deadlocks can happen in one of the possible scenarios

1. Two threads each are waiting to acquire a resource which is held by the other, causing both the threads to block.

When method foo is invoked by Thread thr1, thr1 acquires a lock on obj1(as foo is synchronized). And it tries to enter obj2 through synchronized block. Similarly, thr2 acquires obj2 lock before waiting to enter obj1. This is a classic deadlock where each thread is trying to enter a lock which is held by other. If a javacore is dumped, you see the following section in it to indicate the scenario

Each of the two classes(resources) that each thread initializes has a static method of another class in its own static section. So when thread t1 is initializing the class first, it gets required to initialise class second as well. And the vice versa to thread t2.

Java cores do not have any particular section to describe these kind of deadlocks as the notifying thread need not necessarily be the thread wich is initializing the resource. However java stacks give adequate information to point to this condition.

For example, "Thread-7" is waiting on class second object while also initializing class first. At the same time, you see in the Thread-8 stack that class second is not yet initialized so far and initialization is under way.

Every hardware architecture defines its own instruction set. Instructions, in the simplest sense, are commands to the processor unit to trigger a specific electronic operation on a definite number of operands - which again are memory locations or physical registers. Probably, the creators of Java were inspired by this functioning of physical machines. When they conceptualized a virtual version of the metallic machines (hardware) and called it the Java Virtual Machine, a Virtual Machine Instruction Set also came into existance. They named these Virtual Machine Instructions as Bytecodes.

We do not, however, have virtual registers! The execution is carried out on a stack-machine. The Bytecodes were hence designed to operate on an operand stack.

Consider two simple Java methods written to find the area of a circle.

Exceptions are the customary way in Java to indicate to a calling method that an abnormal condition has occurred.Exceptions can occur because of many events -• Hardware failure• Resources exhaustion• Bug in the programException is said to be thrown when such events occur.Exception classesIn Java, exceptions are objects. When we throw an exception, we throw an object. We can't throw just any object as an exception, however - only those objects whose classes descend from Throwable. Throwable serves as the base class for an entire family of classes, declared in java.lang, that a Java program can instantiate and throw.There are two kinds of exceptions in Java, checked and unchecked and only checked exceptions need appear in throws clausesChecked exception - Checked exceptions are so called because both the Java compiler and the Java virtual machine check to make sure this rule is obeyed.Checked exceptions that may be thrown in a method must either be caught or declared in the method's throws clause.Unchecked exceptions - These exceptions also known as "Runtime Exceptions" are a special case because they do not need to be handled or declared, and thus are known as "unchecked" exceptions eg .Java.lang.NullPointerExceptions. Errors are of type java.lang.Error or its subclasses, and like runtime exceptions, they do not need to be handled or declared.Errors are generally thrown by Java APIs and Java virtual machine itself.

Whether an exception is "checked" is determined by its position in the hierarchy of throwable classes. To create a new checked exception, you simply extend another checked exception. All throwables that are subclasses of Exception, but not subclasses of RuntimeException are checked exceptions.

In my future blog entries I will discuss the causes and resolution of many common java exceptions.

ForkJoin is one of the neat and cool features introduced in Java 7. ForkJoin Algorithms are highly effective algorithms for resolving problems that follow "Recursive style ("Divide and Conquer Approach)" like FIbanocci, Merge Sort etc, where the tasks that are split to be processed are independent entities, and processed except for may be sharing only the output buffer with no other synchronization needed . Even though Merge sort task for eg, operate on a single buffer, they access different index's, for eg, when a task of 1000 entries, is divided in to 4 tasks, each task is processing different index ranges, and there is no need for synchronization.

Point to be noted is, the problem should be having specific characteristic to use the fork/join framework effectively.

they are

1. The problem data(List/file/map...) to be processed and the computation on the data should be dividable to smaller subtasks.2. Processing each of these sub tasks should be possible without requiring the result of other chunks. (except for waiting on Join for collating)

Fork Join algorithms are best suited for such class of application.

If you go through the documentation for ForkJoinTask, Restrictions are clearly documented. I have tried to list most of them here

1. ForkJoinTasks are intended to be used as "Computation tasks" for calculating pure functions (ie purely isolation objects.2.Computations should avoid synchronized methods or blocks3.Only allowed synchronizers are modern synchronizers such as Phasers that are advertised to cooperate with fork/join scheduling.4. No other synchronization should be required except for synchronization by "Join".5. Tasks should also not perform blocking IO, and should ideally access variables that are completely independent of those accessed by other running tasks.

Minor breaches of these restrictions may be tolerable (as all of these restriction cannot be clearly restricted by rules or thrown exceptions) in practice, but frequent misuse will result in poor performance

A significant time is expended in Diagnostic Data collection for various problem scenarios encountered by customers - in many situations leading to prolonged downtime of production systems. Gathering the right set of data in minimal number of iterations from a failing application scenario is a common challenge encountered by IBM Service teams as the data collection process is largely manual and error prone. The challenge is aggravated as several sets of data need to be collected for common problem scenarios and the lack of awareness amongst the IT teams on the same.

IBM Serviceability teams have addressed these challenges by automating the data collection process thereby reducing cycle times for problem resolution and improved turnaround times for problem resolution.

There are automated data collectors available for different IBM products as a part of the IBM Support Assistant framework. Some of them include Information Management Collectors, Rational Collectors, WebSphere Collectors and Lotus Collectors which provide an automated way of collecting product specific logs.

In this poster we introduce the Java Diagnostics Collector which gathers documentation and diagnostic data associated with Java Virtual Machine problems. It is started automatically when the Java Virtual Machine detects a problem and produces dumps. Some of the key features of Java Diagnostics collector are:

I have synchronized block. inside the block,calling a method which creates a pdf document. The problem is the thread which calls this method is waiting for a long time causing other threads to hung. how can i prevent this? Can i do some sort of timer so that if one thread is taking long time to return from the method,we can interrupt that thread and continue with other threads. Please give me a solution.

ORB aka object request broker, is the java implementation of the OMG's CORBA (Common Object Request Broker Architecture) specification, which enables the usage of remote objects usable like the local objects. It also lets objects communicate with each other independent of the platform and languages used to implement those objects.

The ORB is implemented as part of the java virtual machine and plays an integral part in the application server runtime environment. In the client/server communication, the ORB provides primarily the following functionality -1) Provide a framework for clients to locate the remote objects on the server and invoke requests on them.2) Manage the connections.3) Manage the request and response messages to/from the remote Java objects.4) Marshal/Demarshal, based on the CDR (Common Data Representation) , the messages sent over the wire.

Provide a framework for clients to locate the remote objects on the server and invoke requests

For a client to be able to successfully locate the remote object on the server, the remote object needs to be "registered to a naming registry" and "exported". The "bind" call will ensure that the remote object is registered to a naming registry and "javax.rmi.PortableRemoteObject.exportObject()" will ensure that the remote object is exported i.e. it is ready to be invoked. Once, the client does a look-up, "javax.rmi.PortableRemoteObject.narrow()" will have to be called on the reference returned by the look-up. The object returned by the "javax.rmi.PortableRemoteObject.narrow()" will be used to invoke the remote object.

Now lets look at what internally happens in the ORB when an javax.rmi.PortableRemoteObject.exportObject() -1) The tie and stub classes associated with the remote implementation are loaded.2) The tie class to the remote implementation class and tie class to the stub class are cached for future/faster look-up.

The "javax.rmi.PortableRemoteObject.narrow()" is fairly simple, it just checks whether the object returned by the look-up can be casted to the remote interface i.e. the object should extend javax.rmi.CORBA.Stub and implement the remote interface. The reference returned by the javax.rmi.PortableRemoteObject.narrow() will be used to invoke the remote function.

The stub and tie play a key role in the remote communication. The reference returned by the javax.rmi.PortableRemoteObject.narrow() is actually a stub. As the stub implements the "remote interface", the implemented remote functions will invoke the ORB to send the data to the server and receive the response from the server. At the server side, the data will be received by the ORB. The ORB will identify the corresponding tie and the tie will invoke the remote function implementation. Once the reply is received, the tie will pass the response data to the ORB and subsequently the data will sent to the stub at the client side.

In the next blog, we will explore how the ORB manages the connections.

Right from the beginning, I have been extremely fond of mathematics. Consequently, I planned to get into Mathematics, Physics and Chemistry (MPC) in intermediate (11th and 12th grades). However, I was discouraged to get into MPC because of my visual impairment and there was no provision for the college to support me with the lab work. Of course, I was disappointed and I decided to go to Commerce, Economics and Civics (CEC) since I believed that Economics would certainly have math in it.

I completed my bachelor's degree in Economics. Then, I looked for the management career in XLRI, IRMA and IIM. All three institutes claimed that they did not have a provision for a visually impaired dude! Then, I decided to go for master's degree in Economics from the University of Hyderabad. Later, I spent one year in ISI. Then, I secured my Ph.D. in Economics from the University of California at Davis.

I joined the University of Colorado at Denver as a faculty member and continued in that position for the next seven years. During my stint in the University of Colorado, I realized that everyone was making more money in the field of Information Technology than I was with my university job! I switched careers and went into computer sciences. For the last eleven years, I have been with this industry.

In conclusion, I did not really choose the path that I have been walking. In other words, I am not one of those heroes that you find in the writings of Ayn Rand! At the same time, I wholeheartedly tell you that I have no regrets at all.

Current Job Profile:

For the last one year, I have been with Java Technology Center (JTC). I have been working on Apache Open Source project called Harmony (the alternative class library). Once again, I am planning to head back to Research because of one more interesting opportunity with MIOP.

Q. What has your career journey been like? How did you get started?

A. To some extent, I answered this question in the introduction. In IT, I commenced my career with a bunch of E-Commerce projects. I used application servers like BroadVision and ATG Dynamo. Then, I joined SAP Labs. For the next five years, I worked on various aspects of NetWeaver. Roughly three years ago, I got into IBM Research.

Q. You were once an Economist, how challenging is the role of an IBM Researcher for you?

A. I did not face any problem in terms of research methodology but I did have challenges to develop a research agenda in the area of computers. While I was with research division, I focused on Service sciences, Software Engineering, Mobile Computing and Social Networks.

Q. How do you keep yourself updated on technologies? Are there any favorite websites, books, journals or blogs you follow?

A. I read lots of books. Currently, I am reading Domain-Driven Design. I strongly recommend it. I also follow the blogs. My favorite ones are DeveloperWorks, TechCrunch and Harvard Business Review.

Q. Is there anyone that you look up to and model yourself on?

A. It changes from time to time. Currently, my hero is Kent Beck.

Q. How do you find DeveloperWorks/My developerWorks useful?

A. For over six years, I have been working only in Java. In my view, there is no better source than DeveloperWorks. However, I am still a figuring out My DeveloperWorks.

Q. What is your advice to the future aspirants ?

A. Keep nurturing the love for technology. Money alone cannot make us happy.

Q. What motivates you?

A. The previous answer makes sense here too. I use Java to solve my day-to-day problems. For example, I downloaded a book called "Tips from the Trenches" today. The copyright stuff was there on every page. I was getting irritated. I wrote a simple Java program with a hint of regular expressions to clean it up. Coding is fun. I do not know how long it lasts but I have been enjoying coding for the last 25 years.