Language Neutrality and the Java Platform

May 25, 2002 - Nik Boyd

A Somewhat Belated Response to the Assessment by Roger Sessions

Through web links, I recently found the ObjectWatch Newsletter from Roger Sessions dated June 5, 2001, which includes an article titled: Is Java Language Neutral? This article raised several questions for me, including the following. What constitutes language neutrality? What criteria should we use to judge the neutrality of a platform? Does it necessarily include complete language interoperability, or merely the ability to develop and integrate components written in multiple programming languages? Even if certain kinds of language interoperability can be achieved, what benefits does such interoperability confer? What are the natural limits of such interoperability?

I will dispute (or at least quibble with) several points made in the ObjectWatch article. While I think it's fairly obvious that the Java platform was not originally intended to support languages other than Java, it clearly has the ingredients needed to support a broad variety of programming languages. The ObjectWatch assessment itself references a list of programming languages for the Java virtual machine and uses this list as fodder for its analysis. But, the ObjectWatch article defines language neutrality in rather narrow terms. Some of the analysis is arguable, or merely shallow, and appears biased upon probing. Some of the analysis seems subtly oriented toward the exclusion of the Java platform in favor of the .NET platform. In contrast, my biases and true colors are obvious. I'm an unabashed admirer of both Smalltalk and Java, as will become apparent if it's not already so.

I designed the Bistro programming language specifically to integrate the best features of Smalltalk and Java, and provide nearly seamless integration between Bistro (Smalltalk) and Java. I could not have done this without the minimum features needed to support the essentials of Smalltalk. The admitted focus of the ObjectWatch language evaluation was "Possibly Commercial Languages (non-Java) that compile into JBC". Now, I will be the first to admit that Bistro is not (as yet) a language that has seen commercial usage. However, I'd like to believe that it has the potential for such, especially after a facility for round-trip conversions between Smalltalk and Bistro has been developed.

In the ObjectWatch article, Bistro was pegged as not emitting Java bytecode (JBC). Actually, the Bistro compiler does emit JBC as a result. It also translates Bistro source into Java source, but it would be far less useful if it did not then compile the generated Java source into bytecode. The development of the Bistro compiler was simplified by doing source-to-source translation and reusing the existing Java compiler. This approach also keeps Bistro at least somewhat platform neutral. For example, in principle, it would be relatively straightforward to translate Bistro source into C# source. Although, if I chose to target C#, the primitive method syntax would have to change to support C# instead of Java.

But, enough quibbling. Let's focus on the features needed to support language neutrality. Let's consider the minimum features that the ObjectWatch article listed and how Bistro addresses each.

So, what can we conclude from this counter-assessment? Some of the evaluation criteria listed in the ObjectWatch article raise important questions about design intent and expression. Should a language neutral platform impose interoperability on the type systems of the supported programming languages, and if so to what degree? Should language neutrality include cross-language exception handling? What are the minimal features truly required to support maximal interoperability without imposing artificial limitations on the supported languages? Some of the minimum features the ObjectWatch article listed are a bit overstated. The article concludes that:

"None of the non-Java JBC emitting languages indicate that they can support the minimum features that I previously identified as necessary for true language neutrality. None, for example, seem to support either cross-language polymorphic method resolution or cross-language exception handling, features that are absolutely critical for true language neutrality."

However, not all programming languages have classes with polymorphic methods. Those that don't clearly have no need for "cross-language polymorphic method resolution." It just so happens that Bistro does, and the Java platform supports this adequately. Also, very few programming languages share a common exception model, but blaming a platform for these disparities in language models seems extremely obtuse to me. The ObjectWatch assessment misses an essential point - some programming languages are richer and more expressive in certain areas than others (e.g., Bistro vs. Java). Rich programming languages express certain computational ideas more efficiently and succinctly. This is why such differences exist.

A programming language that supports a richer programming model can often be mapped onto a simpler one if the simpler one has the requisite capabilities to support such a mapping, as Java has for Bistro. However, where a direct mapping would impose unnatural limitations on the richer of the two, it may make sense to expose the limitations of the underlying one, but it does not make sense to shackle the richer language with those limitations simply to achieve some pathological level of interoperability. Quite the contrary, it makes sense to elevate the underlying platform with the additional capabilities of the superior language, and then provide mechanisms for interfacing with and reusing components developed in that language.

In contrast to the criteria suggested by ObjectWatch, I suggest that the following are the minimum (necessary and sufficient) platform features required to support language neutrality:

However, I do not mean to indicate that all supported programming languages should be required to use these features. All the features listed by ObjectWatch can be implemented with these four features, but not all programming languages will use all of these features. Of course, the unused features will impose limitations on the level of language interoperability achievable. But, that may be a natural consequence of disparities between programming language models.

Comprehensive, seamless, cross-language interoperability is an oxymoron.

Requiring this capability of a platform and the languages it supports is unwarranted and untenable. Programming languages should not be forced to a lowest common denominator of conceptual design. If they were, there would be no point in having different programming languages. Some of the interoperability criteria the ObjectWatch article listed simply do not make sense in all cases. Of those that do, some kinds of interoperability may be more difficult to achieve than others with the Java platform. However, the Bistro project demonstrates that they can be achieved where appropriate.

Additional Material

Smalltalk over Java: An Introduction to Bistro - Provides a comprehensive overview of the Bistro programming language and its relationships to Smalltalk and Java.
The Bistro Project - Provides access to the open Bistro source code and notes regarding the ongoing development of Bistro.
The Bistro Papers - Provides access to the research papers that led to the development of Bistro.

Trademark Notices

Java is a trademark of Sun Microsystems, Inc.
ObjectWatch is a registered trademark of ObjectWatch, Inc.