Red Hat Summit November 2004

http://www.gnu.org/software/classpath

http://planet.classpath.org/

Mark Wielaard
mark@klomp.org
http://www.klomp.org/mark/

Essential core classes for the java programming language

GNU Classpath

What is GNU Classpath (formally)

Essential Core Classes for the java programming language

Free Software library for the GNU system

Not a compiler (gcj)

Not a execution environment (libgcj/gij)

Base library shared with a lot of different projects

Official GNU project with the FSF as custodian

History

GNU Classpath was started in 1998 (5 developers)

Initially designed around Japhar, but planned to be used with multiple runtimes

Merge with libgcj (2000) (20 active developers)

More and more runtimes based on GNU Classpath
Mainly research, but some production runtimes

Kaffe starts seriously adopting GNU Classpath (2003), even more active developers and multiple active branches.

GNU Classpath is shared
among many projects

“Upstream” provider
for the core class library

java.*, most javax.*

Mainly for historical reasons,
certain javax.* are provided
by other projects

Common code base,
bug tracking, ...

Non-trivial applications build
on top of GNU Classpath

GNU Classpath – Present

Jikes RVM

Kaffe

Jupiter

IKVM.NET

AegisVM

GNU Classpath

. . .

JamVM

What is GNU Classpath (informally)

What is GNU Classpath (team)

70+ people (with paperwork on file with the FSF)

29 credited in the last release (active during last 2 months)

Average of 350 SLOC per day (new code)

Average of 5 commits per day (0.11 -> 0.12)

Total Physical Source Lines of Code (0.12) 258,840

According to David A. Wheeler's 'SLOCCount'

find classpath -name *.java | xargs cat | wc --lines
549299
find classpath -name *.c | xargs cat | wc --lines
31499

How do we make GNU Classpath

savannah.gnu.org holds CVS repository

Everybody with proper paperwork on file can get access.

Rapid development mode

Work done by the most technical capable
(No formal hierarchy)

Discussions on mailinglist and irc.gnu.org #classpath

Informally on http://planet.classpath.org/

Merged into libgcj (GCC) and Kaffe CVS (daily/weekly)

http://developer.classpath.org/ has CVS diffs

Snapshots (every two months) integrated with releases from other tools/compilers/runtimes.

GNU Classpath Maintainer

GNU Classpath Maintainer

“Official” duties

Keep it maintainable

GNU Classpath Hacking Guide

GNU Coding Standard

GNU Maintainer Guidelines

“Paperwork”

“Unofficial” duties

Release Manager

Quality Manager

Merge/Patch monkey (libgcj)

Motivation

Currently, most free software is written in C

Close to hardware

Fast execution, even
with bad compilers

Large code base,
many libraries

Ubiquitous

The Good

Easy to make bugs

Lacks “modern”
language concepts

(“modern” = 1980’ies)

Hard to write
portable code

The Bad

Libraries not
well integrated

Difficult to learn

The Ugly

Motivation

Java is a good foundation for many projects

Type-safety

Avoids many typical bugs, crashes, security problems

More opportunities for optimizing compilers

Modular, object-oriented, concurrent, dynamic

Easier to write structured, portable code

Very rich library, reasonably well designed (mostly)

Large developer base (“COBOL of the 1990’ies”)

There exist lots of other good (even better?) languages:
Oberon, Eiffel, O’Caml, Haskell, Erlang, TOM, Cedar, ...

But: They have not many free applications/libraries

Motivation

But: Java does not solve every problem

Over-hyped as a solution to everything

Bad reputation for wasting resources (CPU, RAM)

It is easy to write inefficient programs

Early implementations were very slow

Type-safety and memory management have their cost

Often over-estimated: Array bounds checking
(→ no buffer overflows) costs ~2% execution time,
avoids ~50% security-related bugs

Syntax similar to C++ → not very easy to learn

Java is a compromise

Not necessarily ideal, but reasonable

Motivation

— Richard Stallman
The GNU Manifesto, 1985

“

”

Why GNU Will Be Compatible with UNIX

Unix is not my ideal system, but it is not too bad. The essential features of Unix seem to be good ones, and I think I can fill in what Unix lacks without spoiling them. And a system compatible with Unix would be convenient for many other people to adopt.

Plenty of free software is being written in Java

Sourceforge.net:
11’032 Java projects

Motivation

Freedom!

Freedom to use, study, adapt, improve and share

Freedom to innovate

Not controlled by any single entity

Future: Possibility for natural, proven
(vs. committee-dictated) standards

Escape the Java Trap!
(Article by Richard Stallman)

Anatomy of a traditional java-like system

Java Compiler

Java ↦ bytecode

Java Virtual Machine (JVM)

Executes bytecode (for example .jar file)

Run-time services

Bytecode interpreter

Just-in-time compiler

Garbage collection

Synchronization

Class library

Data structures

Networking

User interface

Database access

System/Library access — JNI (C calling convention)

Run-time services

About 20 JVM projects

Very diverse goals

Almost no common code (yet)

Anatomy of a traditional java-like system

Class library

java.{lang, math, ...},
javax.{mail, crypto, ...}

Some C code for POSIX-like systems

2

3

Bytecode compiler

gcj, jikes, kjc, Eclipse, ...

Complete up to 1.4

1.5 will need some work
for generic types: List<A>

1

1

2

3

Anatomy of a Java-like system

Ex.: Jikes Compiler

71,000 lines of code

~ 17.5 person-years

~ USD 2.4 Mio.

Java compiler

Ex.: Kissme VM

59,000 lines of code

~ 14.5 person-years

~ USD 2.0 Mio.

Run-time serv.

Ex.: GNU Classpath

258,000 lines of code

~ 68.2 person-years

~ USD 9.2 Mio.

Class library

Very coarse estimates!

Generated using http://dwheeler.com/
sloccount/

“Basic COCOMO”

1

2

3

1

2

3

(Complete GNU Compiler Collection is 2,000,000+ SLOC)

Very different VMs

GNU Classpath is used by very diverse VMs

Very different (sometimes conflicting) design goals

Extremes: gcj ↔ Jaos, JNode OS ↔ IKVM.NET

gcj: Java ≃ C++

Jaos, JNode OS: Cannot support any C code, no POSIX

IKVM.NET: Build to be integrated into .NET platform/libraries

Very different VMs

Diverse VMs → delegation/façade pattern

Clear interface between Classpath and VM

Plan: Common glibj.zip/.jar with all core classes

VM should inline calls to pack.-local final methods

java.lang

. . .

1

Class

VMClass

Any VM-specific state and methods

Package local, final

Classpath provides non-optimized default implementation

1

1

Thread

VMThread

1

All public methods

A lot of history - Free software is flexible

Done with GNU Classpath:

Compiling Java source » stand-alone executable

Compiling Java bytecode » CIL (bytecode of .NET)

Operating Systems with type-safe kernels

JVM for multiprocessor clusters (128 CPUs, Myrinet)

Embedded systems with real-time guarantees

Alternative access to native system/libs (non-JNI)

Free Software can be adapted
to arbitrary needs → innovation

Documentation

Documentation
is very important

Using gjdoc we generate XML, XHTML and info

Many packages/classes have reasonable to very good documentation

There certainly
are exceptions

Ugently needed:

High-level overview

Manual for free environments

Quality assurance

Test suite

~175,000+ tests
(~65,000+ SLOC)

We need many more!

Key to reliability

Tests are very
easy to write

What is the spec?

Do what applications expect

// Tags: JDK1.0

package gnu.testlet.java.util.Stack;

import java.util.Stack;

import gnu.testlet.*;

public class empty
extends Testlet

{

public void test(TestHarness h)

{

Stack stack = new Stack();

// Check #1.

h.check(stack.empty());

// Check #2.

stack.push(“abc”);

h.check(!stack.empty());

}

}

Test for java.util.Stack.empty()

http://sources.redhat.com/mauve/

Releases

Now: Version 0.12

Time-based release schedule

Every one/two months,
a new 0.xy release

Already quite usable for real applications

“0.12” may be too modest a name

For v1.0, we need:

Fixed VM interface

Complete implementation of supported packages

Define “supported”!

Full test coverage

Full documentation
of the API

Start of a real manual?

Current state – GNU Classpath

GNU Classpath is comparable to J2SE 1.3/1.4 (Desktop)

Build both according to spec/docs and around actual applications

No formal compliance with any specification

java.beans[.beancontext], java.io, java.lang[.ref, .reflect], java.math, java.net, java.nio.charset[.spi] (only SPI), java.rmi[.activation, .dgc,
.registry, .server], java.security[.acl, .cert, .interfaces, .spec], java.sql, java.text, java.util[.jar, .logging, .zip]

javax.naming[.directory, .ldap, .spi], javax.swing.[border, plaf], javax.transaction[.xa]

(Plus integrated packages – see following slides)

J2SE 1.4 (Desktop), should work, might have bugs (please report!)

Current state – GNU Classpath

J2SE 1.4 (Desktop), partially (80+%) works

java.applet, java.awt, java.awt.color, java.awt.event, java.awt.geom,
java.awt.image[.renderable], java.nio[.channels, .spi], java.util.prefs

javax.accessibility, javax.print[.*] (only SPI), (parts of) javax.swing, javax.swing.colorchooser, javax.swing.undo

J2SE 1.4 (Desktop), lots of work needed (but getting there)

java.awt.font, java.awt.im[.spi],
java.nio.charset (service providers)

javax.imageio[.*], javax.print (service providers), javax.rmi[.CORBA],
java.security.auth[.*], javax.swing[.event,
.filechooser, .plaf.basic, .plaf.metal, .plaf.multi, .table,
.text, .text.html, .text.html.parser, .text.rtf, .tree], org.omg[.*]

Current state – Others

Various standard packages

No formal compliance with any specification

javax.sound

Service providers for
ALSA, esd, lame, ogg

Tritonus Project

javax.crypto

Service providers for
many crypto algorithms

GNU Crypto

java.util.regex

GNU regex

javax.activation
javax.infobus
javax.mail
javax.servlet

javax.xml (GNU JAXP)

GNU Classpath Extensions

javax.speech

Text-to-Speech
(no recognition)

FreeTTS

javax.net
javax.net.ssl
javax.security.cert

SSL/TLS Support

Jessie

Integrated

Integrated

Integrated

GNU JAXP

Being Integrated

Current state - “Enterprise”

J2EE 1.4 (Server)

Multi-tier stack: web services/enterprise computing

Multiple “free” implementations: JBoss.org, Jonas

Needs some work to combine it all

Conformance: Lots of politics

Service providers for some of the interfaces mentioned earlier:

javax.activation, javax.ejb[.spi], javax.enterprise[.*], javax.jms,
javax.mail[.*], javax.management[.*], javax.resource[.*],
javax.security.jacc, javax.servlet[.*], javax.transaction[.xa], javax.xml.*

Current state - Beyond the “standard”

Support for multiple other programming languages

GNU KAWA: Scheme, Common Lisp, eLisp, ECMAScript, ...

Jython, JRuby, Rhino (javascript)

Traditional free libraries with Java bindings

GTK+, GNOME, glade, gconf, vte, ...

Is part of the official language bindings
since GNOME 2.6

GNU gettext, getopt, readline, ...

Lots of stuff on sourceforge.net and jakarta.apache.org

“Open Source”, but often doesn't work or integrates with the Free Software stack that much (slowly changing now).

The Future

The road to GNU Classpath 1.0

Will be the common “free java” core (One glibj to rule them all)

If it compiles against GNU Classpath glibj, it should just work on all free systems (GCC 4.0 will be important – everybody ships it).

Aiming for start of next year.

Package/Feature freeze next month

Drop unfinished parts in December

Polish in January

Does need help (Current plan seems “outrageously unreasonable”)

The real fun will be

java-gnome, strong integration with freedesktop.org, GNU platform.

The “pain” will be

Escaping the Java Trap

How you can help

Help is greatly appreciated

Port and test free java programs on free systems

Write test cases for Mauve

Write intellegible documentation

Implement library classes

“Standard”

Integration
(gnu, gnome, freedesktop)

Write new applications

Fund development

How to proceed

Look at the task list:
http://www.gnu.org/software/classpath/ Both easy and tricky tasks

Ask us for details:
classpath@gnu.org

Visit irc.gnu.org #classpath

Read Planet Classpath:
http://planet.classpath.org/

Happy hacking!

2004-11-22T22:30:44