java.sun.com (JSC): When I spoke with Java EE expert Adam Bien about GlassFish, he praised its portability, scalability, documentation, diagnostic capabilities, and more. As one who works under the hood with GlassFish, how do you respond? Sahoo: Regarding the enterprise use of GlassFish, a couple of features immediately come to my mind: JMS provider plugability via genericJMSRA (Generic Resource Adapter for JMS) and enterprise application integration using Java EE service engine. For developers, we have a tool called verifier that can help identify many types of portability problems in Java EE applications. This tool will be very useful when profiles are available in Java EE 6. JSC: What major misconceptions do you encounter about the GlassFish application server? Sahoo: In the early days of GlassFish, people used to think we were just the reference implementation and lacked enterprise features. It took some effort to generate the awareness that GlassFish has the features needed in complex, demanding production environments. Important News About GlassFish
JSC: What's the most important recent news about GlassFish? Sahoo: The GlassFish team has decided to use OSGi in order to provide a modular, extensible, and embeddable application server. This is the theme for GlassFish, version 3.
JSC: Tell us how GlassFish v3 differs from version 2. Sahoo: GlassFish v2 is a complete Java EE stack. Various elements of the stack made assumptions about other elements of the stack, making it difficult to replace part of the stack or to remove some unused elements from the stack. Although we had an add-ons mechanism to add extra services, and we had implemented on-demand startup of services, the implementation team did not have the luxury to make the wholesale change that was required to fully implement those features. In GlassFish v3, we are removing that barrier. We are implementing an OSGi-based microkernel architecture. GlassFish v3 will be delivered as a set of OSGi bundles along with Felix, an open-source OSGi framework. Users are free to choose their own OSGi framework as well. By modularizing GlassFish using OSGi, we will have the option of composing the stack differently to cater to the needs of different classes of applications. It will be a lot easier for our partners to add extra modules in GlassFish to suit the needs of their users. GlassFish will be far more efficient when it comes to using system resources, as only modules used by an application will be loaded. Life-cycle management of GlassFish will be a lot easier, making it a candidate to be embedded in other applications. We are strongly committed to achieving all of this while maintaining backward compatibility. JSC: What can we anticipate regarding GlassFish in the coming year? Sahoo: In the coming year, you will see GlassFish implementing the Java EE 6 specification. We already have a Telco extension being developed in our sister project, SailFin. We are making GlassFish available to non-Java programmers such as JRuby and Groovy users. We will be exploring deployment of priority-aware complex event-processing applications in GlassFish. This may require us to take a look at Real-Time Java in GlassFish. NetBeans IDE Integration With GlassFish
JSC: Provide us with some insight into the integration of the NetBeans integrated development environment (IDE) with GlassFish. Sahoo: In the early days of Java, little emphasis was placed on IDEs, which I think was a huge mistake. The success of a runtime platform depends on adoption, and that can't happen without providing necessary tools to developers. The GlassFish community understands this very well. Having major contributions to both open-source projects from Sun allows us to have good synergy with NetBeans. Every time we have a major release of GlassFish, it is aligned with a NetBeans release so that developers can use the features seamlessly. When we think of a feature in GlassFish, we engage with the tools team to see how to expose it to our application developers. Take a look at the WSIT module in NetBeans, which exposes cool features of Metro, our web services stack. By the way, we are not limiting ourselves to NetBeans. We have plug-ins for other popular IDEs that developers should check out. A Portability Checking Tool for Java EE Applications
JSC: You are writing a portability checking tool for Java EE applications. Tell us about that. Sahoo: Traditionally, program portability results from well-defined language rules being enforced by compilers. The situation is a bit different in Java EE, which is a collection of frameworks and libraries. There is no such thing as a Java EE compiler, and the rules are not as well defined as the grammar of a language. A lot of the Java EE applications out there are nonportable. If Java EE 6 is going to define multiple profiles of the platform, this will become an even more serious problem. Their nonportability is primarily caused by two things -- the use of proprietary APIs and incorrect use of Java EE facilities. So we're working on a tool that identifies these issues and warns users much earlier in the development cycle. Developing in an Open-Source Community
JSC: How does working as part of an open-source community with GlassFish differ from working with software that is not open source? What adjustments have you had to make? Sahoo: One significant difference is the early feedback that we get from our users who track the developments very closely and tell us what changes they want before the release is made. You can think of it as a continuous beta. We can do a lot more experimentation in the code base and get feedback from the community before deciding whether or not to include a feature in the final release. The direct communication channel between engineers and users means there is less chance of mistakes in understanding user requirements. When it comes to adjusting my working style, if I had to single out one change, it would be having engineering discussions in the public mailing list. Earlier, a lot of these discussions took place in teleconferences, but that doesn't work very well in open source, where the committers are all spread out and there is no one good time that works for all. Secondly, to get the real benefits of open source, we not only have to write code, we now have to constantly talk about the changes we are committing and encourage users to try them out and give us feedback. Advice, Fun, and Influences
JSC: Do you have any advice for someone starting out as a Java programmer? Sahoo: Focus on basics; learn programming first. Java is simply a language to express your ideas. JSC: What is the Java class that you couldn't live without? Sahoo: JSC: Is there an intellectual discipline or fun activity that you feel makes you a better developer? Sahoo: I like to understand what's going on behind the scenes. For example, a C++ programmer doesn't need to understand how a virtual function table is laid out in C++, but knowing this is fun. I highly recommend Inside the C++ Object Model by Stanley Lippman for interested readers. JSC: What recent changes to the platform have made your life easier? Sahoo: Generics and annotations. Without generics, it was necessary to write a lot of "cast" expressions in code. To a large extent, generics makes this unnecessary, which leads to type-safe code. In the absence of annotations, especially in the enterprise Java world where there's a lot of metadata associated with the code, XML files were heavily used to store the metadata. Such XML files are typically known as deployment descriptors. While it makes perfect sense to store metadata that's typically dependent on the deployment environment in an external file such as a deployment-descriptor file, it hardly makes sense to use an additional file to maintain information that's supposed to be in sync with source code. Annotations make it easy to maintain such metadata in the source code/class file. This has been extremely helpful to enterprise Java users in developing applications using EJB 3 or JPA who use such a facility. JSC: What do you enjoy most about programming? Sahoo: It is very easy to experiment with an idea, unlike in other engineering disciplines. JSC: Where in the process of programming do you have the most fun? Sahoo: Debugging. JSC: Renowned Java bug fixer Brian Harry says that bug fixing is "a great way to understand how the code works." He says, "Reading the code is fine, but working with it is better. Even if you don't find a solution, you'll learn and become a more powerful developer." Do you agree? Sahoo: I can't agree more. Working with existing code gives an insight into how the developers thought about the problem domain. JSC: What is your favorite programming book? Sahoo: When it comes to overall programming books, I love The C++ Programming Language, by Bjarne Stroustrup. For that matter, Bjarne Stroustrup is my favorite author. Next is Design Patterns: Elements of Reusable Object-Oriented Software, by Gang of Four. JSC: Can you name some things you wish you'd learned in engineering school? Sahoo: I wish I had more formal education in mathematics. Mathematics is the language of patterns. I always feel that mathematicians see things differently. They try to come up with the right abstractions. That's such an important skill to have to write better code. JSC: What is the most counterintuitive observation or comment you can make about Java technology? Sahoo: I definitely miss the lack of destruction of automatic variables in Java. In C++, if I had to execute some code, for example, acquiring and releasing a lock, at the boundary of a scope, I could use constructor-destructor pair to encapsulate that logic and apply it wherever needed uniformly. In Java, I have to write that in every place using Secondly, it is not that simple to write Java applications that don't leak memory. JSC: Who has influenced you most in your career? Sahoo: While I have learned a lot from my past colleagues and am continuously learning from present ones, if I had to single out one particular individual, then that has to be Dr. Pinaki Poddar. He has been a great friend, philosopher, and guide over the last decade. Dr. Poddar is a former member of the Spoken Language Processing Group of Tata Institute of Fundamental Research, a premier institute in India for advanced research in the field of science. He has been a role model ever since I met him. JSC: What do you like most about your work? Sahoo: Interaction with my colleagues and the knowledge I gain from that. JSC: You work from Sun's development center in Bangalore. What is it like working so far from the core GlassFish development team? Sahoo: The core development of GlassFish does not occur only in the U.S. Major contributions are made from our group in Bangalore and from other non-U.S. centers as well. Open source further reduces the communications gap between various teams because we all make active efforts to communicate through email, as opposed to in-office discussions. See Also
Sahoo's Blog
| ||||||||||||||||||||||||||
 | |
| ||||||||||||
Print-friendly Version
Bio: I am an engineer at Sun Microsystems, working in the 
