ObjectWatch Newsletter # 33
June 5, 2001
This Issue: Is Java Language Neutral?

CONTENTS

• Quotation of the Month: J2EE Portability

• Main Article: Is Java Language Neutral?

One of the results of Roger's recent speaking engagements has been a large number of new readers of the ObjectWatch Newsletter. We would like to specially welcome our new readers from Canada, India, Korea, and Hong Kong. We hope you enjoy reading the newsletter.

QUOTATION OF THE MONTH: J2EE PORTABILITY

MAIN ARTICLE: IS JAVA LANGUAGE NEUTRAL?

Is Java language neutral? This may seem like a silly question. Java IS a language. Isn't it? Maybe. And maybe not.

It depends on what you mean by "Java". Some of us think of Java as being a specific programming language with an associated syntax and a set of language features (such as automatic garbage collection). Sun, however, has traditionally used the term "Java" to mean both the language and the platform (including the extensive Java platform API). In other words, Java is both what you program with and what you program to.

I have no problem with either the language or the platform. Java is a great language, one which I have advocated since 1996 (in my book, "COM and DCOM; Microsoft's Vision for Distributed Objects"). The Java platform is very complete, and, with a few notable exceptions (such as entity beans), well thought out.

One might argue that a platform and a language are closely related. But of the two forerunner technologies to the J2EE part of the Java platform, CORBA and the Microsoft Transaction Server, both took considerable pains to distance themselves from any particular language. The only serious competitor to the Java platform, Microsoft's .NET platform, has also been very careful to maintain language neutrality.

It is hard to think of any successful platform (other than Java) that has tied itself to a specific language. Smalltalk tried something similar, and for a while appeared to be headed for real success, but eventually faded into obscurity.

There are good reasons for separating platforms from languages. Platforms change slowly, the reason we still have a number of banking applications  running on OS/2. Languages change frequently; yesterday it was Smalltalk, today it is Java, tomorrow, who knows? Platforms are generic, able to run a range of applications. Languages are specific, optimized for certain types of applications.

Another important reason for separating language from platform is the pragmatics of training new programmers. Most large companies have programmers with different language skills. Training a COBOL programmer to work with the Java platform will be much easier if they do not also have to learn the Java programming language.

At least some people at Sun seem to agree with my argument. Sun's chief Java evangelist,  Simon Phipps, says at his personal web site, "As I've been saying for five years now, what matters about Java is that you end up with portable binary components - the language is cool but less significant."

So if we accept the argument that language and platform should be independent of each other, it becomes a reasonable question as to how well this has been accomplished in Java. Is the Java platform truly nonpartisan when it comes to language?

Before I can answer this question, I need a definition of a "language neutral platform". A language neutral platform is one that truly doesn't care which language you use. It is one that allows you to choose languages based on the pragmatics of the situation, not the predilection of the platform. It allows you, for example, to purchase a class library written in one language and specialize it in the language of your choice. It allows you to have different programmers working on the same project in different languages.

The following are a minimum set of requirements for a programming platform to be truly language neutral.

• The platform must support the development of a class library in one language and invoke methods on it from another.

• The platform must support cross-language polymorphic method resolution, allowing base classes in one language to have methods overridden in other languages.

• The platform must support a language neutral typing system, allowing parameters to be freely passed from methods written in one language to methods written in another.

• The platform must support cross language exception handling, allowing exceptions raised in a method in one language to be caught and processed in a calling method written in another language.

• The platform must define an API that can be used from any supported language.

Simon Phipps gives evidence on his site that Java the platform is truly independent of Java the language. He points to a German web site that lists "all the known languages that can be compiled to platform independent Java bytecodes".  (www.sphipps.com/simon/links.htm) The site he refers to is grunge.cs.tu-berlin.de/~tolk/vmlanguages.html maintained by Robert Tolksdorf.

If the Java platform were to be language neutral, the key would have to be Java bytecode (JBC). The Java language architecture requires that Java source code be translated to JBC before being either compiled or interpreted. In theory, any language that can translate to JBC should be usable within the Java platform.

Based on Tolksdorf's web site, the list of languages that can generate JBC is impressive. I counted 133 links. As I followed and categorized these links, I found the results much less impressive.

Some caveats: I did my best to examine each link and understand the underlying technology. The process was tedious, and in many cases, the information available was sparse. There is undoubtedly some inaccurate classifications, but I have been as diligent as possible, paying particular attention to the most important category, Possible Commercial Compilers of non-Java languages to JBC. The actual classifications I made are given in the footnote to this article, so you can see if you agree with my conclusions. Also, I should point out that many products fell in more than one category. In these cases, either category would have made the product unacceptable for commercial usage, so I chose whichever seemed most appropriate to me.

I found that the most popular category on Tolksdorf's site was interpreters, compilers, or scripting engines written in Java, but ones that neither produce JBC nor in any other way attempt to allow non-Java programming for the Java platform. This included 53 of the 133 entries. These entries are just software systems that happen to be written in Java. None of these should have been included on this web site.

The second most popular category is Abandoned Projects. A full 40 of the 133 links are either links that are no longer active or links that show no sign of having been updated within the last year. As best I can tell, all of these are projects that have long since been abandoned.

Tied for third place were the categories Freeware and School/Hobby projects at 19 entries each. Both of these categories include technologies that show the feasibility of generating JBC from sources other than Java (a capability that is not in dispute), but do not include actual supported implementations that would be used in a large commercial project.

Out of 133 "languages that can compile into JBC", the total count in the category of Possibly Commercial Languages (non-Java) that compile into JBC is 8. The 8 products are these:

• Convert, a product which converts from VB to Swing forms from Black Dirt Software. I sent email to Black Dirt Software requesting more information. This email was not answered. No contact information was listed on the web site.

• Smalltalk/JVM from Mission Software. I called Mission Software and talked to Kim, who told me that this is an internal tool and that they don't actually sell this product. If Kim is correct, then this product should not be on this list.

• PERCobol, from LegacyJ. Based on the marketing literature, this does not appear to generate Java byte code, but instead provides a bridge between COBOL compilers and some parts of the Java platform, particularly enterprise JavaBeans. If this is true, this product should not be on this list.

• AppletMagic, a compiler of Ada 95. I was unable to get any information on this product.

• JGNAT, another compiler of ADA 95 from Ada Core Technologies. I spoke to Nancy Cruz at Ada Core Technologies who told me this work was funded by the Defense Department. She promised me a list of customers using this product within 15 minutes, but, as of press time (five days later) has not followed through.

• Canterbury Pascal, Oberon-2, and Modula-2, all produced by Mill Hill and Canterbury, an English company. I sent them a note asking for more information on the sales and deployment of these compilers, but, as of press time (one week later) have not received a reply.

Based on this research, I draw the following conclusions.

1. If there are any serious commercially supported compilers that generate JBC from non Java languages, there are very few, probably fewer than 5.

2. If there is any commercial usage of non-Java JBC emitting compilers, it is very limited. It is highly unlikely that more an infinitesimal fraction of the JBC in existence today came from anything other Java.

3. If there is any support for language neutrality in the Java runtime, it is very marginal. 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.

At best, the Java platform supports not true language neutrality but rather language replacement. There is a big difference between language neutrality and language replacement.

With a language neutral platform, one can choose between any number of languages, mixing and matching based on the needs of a given project. This is one of the defining strengths of the Microsoft .NET platform.

With language replacement, you can, indeed, choose which language you will use, but once you make that choice, you can't change. Yes, you can use an Ada compiler that generates JBC, but future work will be limited not only to Ada, but to that particular compiler's notion of how the JBC will be generated from Ada. This is much more limiting than, say, being able to program only in Java. At least then you are using a popular language, and one with a number of compilers from which to choose.

I believe that Simon Phipps and other Sun luminaries have greatly exaggerated the degree of language neutrality supported by the Java platform. The evidence indicates that true language neutrality in the Java platform is nonexistent, and even language replacement is sparse, if it exists at all.

In fact, it appears that Sun as a company is much less interested in language neutrality than is Simon Phipps. Sun's most recent JavaOne conference, for example, had almost 300 sessions. I could not find one that discussed the use of non-Java languages to program to the Java platform.

I assume that Phipps is well aware of the true relationship between the Java platform and the Java language. Even a rudimentary examination of the links supplied by the Tolksdorf web site would show that few, if any, of these products are commercially viable, even fewer are in common use, and probably none at all support true mix and match language interoperability

It will be interesting to see what the future does hold for the relationship between Java the language and Java the platform. There is no reason that Sun could not undertake the kind of effort that would make Java the platform truly available for all languages. Microsoft has already shown the way with its .NET language architecture, a language architecture very similar to Java but with language neutrality designed in from the beginning. 

For now and for the foreseeable future, despite Phipps protestations to the contrary, it seems clear that the Java platform is about one language and one language only: Java.

- Roger Sessions
Austin, Texas
June 4, 2001

.......

Footnote: For readers that would like to see how their analysis of the Tolksdorf web site compare with mine, here are my classifications. I apologize in advance for any inadvertent errors in classifications, and will be happy to issue an errata if any company that feels it was misclassified contacts me.

Again, the web site Phipps mentions is grunge.cs.tu-berlin.de/~tolk/vmlanguages.html

PRECOMPILERS FOR JAVA: iContract, The extensible Java pre-processor EPP

INTERPRETERS/COMPILERS/SCRIPTING ENGINES WRITTEN IN JAVA (MOSTLY RESEARCH PROJECTS) BUT NOT EMITTING JBC: Jacl, Tcl/Tk from Sun, Funnel, A Programming Language for Active Networks (PLAN), Combinatory Logic Interpreter, PS3I, HotScheme, SILK (JScheme), AJLogo, PROLOG+CG, Java Internet Prolog, NetProlog, CKI Prolog, JavaLog (Prologue interpreter), Jinni (Prologue interpreter), rLogo, JLog, W-Prologue, jProlog, JESS (Java Expert System Shell), Bistro (Smalltalk), dSelf, Hojo, Nice, Correlate, Jickle - Java Control Language, Yoix, Simkin, Bean Scripting Framework (BSF), Dawn, DynamicJava, W4F, Netscript, Rhino, BeanShell, PolyJsp, Resin, Iava, WebL, FESI, IScript, Pnuts, Yassl, Guarana, A Forth Interpreter in Java, Delta Forth, FIJI - ForthIsh java Interpreter, Java Backend for GCC, Tea, SQLJ, AgentSheets, JavAnimator, Bolero (Software AG)

ABANDONED PROJECTS (NO ACTIVITY FOR AT LEAST ONE YEAR OR DEAD LINK): SubJava, JPP - A preprocessor for the Java language, Aardappel, Lisp, Scheme, webLisp (pLisp), Jaja, Skij, LispkitLISP compiler, Lambda Calculus Interpreter, The UncommonLISP Interpreter, Plonk, JBasic (Jaba), HotTEA - Basic written in Java, JavaBasic, COCOA, the Java BASIC Interpreter, TRS-80 Model 1 BASIC Interpreter ("Warning: This was the first major program I wrote in Java, so in many places the code isn't pretty."), Applet Designer, Turtle Tracks, Yoyo, DGKS Prolog, LLPj, LL, Javalog, MLj, Bruce, Visual Eiffel, JOB (Oberon-2), Poor Man's Genericity for Java, Scriptic, JavaParty, Mist Beach Forth, DB/C JX, Luck, JOI - The Java Occam Interpreter, Agora98, MINERVA, BAMBOO, Jasmin, Jas

SCHOOL/HOBBY PROJECTS: Haskel, MetaJ, Demeter/Java, Sather, C2J++, dejay, PolyJ, Jass, Borneo, Javar, Javab, Component Pascal, JOMP, Tiger, Fortran 2 Java, Java Information Flow, Coco/R, Jcon, Javaa

FREEWARE: Kawa, Small Eiffel, J-Eiffel ("Note: This version is still experimental!"), JPython, Jython ("Jython is 100% Pure Java and should run successfully on any bug-free fully 1.1 or 1.2 compliant JVM. Unfortunately, such a beast can sometimes be hard to find."), aspectj, KOPI, Specialization classes for Java, GJ, Jamie, OpenJava, Kiev, JUMP (Not Microsoft's JUMP), Pizza, perljvm, C2J, Java Expressions Library, E, NetRexx

POSSIBLE COMMERCIAL JBC EMITTING LANGUAGES (SEE NOTES IN ARTICLE): Convert - Converter of VB to Swing forms (Black Dirt Software), Smalltalk/JVM (Mission Software, Inc.), PERCobol (LegacyJ), AppletMagic (Titan Systems Corporation, a subsidiary of AveStar), JGNAT (From Ada Core Technologies), Canterbury Pascal for Java, Canterbury Oberon-2 for Java, Canterbury Modula-2 for Java (Mill Hill and Canturbury)

PRODUCTS WITH NOTHING TO DO WITH JAVA: StarLogo

UNDETERMINABLE STATUS: Talks2 (no English text on web site), Foo (no English text on web site), James 007

ABOUT OBJECTWATCH

ObjectWatch specializes in teaching how to architect effective enterprise architectures. Roger Sessions is the CEO of ObjectWatch and the designer of all of the ObjectWatch workshops. He has  many years of close association with CORBA, Java, and Microsoft technologies.

Roger's most recent book is "COM+ and the Battle for the Middle Tier", published by John Wiley & Sons. This book is an introduction to COMWare technologies. It discusses the COM+ COMWare platform and compares it to the other industry COMWare standards (EJB and CORBA). This book can be ordered at www.amazon.com/exec/obidos/ASIN/0471317179/objectwatchA

Legal Notices

The ObjectWatch Newsletter does not accept outside advertising or rent out its subscription list.

This newsletter is Copyright (c) 2001 by ObjectWatch, Inc., Austin, Texas. All rights are reserved, except that it may be freely redistributed provided that it is redistributed in its entirety, and that absolutely no changes are made in any way, including the removal of these legal notices.

ObjectWatch is a registered trademark (r) of ObjectWatch, Inc., Austin, Texas. All other trademarks are owned by their respective companies.