Cutting Edge Computing

How Do You Marry Java and .NET? April 13, 2012

Years ago, I did some work for Mainsoft, which had a technically cool way of running .NET code on Java application servers.  This involved dynamically cross-compiling .NET into Java.  The idea was that you could create your application (typically a web application) using Visual Studio, then with a minimum of effort, configure it to run on a JVM and application server.

I would provide a link for Mainsoft, except that the company has changed names and markets (www.harmon.ie).  Apparently it wasn’t a good enough idea for a company to make money from.  Part of the problem was that there were two paths to getting .NET to run on Java – you either did byte code translation, or your implemented some or all of the .NET Common Language Runtime in Java.  Mainsoft did mostly the first, but also found that it was easier to use Mono classes for a lot of the CLR.

But now there seems to be a way to do it in the opposite direction; that is, running a Java application in .NET.

Mainsoft’s strategy was easily comprehendible but rather niche – developers were experienced in .NET and wanted to use the best .NET development tools possible, but the enterprise wanted flexibility in deployment.

IKVM, an open source project, uses some of the Mono classes to enable Java code to run on .NET.  It also includes a .NET implementation of some Java classes.  I’m not sure why Mono is needed in this case (and in fact, it’s likely that the Mono project has largely run its course).  IKVM lists three components to the project:

• A Java Virtual Machine implemented in .NET

• A .NET implementation of the Java class libraries

• Tools that enable Java and .NET interoperability

Microsoft was promoting IKVM during its language conference, obviously as an existence proof for the concept that there may be people who are interested in porting from Java to .NET in this manner.

Still, as a practical matter, it doesn’t seem worthwhile doing.  There are plenty of JVMs for Windows (I realize that .NET is a subset of Windows, but as a practical matter is pretty well tied to it).  The distinction of running on .NET is one that most won’t bother to make.  Perhaps someone out there can offer an explanation.

In Memory of Dennis Ritchie October 14, 2011

I woke up this morning to the news of the passing of Dennis Ritchie, computer science researcher at AT&T Bell Labs and inventor of the C programming language (he actually passed away last weekend).  The C Programming Language, a language manual by Brian Kernighan and Dennis Ritchie, was the bible for several generations of professional programmers.

The early 1970s saw the rise of multiprocessing, where multiple users shared the same computer in a timesharing arrangement.  The research state of the art at that time was MULTICS, an MIT research project.  Bell Labs took those concepts and Ken Thompson developed the Unix operating system (with Ritchie’s assistance).  Ritchie then designed the C language as a high-level language married closely to Unix and its underlying API and commands.

However, C was also created as a platform-independent language, a nod to the fact that Unix would eventually be ported to dozens (probably more like hundreds) of different processors and hardware architectures.  For example, it lacks a string library, because strings are implemented differently on different OSs.  So C programmers got used to doing an array of char to represent a string (third parties eventually came out with custom string libraries for different computers).

C has elements of both a high-level language and a systems programming language.  It had high-level constructs, but could also directly access memory locations through pointers.  It does no automatic allocation or deallocation of memory; malloc and free are among the first constructs learned by aspiring C programmers.  Further, C does essentially no type-checking; programmers could essentially copy data from one type to another, irrespective of the type size, at their own risk.

Functions are generally called by reference, by establishing the memory location of the function (called a pointer), and are called by referring the calling function to that location (called dereferencing the pointer).  This can make possible some extremely convoluted programming constructs.

These characteristics and others made C extremely flexible, but also extremely prone to programming errors.  When I was the BoundsChecker product manager at Compuware NuMega Labs, we determined that a large majority of C (and its object-oriented extension C++) programming errors were memory errors.  It is simply too complex for most C/C++ developers to fully understand and control how they are using memory.

C programs eventually became so unmanageable that many development teams now use managed languages such as Java or C#.  Both languages (as well as niche languages like Lisp and Smalltalk) automatically allocate memory when you define and use a variable, and reclaim that memory when there are no longer any links to it through a technique called garbage collection.  But many commercial applications still use C/C++, either for legacy or performance reasons.

I was a C programmer for a brief period of my career, and occasionally taught C++ as an academic.  During my time as an academic, I wrote a discrete event simulation application in Pascal (invented by Swiss computer scientist Nicolas Wirth), a similar language that provided much stricter type checking.  Despite the popularity (and to large extent necessity) of managed languages today, I still firmly believe that you can’t truly understand how to program a computer unless you have a clear picture of how your code is using memory.  And we owe that view of memory to Dennis Ritchie and C.

Are Domain-Specific Languages the Next Software Engineering Breakthrough? November 11, 2010

Almost since people have been writing software, we’ve looked for better, more efficient, and more intuitive ways of doing it.  First-generation languages (machine code) gave way to second-generation languages (assembly), which was largely abandoned in favor of third-generation languages that are in mainstream use today.  Starting with the likes of Fortran and Cobol in the late 1950s, we now use C# and Java, plus a number of other less mainstream but still-important third-generation languages.

That’s not to say that we haven’t tried growing beyond the third generation.  For a while in the 1990s, fourth-generation languages like PowerBuilder and Progress attempted to make data access more intuitive.  Also in the 1980s, Japanese industry and academia embarked upon a far-reaching but poorly-understood Fifth-Generation Computing project that didn’t have any wide-ranging impact on software development.

And C# and Java represent a significant advance over the likes of C++ and Ada in that they are managed languages.  Rather than requiring the programmer to manually write code to allocate and deallocate computer memory, the underlying language platform does it automatically.

But at a conceptual level there’s little else fundamentally different between Fortran and C#.  To be clear, there is much that is different, but the language instructions themselves haven’t changed a whole lot.  While we have libraries and frameworks that enable us to abstract a bit more today (and doing so may create more problems), we are writing code as the same conceptual level that we did fifty years ago.

The buzz in the industry over the last several years has surrounded so-called domain-specific languages, or DSLs.  I’m reminded of this by this article on former Microsoft executive Charles Simonyi, who has since founded a company to create a foundation for implementing DSLs.  I’ve also participated in several conferences over the last couple of years where speakers have promoted DSL concepts.

DSLs are an attractive concept for a number of reasons.  Because they focus on a specific problem domain, they tend to be fairly simple.  Domain experts, rather than programmers, may be willing to adopt them because they abstract a programming problem into terms that they understand, and can build solutions for.

I really like the idea, but I’m doubtful in practice.  Fifteen-plus years ago as an academic, I actually wrote a DSL, a visual language for discrete event simulation.  I loved it, but even those interested in discrete event modeling were flummoxed at some of the things I did.  And these were people who were used to thinking in those terms.  Languages meant for specific types of problems have to be designed very carefully (I probably didn’t do that) just in order to appear on the radar.

And I think we’ve debunked the concept of the citizen programmer.  I’ve seen a lot of products intended to bring programming to the user come and go over the last twenty years.  Microsoft’s original Visual Basic was intended to do just that, but it was successful only because it was useful to professional programmers.  While a few domain experts adopted 4GLs and became programmers (I saw that while working at Progress Software), it’s very much an exception.

We prize programming languages in large part for their versatility, not their simplicity or their utility for a specific purpose.  DSLs aren’t flexible.  Even in a problem domain, you want the ability to draw in instructions and tools from other domains, and from a large toolkit in general.  Unless we rethink the fundamental concepts behind DSLs, this will be the next breakthrough that never was.

Patent Fight Over Java Likely Means No Winners September 1, 2010

One of the commenters in my previous post noted that the lawsuit filed by Oracle against Google was a patent fight, not a license fight.  It apparently involves a clean room VM developed by Google that allegedly violates one or more of the existing patents Sun was originally awarded on Java.  It is possible to violate a patent, in effect copy a protected invention, even though the logic behind that invention is distributed via an open source license.

I’ve written a lot about software patents in the past.  I’ll say two things regarding them today.  First, software patents are never as cut and dried as they may appear at first glance, and predicting the outcome is virtually impossible.  I don’t know who’s right here, but being in the right isn’t necessarily indicative of who will win the suit.  A duplicate of the invention itself isn’t typically sufficient; the steps in creating the invention matter just as much.

Prior art may come into play in Google’s favor.  Java certainly wasn’t the first managed platform; Smalltalk and Lisp immediately come to mind as predating it.  There were also other clean room Java VMs.  A company called New Monics, started by Kelvin Nilsen, did fundamental and applied research into garbage collection, and came out with products supporting a hard real time Java for embedded use (New Monics was acquired by Aonix several years ago, and PERC still seems to be alive).

Second, if this were two ordinary software companies, I would say that the suit would be settled by a cross-licensing of each others’ patent portfolios.  Today, tech companies accumulate patents as a defense mechanism, in case of a lawsuit.  It is often possible for the defending company to coutersue, identifying technologies from the plantiff that may infringe on its patents.  This often ends in a settlement where little if any money changes hands, and both companies continue as they did before.

(Incidentally, since patent trolls don’t make products, this defense won’t work with them.)

However, I suspect that larger issues are at work here that are likely to preclude an amicable settlement.

Last, in Oracle’s favor is that in engineering practice, clean room design is difficult to prove.  Companies engaged in clean room design often require that engineers have no prior knowledge of the technology, so that they can plausably argue that any similar design approaches are an accident rather than intentional.  In the case of Java, I might doubt that it’s possible to hire such engineers who can still produce the VM.

The loser of this patent fight remains all of us.  However this may turn out, it will cause uncertainty as to just what we can do with Java, and how we can do it.  For the vast majority of companies building custom applications for internal use, it doesn’t matter directly.  But it’s likely that they’ll have to pay extra attention to the tools and frameworks they use, as it may not be clear what is patented, and by who.