.NET vs Java

     Deciding which architecture to use for software systems can be a daunting task. Organizations put less thought into the features and attributes of  a particular framework than the associated costs of that decision. Many choose Java over .NET simply because of lower initial costs but lose sight of the total lifecycle cost of the system throughout the development life cycle. Other organizations pick a particular technology because they feel it is a better fit with their current state. Both of these drivers may be inadequate in identifying the best architectural solution. in fact, many large organizations are realizing that selecting one or the other is not always the best strategy. As market conditions continue to change and information system complexities grow, the need for diversified problem solving tools may outweigh any benefit obtained from a unified framework.

Libraries

     When comparing any architectural framework, it is essential to identify what makes each one suitable for a particular purpose. Java has a considerable developer following and market share in enterprise development. Because of these two facts, the availability of open source libraries on the Java framework are astounding. These libraries include the SWT (Standard Widget Toolkit), JAI (JavaAdvanced Imaging), and JSF (Java Server Faces). There are literally thousands of open source libraries that developers can use to speed application development. This adds a considerable amount of appeal to the framework.

     The .NET framework also has some open source support and has many libraries to aid in development. Because the .NET framework is younger than Java, and due to Microsoft's insistence on maintaining the frameworks copyright, the open source offerings have not developed at the pace of Java. This is partly due to market share as well. Not to say that .NET is less capable than Java. In fact, .NET is used in far more web applications than Java due to the ASP.NET ease of use, seamless integration with web-based technologies, and support for many different programming languages including Java. In addition to web-based applications, .NET has  extensible and user friendly UI development features.

Developer Availability

     When choosing a framework technology it makes sense to quantify the availability of developers with skills and experience in that technology. Organization wants to choose an architecture that puts them in a position where skilled developers are abundant.

     Java developers are typically in higher demand. This is due, at least in part, to Java's market share. At the time of this writing, a search on careerbuilder.com resulted in 9,228 posting nationwide for Java related positions. It is difficult to determine from this if the demand for developers outpaces availability. The bureau of labor statistics predicts a 3 percent decrease in software developer demand by 2018, though demand for software engineers increases.

     A similar search on careerbuilder.com for .NET related position produced only 4,354 postings nationwide. This fairly accurately reflects the market share ratio of Java to .NET. Of course, it is impossible to determine actual developer availability from this data. Each technology has a strong following and finding skilled developers should not be a major concern in either case.

Competencies

  

     Above all else, the most important deciding factor for an architecture is capability. Does it provide the tools required to solve a given problem. As stated earlier, each technology has a wide variety of libraries available. More than any one developer could ever learn in his or her career.  Java has many more open source libraries; however, not all those libraries are created equal. Many are very old and no longer maintained. Others are poorly written from the start. The same classifications apply to the .NET libraries. Needless to say, choosing the right libraries is equally complex. Due to Java market share and open source community there are more unofficial support channels through forums, professional organizations, and blogs. Furthermore, Java runs on every machine that supports the JVM (Java Virtual Machine).

     The .NET framework has an adequate open source community that grows every day. It is also worth noting that .NET is often considered easier to learn for new developers and simplifies RAD (Rapid Application Development). The latter is a major driving factor for the switch by many organizations to .NET for enterprise systems. Start-ups tend to prefer open source technologies  due to its relatively low initial cost. Anything built with .NET requires the Microsoft Windows OS and the .NET framework; however new open source initiatives like mono are making developing and running .NET a reality on other platforms.

Cost

     Java beats .NET hand down when comparing Initial investment. It would be incredibly short sighted to base the entire decision on this. System architecture complexities have significant impact on all future projects. As the organization and information system needs grow the individual strengths and weaknesses of the underlying architecture become more apparent.

     Java's open architecture provide a very low initial cost. This is primarily why start-ups often opt for open source architectures. The use of open source technologies like java and PHP reduce software licensing investment to almost zero. It enables them to build and run application on machines running open source operating systems which further reduces  the need for start-up capital.

     Technologies based on .NET typically require a Windows OS based workstation for development and a Windows Server for web applications. Windows server installations can reach $4,000. Development tools like Visual Studio run in the $1,000-$3,000 range.

     All of these factors tend to put .NET at a disadvantage but organizations must consider the total lifecycle cost of a solution. According to the Free Republic, the average yearly salary of a Java developer is $10,000 higher. That would easily offset any initial gain outlined above.  

Longevity

     Any discussion about system architecture and technology would be incomplete without calling into question its longevity. In these two cases it may be unnecessary due to their obvious appeal and current market share. Unfortunately, or fortunately, technologies do change so a little healthy skepticism may be in order.

     Java has been in play for over 15 years and has gained an incredible following in that time. Java has perhaps billions of installations from mainframes to access cards. It has proven itself over and over again as a versatile, robust, and reliable framework. Part of that success is owed to Sun Microsystems Inc. vision in making the technology open. This fostered the innovation and adoption that made Java a success. Java's continued success is fueled by this momentum but continued marked dominance is being challenged by .NET and Oracles wavering support of Java's openness.

     Microsoft's .NET Technologies have never been and never will be open. This and other factors have prompted many analysts to give the technology a ten count over the last few years. That has certainly not stopped the frameworks steady, if not modest gains. The fact that many organizations are starting to identify .NET as the framework of choice for large enterprise systems is interesting. More than that, many large organizations are coming to the conclusion that one architecture or framework just is not enough. Maybe that should be the lesson here. Architecture choice is more about capabilities than nickels and dimes or perhaps ego.

     As an organization, or more specifically an agent for an organization, one may have to face the complexities of this decision with a very open mind. It may be impossible to identify one technology that fits every case perfectly. When initial cost, total costs, resource considerations, capabilities, and stability are all factored in the choice may be clear. In reality though, this may be much more of a guessing game for most. Organizational goals, IT strategies, business models, and current state all have a role in choosing appropriate technologies. 

C++ Mixed Mode Programming

As a laboratory automation specialist I often encounter projects that deviate from what most people would call standard software development. Some of the systems I contribute on are custom made from the material handling  hardware to the control systems, and especially the software. In fact, my colleagues and I spend a great deal of time overcoming some very complex problems integrating the hardware systems with software control systems. I recently had the opportunity to work on a project that required the use of a .NET assembly designed to drive a Programmable Logic Controller. This would normally be very straight forward; however, due to the systems performance requirements the control software had been designed in native C++. This left only a few possible solutions for integrating the .NET assembly.

Obviously, There are several ways to call managed code from native C++ via interop methods such as Platform Invoke or COM. The real issue with these methods is the inherent complexities with memory management on the managed code. One of the main issues involves memory management on the heap due to the CLR automatic garbage collection. Objects on the CLR heap do not maintain the same memory address throughout their entire lifetime. In these instances, the use of interior and pinning pointers are used to either relocate the pointer in the prior or prevent the relocation of the object at run time.

Another method of C++/CLI interop is to create a mixed mode application that blends managed and unmanaged C++ without the use of a COM wrapper or PInvoke. This requires no changes to the native code  but will require significant changes to the compiler directives (a search on google will provide the basic project template). In my case this is the method that was used to integrate the .NET assembly into the native application. I chose this method primarily due to my own particular needs for this project. The assembly was only needed in one function that read some inputs and manipulated some outputs based on that read. In this case the fact that the object would only have function scope did not present a significant design challenge. In fact, the only major hurdle was Microsoft Visual Studios crippled C++ CLR intellisense, but that is another story altogether.

In all interop methods there was significant data conversion considerations. The native C++ and managed C++ worlds have significant departure in most of the non-intrinsic types. Managed Strings are specifically vulnerable to problems due to the CLR's handling of string literals. The real issue is that managing pinning pointers and interior pointers will quickly become tiresome in my opinion. So unless you need a global reference to a managed class, this method may not be worth the extra work. I am interested in hearing other stories of C++ interop and how each was handled. Please comment with your experiences.