Philip Brittan's Blog

Jini Archives

Java vs. .NET, part 4 - Java is a language, .NET is not

Java takes a language-specific approach to solving problems, .NET takes a platform-specific one

One of the striking differences between Java and .NET is that Java is, fundamentally, a programming language and .NET is not. .NET is a framework that supports many languages. There has been a lot of identification of C# with .NET, but C# does not equal .NET, and you don’t need to use C# in order to build .NET applications. You can use one of the 20+ other programming languages currently supported by .NET. .NET’s view of the world is from the platform. It is designed from the ground up to leverage specific aspects of the Windows platform to its advantage.

Java, on the other hand, has a language-centric view of the world. Yes, with J2EE, Java has started to create a framework around itself, and extension technologies like Jini and JXTA certainly strengthen Java’s platform, but the way in which Java attacks problems is from a language point of view.

One immediate result of this difference is that it leaves Microsoft with the opportunity to surround Java with other languages. Not only does Microsoft already control the enormously popular Visual Basic and have the ability to make C# very popular, but it can appeal to companies that already have large code-bases in COBOL, C++, Smalltalk, Fortran, and other legacy languages. Java’s answer to those folks is: port your legacy apps to Java or use some kind of awkward connector bridge between the legacy code and Java. It is not natively tolerant of legacy code.

There have been attempts in the past to support other languages with the JVM. Eiffel can compile to Java bytecode. But those efforts have not gained any real support in the Java community. Bertrand Meyer, the creator of Eiffel, writes this in a paper describing his successful efforts to connect Eiffel to .NET:

This ability to mix languages offers great promise for the future of programming languages, as the practical advance of new language designs has been hindered by the library issue: Though you may have conceived the best language in the world, implemented an optimal compiler and provided brilliant tools, you still might not get the users you deserve because you can't match the wealth of reusable components that other languages are able to provide, merely because they've been around longer. Building bridges to these languages helps, but it's an endless effort if you have to do it separately for each one. In recent years, this library compatibility issue may have been the major impediment to the spread of new language ideas, regardless of their intrinsic value. Language interoperability can overturn this obstacle.
….
The language openness of .NET is a welcome relief after the years of incessant Java attempts at language hegemony. For far too long, the Sun camp has preached the One Language doctrine. The field of programming language design has a long, rich history, and there is no credible argument that the alpha and omega of programming, closing off any future evolution, was uttered in Silicon Valley in 1995. Microsoft's .NET breaks this lock.

Everyone will benefit, even the Java community: Now that there's competition again, new constructs are—surprise!—again being considered for Java; one hears noises, for example, about Sun finally introducing genericity sometime in the current millennium. Such are the virtues of openness and competition.

In summary, .NETs multi-language support is another threat to Java. Java needs to blunt this threat. Specifically:

• .NET will surround Java with alternative and legacy-compatible languages. The Java platform needs to become more language neutral while continuing to make Java the best language possible by dynamically incorporating new ideas such as Aspects and built-in support for Web Services.
  
  
• Java's language-specific solutions will isolate it. Make sure technologies mesh with no language assumptions (object layout, data types, calling conventions, runtime context, etc.)
  
  
• .NET as a platform has more hooks into the OS. Java needs to support desktop integration (icons, file linking), which is stuff that happens before any Java code gets run. This is client side, but it's all about what you can deliver end-to-end with Java application code.
  
  
• Deploying server-side J2EE applications is a bear. Java needs platform capabilities to make this much easier. The approach of offering wizards helps, but because they are glued on, they are brittle (hard to change after you’ve gone through the process once) and not compatible between different compilers.

(To be continued. And yes, I am about to offer some hope…)

Blackout

Single points of failure can be entire systems. Prevention may lie in "fencing in".

For those of you on the West Coast, I can assure you that it was pretty dark here in New York last Thursday evening. A little after 4pm, suddenly all our lights, air-conditioners, phones, etc., in our office shut down. The UPS alarms started ringing, letting us know we were operating on battery power. We soon realized that the power was going to take a long time to come back on, hours if not days, and we didn’t have enough battery life for that, so all we could do was execute an orderly shut down of our servers and wait.

The effects of a loss of power are devastating, especially in an overcrowded city. No light, no A/C, thousands of people trapped in subways and on commuter railways, no ventilation in roadway tunnels, no ATMs, no credit card processing, no cell towers to relay our phone calls, no phone systems in our offices, no answering machines, no PCs, no refrigeration, very limited cooking, etc. Life as we know it completely on hold. We are utterly dependent on electricity and the systems that deliver it to us.

The power system -- something I admittedly don’t know a lot about -- seems pretty well distributed. There are a multitude of power plants, operating independently but interconnected through a singular power grid. This grid is supposed to be able to handle changes in local supply and demand, routing extra energy to a hot region where too many people are cooling off in front of the A/C, and seamlessly covering for a downed plant.

But apparently, these independent plants are also susceptible to each other, through the grid. I read that 21 major power plants spread out over 9,000 square miles all shut down within 3 minutes of each other, as a defensive response to some type of surge in the grid, leaving roughly 50 million people without power. Although the grid is supposed to nicely handle failures at any particular power plant, which I assume it does all the time and of which I am thankfully oblivious, it apparently can be a single point of failure itself, leading to catastrophic shut-down of the entire system.

So how can we prevent systems from being single points of failure? The answer may lie in the concept of "fencing in" instead of "fencing out". In my home state of Montana, the law of the land is "fence out". That means that it is incumbent upon any ranch to keep his neighbors’ livestock out of his fields – he is not responsible for keeping his own livestock in. This mechanism dates from the time when most of Montana was open range land, and the occasional farms were responsible for keeping that free-range livestock out of their fields. In this day, when all the land has been claimed and cut up into contiguous ranches, this "fence out" rule seems a little anachronistic, but it remains the rule.

I think that that same rule is used in numerous distributed systems. In our recent blackout, each power station acted entirely in its own self-interest and shut down to protect itself from the surge running across the grid, i.e. they each fenced the menace out. If instead, there were cooperation across the grid to isolate the surge, i.e. fence it in, then catastrophic system failure could have been avoided.

Currently viruses are handled by “fence out” methodology. Every individual system attempts to fence viruses out leaving the viruses free to run around the network looking for just one system that fails to fence them out so that they can propagate. If they were fenced in, they would not have the ability to look for a weak node to attack.

The only way to fence viruses in is to make sure that they have no medium for transmission. As we move towards a model of “utility computing” in which compute resources are served up like electricity from a distributed grid, the risks of a systemic failure become greater. However, since servers tend to operate in strictly managed environments, it should be easier to isolate destructive code (viruses and bugs) and its effects. And by connecting to desktop environments without sending executable content to them, we can make sure that destructive code never gets to leave that rigorously managed server grid. Mark Williamson at HP in the UK has been experimenting with using innovative "fence in" techniques to combat viruses.

It is consistent with game theory that the benefit of the whole is maximized by each constituent pursuing their own self-interest and cooperating to pursue the interest of the group. That is what fencing in requires.

This work is licensed under a Creative Commons License.