CXO

Hear how Mainsoft is opening options for .NET and Java developers

In this Q&A, Mainsoft's Vice President of Technology, Eyal Eliahu Alaluf, discusses a variety of subjects, including: managing a team on different continents; working with .NET code within the Java Virtual Machine; and analyzing the differences between the two platforms that his company is seeing.
Eyal AlallufMainsoft provides tools for running .NET code on the Java platform. I interviewed Mainsoft's Vice President of Technology, Eyal Eliahu Alaluf, via e-mail about a variety of subjects, including: managing a team on different continents (Mainsoft has offices in the United States and Israel); working with .NET code within the Java Virtual Machine (JVM); and analyzing the differences between the two platforms that his company is seeing. Here's what he had to say. What got you interested in programming, and how did you get your start?

I started programming in the early 80s when I was about 11-years-old. I thought of programming as a hobby — a kind of game that allowed me to track our local soccer teams and calculate player statistics using simple building blocks. I also programmed music since there weren't any music programs available to me 30 years ago on my Commodore 64.

In college, I pursued programming because I was good at it, and I could actually build a career out of it. So I studied for my B.Sc. degree in Mathematics and Computer Science at the Hebrew University in Jerusalem, and I have been in the field ever since.

What kind of advice would you give an entry-level programmer who is aiming to become a C-level executive, as opposed to someone who is staying on a pure development career path?

Actually, I am still on a pure development career path.

My experience is that you become a C-level executive by leading by example. When an important issue is escalated to you, get involved in understanding the issue, contribute your own analysis, and demonstrate how to resolve it when delegating the project to someone else. Too often, I have seen managers refrain from understanding the nitty-gritty details of an issue they are responsible for solving. This hands-off approach inevitably leads to a rigid and inflexible management style that is simply not suited for such a dynamic software industry.

What are some of the challenges in working with a team on two continents?

When we established Mainsoft in 1993, the R&D center was located in San Jose, CA. The arrangement worked well until the late 90s, when more and more engineers jumped ship in favor of dot coms offering generous stock options; that's when we made the decision to transition certain aspects of the R&D process to Israel. By 2001, we decided to relocate all aspects of product R&D — from design and development to QA planning and testing — to Israel.

Our model today is to share product strategy equally between the Israeli product engineers and the U.S. business team and field engineers. We want to be sure customer requirements and market requirements receive as much weight as addressing product limitations as we develop our software.

If everyone were in the same office, it would be much easier to overcome the Israeli team's lack of exposure to customers and their engineering requirements. As it stands, we have to be very deliberate about integrating the U.S. business teams' and field engineers' customer experiences into product development and to ensure all product development is relevant to the market.

What kinds of tools do you use to address this challenge?

We use simple, everyday technologies, like the telephone, e-mails, and Web conferences, and we encourage travel. We also invite our customer-facing U.S. engineering team to Israel once a year to work side-by-side with the development and support engineers. We are more effective because the U.S. engineers better understand what the products can and cannot do, and [they] learn first hand what it takes to address customer issues remotely. We also send Israeli engineers to interface directly with customers [so they can] better understand their business needs and real-world applications.

Mainsoft specializes in Java/.NET interoperability. How do you address the Window-specific portions of the .NET Framework when porting .NET code to a *Nix platform? Or is the interoperability purely at the language and core library level?

The Mono open source .NET Framework is actually quite extensive. We focus on Web services, ASP.NET, ADO.NET, and other server-related technologies on Java. So the Framework goes way beyond the language and core library level, and it's a solid foundation for developing and porting applications.

In our experience, when customers port a server application, only a small portion of the application will depend on technologies we do not support. When targeting the Java platform, the full Java framework is callable from Visual C# or Visual Basic code, so there's always the choice of either using supported .NET classes and methods, or using the Java framework. To help customers build the application successfully, we provide support through our developer forums, as well as offer professional services.

What kinds of programmers are typically interested in these types of products, and for what reasons?

.NET programmers typically look to Mainsoft whenever their company needs to offer their C# or VB application on Java. This could be as a result of a business merger, an initiative to consolidate servers, or a project to integrate .NET applications and Java applications within an enterprise portal like WebSphere Portal. These programmers are typically experts both in .NET development and their business domain. They understand that their .NET expertise is key to accomplishing their objectives and that investing the time and energy in becoming experts in Java would defocus them from their mission, and cost them in terms of time-to-deployment.

Developers that use Mainsoft for Java EE products program for Java EE using their .NET expertise, without compromising the end result, either in terms of quality or time-to-market.

Given the similarities between C# and Java, and that much of the .NET Framework is clearly influenced by the Java APIs, is there substantial value in running C# on a Java platform, as opposed to writing Java code for that platform?

C# and Java come from a similar place, but the two languages are evolving in different directions and at different rates. C# Generics and now LINQ have no real equivalent in Java. And ADO.NET (e.g., DataSet) and ASP.NET (e.g., master pages, user controls) provide productivity features that are quite advanced compared to what is provided by Java frameworks. We believe that these development features make a significant difference when it comes to speeding time-to-deployment, and that a developer proficient in using these tools can quickly become productive in a Java EE environment using Mainsoft products.

Sun and Microsoft both employ thousands of brilliant programmers to work on the JVM and the .NET CLR, respectively. In the paper you wrote about the .NET CLR and the JVM, it was quite clear that the .NET CLR was substantially faster than the JVM, at least for those types of operations. Any idea why that might be? (Note: This is in reference to a paper that Alaluf wrote and sent to me about comparing the speed of the .NET CLR and the JVM performing these operations.)

The Java implementation converts integers to strings much faster than the .NET CLR. With real numbers, .NET CLR is much faster. This is because .NET CLR uses native code vs. Java's managed implementation.

When we set out to optimize the conversion of strings to numbers and vice versa, we didn't know that we would provide better performance than .NET CLR for real numbers using a managed algorithm. Only when we implemented the algorithm did we realize it can outperform .NET CLR's unmanaged algorithm. To me, it's decisive proof that even in such low-level tasks, a managed implementation can compete strongly with a native, unmanaged implementation.

Given the deep level work that Mainsoft has done with both the .NET CLR and the JVM, what insights do you have into the particular strengths and weaknesses of those two platforms?

We can clearly see differences in philosophy between them. The JVM is designed with implementation simplicity and minimalism as a goal, while .NET CLR is richer and more sophisticated. For example, .NET CLR has feature-rich support for integration with native existing applications, and it's designed for a programmer's ease-of-use.

In contrast, the JVM JNI support is clearly designed for simplicity of implementation and not for ease-of-use. The .NET CLR pays the price in terms of the complexity of the garbage collector, in this case because it needs to support unmanaged pointers that do not even exist in Java.

Because it is not committed to minimalism, .NET is moving much faster in terms of language innovations than Java. Microsoft is following a clear path of integrating appealing features from other languages into C# and VB in a natural, comprehensive, and intuitive way. On the other hand, we see the JVM, because of its focus on simplicity, progress more rapidly in terms of performance. Java 1.4 was good, Java 5.0 had excellent performance, and Java 6.0 is even better. Sun continues to invest in quality and performance, and we can see the difference in our benchmarks.

Any plans to allow Java code to be ported to the .NET CLR?

Actually, there is already an open source tool that does just that, called IKVM.NET. It is an excellent tool that we recommend and use ourselves as part of our own development process.

How do you plan to handle the advanced features in .NET 3.x, such as lexical closure (lambdas) and their associate, LINQ?

We are actually in the advanced stages of implementing LINQ, and we plan to offer a 3.x preview, which includes LINQ support, this summer. Support for lexical closure comes naturally for us since our core technology cross compiles the Microsoft Intermediate Language (MSIL) to Java bytecode, while lexical closures are implemented by the Microsoft C#/VB compiler. So we are currently focusing on the runtime APIs that are behind LINQ.

The benefits to .NET developers from the Mainsoft offerings are pretty evident; they get a clear path towards enlarging their potential market. But imagine that you are a run-of- the-mill Java programmer: Why would it be beneficial to you to have .NET code running in or around your application?

Java developers like tight interoperability with .NET applications, and the ability to reuse existing assets. Practically speaking, every large IT organization has both .NET and Java developers. Without Mainsoft, the walls separating them are very tall and wide. These walls inhibit the creative freedom of developers and managers. With Mainsoft, your options are wide open. Java developers have easy access to class libraries developed by their .NET developer colleagues. And Java developers can give Java class libraries to .NET colleagues. So existing code can be reused for new purposes and new platforms. Together, Java and .NET developers can form a team that can effectively handle the dynamic software challenges of the organization.

Eyal Eliahu Alaluf is Mainsoft's Vice President of Technology, a position he has held since January 2000. With more than 15 years of experience in the industry, Alaluf oversees the development team behind Mainsoft's cross-platform product suite. Since joining Mainsoft in 1994 as the company's first Senior Developer, he has risen steadily through the ranks. Alaluf became the company's Chief Engineer before his promotion to his current position.

Related TechRepublic resources

About

Justin James is the Lead Architect for Conigent.

Editor's Picks