Robert Schuster wrote: > I invested some time to translate my article which was published by > german free software centric newssite pro-linux.de to english. You can > find the document in OO.o format here[0]. > > What I am interested in is that someone who is a bit more skilled in > dealing with the english language takes a look at the paper and fixes > the wording.
See attached. Let me know if there are any points you want to discuss about it. -- Chris Burdess
Version 1.00 Robert Schuster ([EMAIL PROTECTED]) This document is licensed under the Creative Commons Attribution ShareAlike License 2.0. GNU Classpath - What's around the corner? Motivation In this article series I want to introduce you to GNU Classpath and some of its sister projects. A short time spent reading this article should give you a broad understanding of the state of Java in the Free Software community. I will try to deliver the content without too much technical jargon, although that may not be possible in all cases. What is this all about? To start with I will present some background information about Sun, Java and its license problem, and go on to introduce GNU Classpath and its history. The second section is dedicated to popular software which already runs on our free implementation. Finally I will give you a short glimpse into the future of GNU Classpath. What is Java, really? Many of you may have heard that Java is slow and not well adapted to serious applications. This point of view, however, considers Java only in its common implementation and not as a programming language. A programming language is usually categorized by its capabilities and expressiveness. Java is a language which provides strong support for a programming methodology called object orientation, which is fundamental for today's application development. In addition, a Java developer can benefit from a degree of type safety. When both these concepts are applied correctly they can leverage rapid application development by supporting the design process and can serve to avoid programming errors. At this level we can't say anything about speed; to do so we need programs which are capable of processing the language. When Java was published in 1996, one of its most stunning features was its ability to run on different computer operating systems without having to be recompiled. This property is obtained by using "bytecode", which is then processed and run by a program called a virtual machine. The commands in the bytecode cannot directly access the features of the underlying operating system but instead use a "class library". This library provides functions that a typical Java application needs: Strings, graphical components, a network interface and much more. Therein lies the real secret of platform independence, because on each and every operating system where Java programs should be able to run, we need a specially adapted class library. Therefore there are two things of interest in the speed of Java: on the one hand the ability of the virtual machine to efficiently process the bytecode and on the other hand the care in the implementation of the class library. What are the problems the Free Software world has with Java? Traditionally the Java class library is provided packaged with a virtual machine and a couple of helper programs by Sun Microsystems Corporation as the "Java Runtime Environment" (JRE) or "Java Development Kit" (JDK; for developers) free of charge under a non-free license. In the course of time more and more functionality was added to the library and the virtual machines got ever more sophisticated in processing bytecode. However it soon became apparent that Sun was overly constrained with development: awkward programming errors slipped through their quality assurance, long-known bugs were not fixed and some of the features which Java application developers longed for where delayed from version to version. Besides these technical problems Sun was still not willing to loosen the license restrictions for their product, so distributions such as Debian (and latterly Ubuntu and Fedora Core) could not offer the Java platform as distributed by Sun. In the past Sun repeatedly mentioned the topic of relicensing and high officials gave forth weightily on the matter. However in the end it was always stressed that the central control of Java is a key aspect of maintaining compatibility and the whole topic vanished in a puff of smoke. So isn't Java free already? In casual terms, some people (among them James Gosling, the father of the programming language) claim that Java is 'open source' (http://today.java.net/jag/page7.html#62). Until now all the licenses under which Sun distritbuted their Java product have turned out to be some kind of Read-Only Open Source: a glimpse at the source code is allowed but no further freedoms are forthcoming. Freedom Zero - the basis of all Free Software Contrary to certain trends which only demand access to the source code for software, I want to explain why the freedom to run a program for any imaginable purpose is far more important. Today, only a minority can imagine their computer preventing them from doing tasks (like watching a media stream or copying an application or document) which are normally not a problem for a computer. We are used to systems which can solve a wide range of problems. The export regulations of the USA on strong cryptography or the exorbitant usage prohibitions of software in countries like Iraq, Afghanistan and others seem absurd because it is not possible to enforce them. In the future, technical means like "trusted computing" (TCPA) and digital rights management (DRM) will fill this gap and control access to the computer. In this task the Java as well as the .NET platforms are brilliantly suited to equip software with gates and other restrictions. When implemented correctly and applied properly a Java program cannot pass the border of the virtual machine. What on the one hand secures your hard disk from unwanted access from the outside, can also be turned in the opposite direction. With a Free Software implementation we ensure that the Java platform will always serve the needs of their users who will have full control of it. Another interesting "Freedom Zero" perspective can be found in the article (http://diveintomark.org/archives/2004/05/14/freedom-0). What's the problem with the term "Free Java"? Many people know that the GNU/Linux operating system is based on a UNIX system but it cannot officially be called UNIX. This is because "UNIX" is a trade name which is assigned when a certain suite of compatibility tests are passed. Some years ago many publications therefore wrote "Un*x" instead which confused ingenuous people like me back then. "Java" is also a trade name, which is assigned by Sun Microsystems to products which conform to their specification and have been tested. Indeed, GNU Classpath strives for such a certification but as long as this is not completed, it is not officially Java and the label "free Java" is equally problematic. GNU Classpath and its history until now In 1998 the GNU Classpath project was founded to develop a free Java-like class library which could be used by the Japhar virtual machine. At first Classpath was developed within this project but even at this early time the idea was to some day have a class library which could be used by any virtual machine. The work commenced with 5 developers at that time. In the year 2000 the GCJ class library was gradually merged and another bunch of developers joined the project. Three years later, the Kaffe project became interested in Classpath and started to exchange patches. In the same year Mark Wielaard became maintainer of GNU Classpath. He shortened the release cycles, which where lengthy and discontinuous at this time, to 2 months, which was very much appreciated in the community. Additionally he managed the integration of four projects which were maintained separately at that time. The number of patches increased dramatically in 2004. For the release 0.12 (November 2004), the ChangeLog reveals 29 contributors who added an average of 350 lines of code every day. New developers join us approximately every quarter of a year. The free virtual machines Kaffe, GCJ and SableVM still maintain a derivative of GNU Classpath in their repositories but the unification work is progressing. For JamVM, IKVM.NET and IBM's JikesRVM this goal has already been attained. In Fall 2004 the generics branch was opened. This minor branch of the development is devoted to implementing the language features of Java 5. For a while there was no free compiler available, not to mention a suitable virtual machine. In December a special version of Eclipse's ECJ could be extracted and used to compile the generics branch. We are confident that Tom Tromey's GCJX, a front end to the GNU Compiler Collection (GCC) will be able to be used for the same task by the end of 2005. Eventually in April 2005 Andrew John Hughes got the generic branch to run using the latest version of JamVM. Innovative Free Software Besides Classpath contributors, we get many patches from GCJ and Kaffe, which help to complete the class library or fix bugs in our implementation. While we "only" provide classic Java program execution using a virtual machine a couple of projects based on Classpath pursue some very innovative ideas: the spectrum ranges from translations of Java bytecode into the machine language or the Common Intermediate Language (.NET "bytecode"), to integrations with C++ and Oberon and an operating system which is written in Java and assembly language only. Details about these projects will be given in the second part of the article series. The state of affairs Vast areas of the J2SE 1.4 class library have been implemented already and conform to the specification. Problems arise mainly in corner cases and the Swing and AWT graphical toolkits. One of our strengths is that we can depend on the functionality of other free libraries or open accessible information. For instance, we generate internationalization data using the CLDR project (http://www.unicode.org/cldr/) and thereby gain support for 274 languages (the JDK currently has 134). Applications which use the Standard Widget Toolkit (SWT) for their graphical presentation have a good chance of running flawlessly on Classpath-based virtual machines: since the SWT implementation does not differ between them an application demands more non-visible correct behavior from us. Since most work is invested here SWT-based applications run pretty well. Hall Of Fame, or where we shine Eclipse Getting the famous development environment Eclipse (http://eclipse.org/) to run on our free virtual machines is one of our greater achievements. Eclipse has not been tied to the proprietary JDK for a while now but repeatedly had to fight with new problems. In 2003 many changes to the IDE's source code were necessary to get it to run, but these days you can simply download it from their homepage and run it with GNU Classpath 0.14, a lightweight virtual machine like JamVM and a slightly modified command from the console. It is nearly as easy as this to create a natively compiled version of Eclipse and run this instead. By the way: if you open the "Tips & Tricks� in Eclipse's help menu, an internal Apache Tomcat presents the documents while the search capability is realised by Apache Lucene. RssOwl RssOwl (http://rssowl.sourceforge.net/) is a Java- and SWT-based newsreader. That this application runs flawlessly is due to Classpath developer Sven de Marothy who fixed problems in the class library as well as in RssOwl itself. Apache Tomcat Apache Tomcat (http://jakarta.apache.org/tomcat/) is a web server which can programmatically create web pages. This technique is called Java Server Pages (JSP) and competes with PHP, Perl and Python. The flagship of Apache Tomcat is the current version 5 which runs equally well with Kaffe and GCJ. JOnAS JOnAS (http://jonas.objectweb.org/) is another representative of the Java server world. The software is used to implement large enterprise information systems (http://en.wikipedia.org/wiki/Enterprise_Information_System) and is in turn an environment for applications. JOnAS is a really complex program and we are very happy that it runs with GCJ. BeanShell BeanShell (http://beanshell.org/) is a small interactive shell, which can be embedded extremely easily into applications. The syntax of the shell is Java-like but offers loads of syntactical sugar. If you abstain from the Swing-based interface (classes bsh.Console and bsh.util.JConsole) you can use BeanShell flawlessly with GNU Classpath. OpenOffice 2.0 The announcement (http://software.newsforge.com/article.pl?sid=05/02/25/209222&tid=93) that OOo 2.0 is markedly dependent on (proprietary) Java caused some buzz on NewsForge (http://software.newsforge.com/article.pl?sid=05/03/22/204244) and other sites. Even before the Free Software Foundation's call to free OpenOffice 2.0, Caolan McNamara (http://blogs.linux.ie/caolan/2005/05/04/70/) of Red Hat was hunting down bugs and missing features in GCJ. The office suite is not yet released but I am confident that major interoperatibility problems will be fixed by the time it is. Apache Ant Ant is a Java-based software construction tool which uses XML files to describe the complex intermediate steps to automate application construction. Using only a few additional arguments the tool can be run with a GNU Classpath-based VM and use Jikes or GCJ as its compiler. In the future this will be integrated into Ant's shell scripts allowing the user to invoke it in the way they are used to. Hall of Shame, or what does not work ... yet Gaps and bugs in our implementation of Swing make it impossible at the moment to run huge applications like Netbeans. However others like JEdit at least start. Fortunately development in this area is progressing in a decent pace. What helps most are bug reports with small test programs or real applications that show faulty behavior. A presentation (http://people.redhat.com/fitzsim/fosdem2005/html/img0.html) by Thomas Fitzsimmons (Red Hat) given at FOSDEM 2005 provides a glimpse at the state of affairs at that time. The future >From a user's point of view the availability and stability of Java applications on free operating systems will increase in the coming months. Installation and running of the application will be simplified � although this is an issue for the distributions themselves. When a Java applet in your browser suddenly starts working without you having installed a proprietary virtual machine, you know we have advanced another small step towards a fully free stack of a Java-like system. Furthermore users of less popular computer architectures and operating systems will start to realise Java's promise of platform independence. As well as criticism and suggestions, the GNU Classpath team would be very happy to hear your success stories. If your favorite application now works correctly, you are sincerely invited to come along on the channel #classpath on irc.freenode.org . What's coming up next? In a few weeks I will publish a sequel to this article. It will target Java developers and developers in general: I will deal with many of our sister projects, why you should build on our platform, how our development works and what goals we have for the next time. Thanks for your attention. Robert Schuster - (C) 2005 Some rights reserved.
_______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
