Java, MONO, OR C ?
Thoughts on The Future Of Open Source Desktop Development
This was written March 16, 2004 and represents a personal opinion, though advice and comments from a number of others are reflected here. Hopefully it will start a discussion and become rapidly outdated in light of new insights and progress.
BACKGROUND
In the Linux desktop world, there's widespread sentiment that high-level language technologies such as garbage collection, sandboxed code, and so forth would be valuable to have and represent an improvement over C / C .
Several Desktop Projects Are Actively Intested in this Kind of Technology:
GNOME: many developers feel that this is the right direction Mozilla: to take full advantage of XUL, it has to support more than just JavaScript OpenOffice.org: has constantly flirted with Java, and is considering using Java throughout the codebase Evolution: has considered Writing new code and features in mono, Though They area Waiting for a gnome-wide decisionion
.
For some time now, Novell (previously Ximian) has been hacking on the Mono project to reimplement the .NET framework. Mono has been widely associated with GNOME, but many people are unaware that the projects are unrelated. GNOME has never adopted Mono as its .
NO REWRITES PLEASE
None of the huge desktop projects are considering a one-pass rewrite to a new language; managed code can invoke C / C code, so there is an evolutionary path where newly-written code can be managed This allows gradual refactoring.Language vs.. Platform
In looking at C # or Java, projects such as GNOME are considering primarily the language, not the platform. For example, GNOME would continue to use GTK and other open source platform elements, rather than WinForms, XAML, or Swing. It's just that these Platform Elements Would Now Be Used from a High-Level Language (AND in The Future Implement in Such A Language).
Native Component System As Migration Path
OO.org is in the best position for gradual refactoring to a high-level language runtime, because of the UNO framework. UNO allows an interface to hide whether the object is C or Java. With Mono, or Java technologies such as JNI or CNI , it's fairly simple to invoke C / C from the high level runtime. However, calling C # / Java code from C / C is more complicated. UNO addresses this issue, allowing smooth bidirectional access between C and Java.
XPCOM allows similar benefits for Mozilla. GNOME is in a tougher situation, and will probably have to keep the language mixing one-way (new language code calling C / C ) or add a dependency on something like UNO for the migration path benefits.
Several years ago, Owen and I advocated a native shared runtime as an easier-to-implement alternative to a high-level language runtime. But perhaps a simple native component system bridge nicely complements a high-level language runtime.
Pressures to move
Why is a high-level language and runtime important? Why are these projects considering a move? Coding efficiency. High-level languages are simply technically superior to C / C for most uses, desktop applications in particular. XAML. Microsoft is trying to take over the Internet and replace HTML. There are many more possibilities for an effective open alternative to XAML given a managed-runtime language. Component technology. A managed language solves some of the same problems COM was designed to solve, such as ABI encapsulation, versioning , and modularization. Unification of server and desktop APIs. By allowing programmers to use the same set of class libs to write a desktop app or a server-side app, we get advantages in terms of training and code reuse. ISV appeal. A familiar language with cross-platform capabilities is a relatively friendly porting target. The rest of the world is moving, and companies are angling to get their particular technology accepted. It's important for th E Open Source World to Proactively and Consciously Make Its Own Decision.
Community shop Decide
Right now the open source projects are largely ignoring this issue, while companies maneuver in the background. Unfortunately, the highest-profile directions encouraged by companies are unlikely to be accepted by the community as a whole.
.
Looking at the situation realistically, if GNOME started to require a .NET clone you'd see a fork, and if it started to require a proprietary JDK you'd see a fork. There are too many people who would find these directions unacceptable. The question then is: many strong proprietary companies such as Microsoft are moving full speed ahead on high-level managed language platforms Can open source compete, or is it too unable to make hard decisions Rephrased:.? is there some way we can find to Move Away from C / C , WITHOUT CAUSING MASSIVE Alienation and forking?
It's time to start the discussion. Rather than fooling around in the background, companies should get involved in a broad community process where we work out a common direction for the open source desktop codebase.
Level Playing Field
To me the way to create something that most of the community can swallow is to stick strictly to open source, unencumbered technologies This means there's a level playing field;. Anyone can hire developers to contribute to the technologies, anyone can fork if they have to It's Essential That Our High-Level Language Technology Have No Single Owner with Irrevocable Control.
Open source creates this level playing field, and that's why it historically works as a way for diverse companies and individuals to collaborate on software projects. Without the level playing field, everyone gets too paranoid and fragmentation or stagnation are inevitable.
Problems with a .NET Clone
Microsoft has set a clever trap by standardizing the core of the CLI and C # language with ECMA, while keeping proprietary the class libraries such as ASP.NET and XAML. There's the appearance of an open managed runtime, but it's an incomplete platform, and no momentum or standards body exists to drive it to completion in an open manner. Many interesting class libraries are clearly encumbered by Microsoft IP and nobody concerned about legal liability will want to ship them. The core may also be encumbered, though that remains uncertain.Aside from IP issues, Microsoft controls the .NET platform. They will always be ahead, and it will always be tuned for Windows. This is the wrong direction for free software, if we want to win the war, and not only some battles.
Even IF We Use Some Unencumbred Ideas Or Designs from The .NET World, We Should Never Define Our Open Source Managed Runtime As a .NET Clone.
If we built on the ECMA core, it would be critical to launch a large-scale effort to standardize and market a comprehensive alternative API set to replace the Microsoft-encumbered class libraries. This would be a heck of a lot of work.
Is Java an Alternative?
Java has broad industry acceptance, historically driven by Sun and IBM; it's by far the most-used platform in embedded and on the UNIX / Linux enterprise server At the moment, it's more widely used on the web than .NET It's the obvious.. DEFAULT GIVEN THE UNIX TRADION OF IORG...................
But momentum is already shifting;. Microsoft's monopoly power threatens to deflate Java and substitute .NET The large open source projects could drive Java deep into Linux, and bring it new life, just as Linux revived UNIX as a whole But first we need an. open source Java implementation.Currently we have two options for an open source VM. The gcj effort, and IKVM running on the Mono JIT. Both use the GNU Classpath libraries. A GPL-compatible release of Sun or IBM's mature JDKs would allow the open Source World to Respond to Microsoft Much More Quickly, But We can't Know WHether this Will Happen.
.
Java Has Some Technical Advantages over C #, And Vice Versa, But it's probably way to assume That A Debate over the technical merits of java vs. c # Will be unproductive and neverending.
One virtue of Java is that it's at least somewhat an open standard; the Java Community Process is not ideal, but it does cover all the important APIs The barest core of .NET is an ECMA standard, but the class libraries of note are. Microsoft-Specific. It's unclear trianeind Influnce over the ecma spec in any case.
Also Worth Keeping In Mind, o.o.org is already useful java.
Combining Java and Linux IS Interesting from another standpoint: it merges The Two Major Microsoft-Alternative Platforms INTO A United Front.
What About Perl, Python, And Ruby?
The traditional open source languages such as Perl, Python, and Ruby are significantly different from Java and C # (while Java and C # are very close, as the existence of IKVM implies). Parrot tries to get these languages running on a common runtime.My view, which will doubtless get me flamed, is that these languages are not really the right thing for writing large desktop apps such as GNOME or OO.org, though they are nice for a lot of other purposes. We should be able to keep supporting bindings to these languages though, via the traditional mechanisms for now, and in the future via UNO- or Jython-style approaches. in other words, it should continue to be possible to write desktop applications in these languages.
Spelling Out the Options
.
Whether to use Mono or some form of Java. If Java, whether to use gcj or IKVM / Mono as the open source implementation. If Java, whether to target an open source implementation specifically, or try to support both open source and proprietary JDKs. If Mono, whether it's just C # plus existing GNOME libraries (or even GNU Classpath!) or the whole .NET platform. Whether to use UNO (or equivalent) as a migration technology, to improve the unmanaged-to-managed interface. Which language syntaxes can be used to code GNOME itself, as a matter of policy. Which language syntaxes are feasible to implement, targeting the chosen runtime. ie what languages can third-party applications be written in. It's likely that Perl for example is impossible to implement Satisfactorily On Top of Either Java Or .NET. What set of class libraries CAN GNOME Applications Use and Rely Up? How Quickly CAN .NET WIN?
Every month without a coherent open source managed runtime answer - something we can start using across the board in the major projects - risks losing developer mindshare and the open Internet to a de facto Microsoft lock-in.
In proposing and advocating a language runtime, companies and individuals need to keep in mind what's genuinely viable to be adopted across the board For example, anything which is not open source is not viable;. Significant interest groups including some companies will not Accept it, and for pretty good reasons.
Anything which is defined as a ".NET clone" also appears to be not viable;.. There's strong opposition to this path as well Cloning .NET on Linux may speed up adoption of Microsoft's technology, handing them the Internet on a silver platter Speeding up the competition's success is not the way to catch up with them. Fear of this is widespread.Those of us trying to make a profit should keep in mind that everyone stands to benefit from keeping the core open source platform unified and competitive. There are a lot of class libraries and applications in an overall competitive ecosystem that can be company-specific. This opportunity to add extra stuff "on top" does not exist in an all-Microsoft world, where the profits go to a single company. But .
WE NEED A Unified Front On this Topic, and Quickly. We Either Find A Way To Use Java Or Mono, or We need to put the question to bed and declare C / C The Only Way for the Forteable Future.
What next?
For some time, the gcj and Classpath teams have been working on an open source Java runtime. Perhaps it's time to ramp up this effort and start using it more widely in free software projects. How long do we wait for a proprietary JDK to become GPL Compatible Before We Take The Plunge with What We Have?
The first approach I'd explore for GNOME would be Java, but supporting a choice of gcj or IKVM or the Sun / IBM JDKs The requirement would be that only the least common denominator of these three can be used:. Only the subset of the java standard completed in GNU Classpath, and avoiding features specific to one of the VMs Over time, the least common denominator becomes larger;. Classpath's goal is to complete the entire java standard.If this approach works, it seems like a viable compromise There. Are some tradeoffs to remaining neutral on the gcj vs. ikvm vs. JDK Issue:
We may have to write all Makefiles twice, or write a reasonable abstraction to handle this We can not use VM-specific features that may be useful, such as CNI The full Java platform can not be used;.. When using an API , Developers Must Check That It's Present and Functional In ClassPath.
Supporting Multiple VMS Does Have Some Technical Advantages, Such As The Ability To SELECT A VM WITH OPTIMAL TRADEOFFS: Portability, Performance, Size, And Other Aspects May Vary Across IMPLEMENTATIONS.
THE BIG Question IS, Can We Accept A Solution Where C # can't be used to import the gnome core? If little insist on C #, and Others Insist on "Anything But .Net," We're At Something of An Impaasse. It's possible there's a viable compromise involving the Mono core without the .NET class libraries, and additional legal evidence that the Mono core is safe; but I'm not sure even that will be enough to get critical mass to accept it Supporting Microsoft is the. Last Thing Most Other Players in The Industry Want to Do.
The open source Java subset is something we could start using today, that nobody has any fundamental reason to reject. It's strategically safer because it does not endorse Microsoft's platform, and all three major vendors involved in GNOME maintain a VM that can run it. It has stronger technical ties to the rest of the Linux world, including server and embedded; rather than isolating the desktop on a desktop-specific platform.Thus I think it's time to start getting buy-in and coding proof-of-concept for using Java in the GNOME core. Longhorn arrives in only 1-3 years, and we need all that time. If a proprietary JDK becomes open source then great, we could figure out how to move to it if it's better. But let's not count on That Deus EX MACHINA, AS A Community We need a self-reliant plan to derail the microsoft monopolists.
Postscript: Xaml
One discussion the desktop community should have in parallel with the language issue: how do we address XAML, and how do we evolve GTK , Qt, XUL, and so forth to provide an alternative Perhaps XAML is a vaporware silly idea we can ignore,? But we need to get far enough alone with thing......................... ..
.
PostScript 2: Language Platform vs. GNOME Platform
There Are A Number of Elements of The Desktop Platform With Comparable Features in The Java and .NET Platforms:
UI Toolkit Corba Implementation XML Parser Preferenceation Storage APASE Access Vector Graphics
The default would be to stay with the current platform elements used by the Linux desktop, for codebase sanity and UI consistency, with case-by-case consideration of the language-specific alternatives. In other words, first we adopt the Java or C # language ...........................
How do we decide WHETHER TO USE THE JAVA / .NET Feature, or the native linux feature? WE Might Split The Platform Elements INTO MULTIPLE CATEGORIES:
Elements that determine how the desktop works, looks, and feels. The UI toolkit is an obvious one. But for example, GConf's process-transparent model-view architecture is critical to implementing GNOME's "instant apply" interface guideline. It would generally be impossible to write an acceptable GNOME application or component without using these elements, because the corresponding Java / .NET elements do not offer the same functionality. Elements that define interactions or interfaces among applications. For example, an interprocess communication mechanism is useless unless all the applications share it;.. so it's essential to standardize the platform feature Elements that are user-invisible and can be decided application-by-application If different applications use a different API for database access, or vector graphics, users are never going to notice ............. ..
IT May Well Be Hard to Enforce Or Encourage these DistInctions in Practice, though.
Validate HTML
