Talking about gcj on the desktop. He works at Red Hat on all sorts of java stuff.

Intro to GCJ. GCJ takes java source and turns it into object code. It can then be run with the gcj runtime. Provides runtime services, class libraries, interfaces to native code.

GCJ can convert source -> bytecode, source -> native, bytecode -> native, jar file -> native library. libgcj is a large DSO somewhat like libstdc++. Uses G++ linkage model. Uses boehm-gc. Threading, type checking, security model and a bytecode interpreter. The fact that it has a bytecode interpreter is note widely known. No JIT compiler yet, though. Performance is pretty good, though, because lots of the libraries are native compiled so only app code is interpreted.

The GCJ managed runtime: uses classpath. Mostly merged, except for some low level stuff. GUI stuff is completely shared, I/O, etc. Natlively compiled java programs link to libgcj. C++ apps that want to have a managed runtime, you can just link to libgcj and it gives you an invocation API. gij is an example of this program. Like the java command. It can also load shared libraries, not just .jar files.

Current work to get compatibility with current java runtime. Packagin, binary compatibility. AWT, swing, other graphics.

Packaging problems: using the jpackage.org conventions. Relies on JPackage JVM interface. Currently only available on propietary JVMs. Uses alternatives for switching between JVMs. GCJ-JPackage aims to be a free alternative to the proprietary interface. Currently rpm-based, but debian is talking to them too. Good test of the GCJ interfaces.

Binary compatibility. Need to support chapter 13 of the java lang spec. This is the ABI spec. Restrictions like java API changes that result in ABI changes, etc. The C++ linkage makes this impossible. Moving away from that and moving to a new model. Solves a lot of other problems, too. Lets them run big apps like jonas (custom classloaders, etc.) Decouples the compiler from the runtime. Means you can remove the dependency on the gcc release cycle. Gets faster startup times and reduce memory usage as well. Should be in GCC 3.5.

AWT: this is sun's first attempt at a toolkit. AWT is old? Not really. Is the low-level base for swing. Many existing applets still use the AWT. It has a peer-based design. Our implementation uses Gtk widgets as peers.

Can run small applets. Not larger ones, too many bugs. Most components are done: text fields, buttons, panels, etc. Image handling is done. Graphics and the event system including focus handling.

Thinks that still need to be done: bug fixing. Need to migrate from gtk 1.2 -> 2.4. Some gtk and metacity work. i18n needs work including java imput methods or native methods. Accessibility. X Clipboard interaction. DND. GraphicsEnvironment implementation. And an API conformance test suite.

gcjwebplugin: web browser plugin for java applets. Runs as a netscape 4.x plugin + xembed support. Out of process. [ Demo - looks nice ]

swing: widgets are "lightweight" which means they handle their own painting. Can use the java drawing or 2D drawing - we implement both. Uses java.awt.Graphics using GDK or java.awt.Graphics2D using Cairo. Current swing impl can use either.

It's come a long way in a year. Many widgets are complete. Several big widgets are not yet complete. Things like HTML rendering are hard. And text handling. Plan on using existing infastructure wherever possible. (GTK, freetype, pango, etc.) But lots of code left to write. [ More demos. Things are slow, but work. Laptop is old. ]

The java-gui-branch. It's a branch in the gcc repo. Known-good compiler that doesn't change. Liberal commit policy. Temporary build bustage is OK. Patches for reducing compilation time. Works well with jhbuild. Almost all Red Hat driven. Things are improving and patches are coming in from the community as well.

Using jhbuild for gcj development. Makes things a lot easier. Builds dependencies. Makes it easier for the GNOME and GCJ folks to work together. And with the Java-GNOME folks.

Java-GNOME. They use GCJ for their builds. Allows an interface to the gtk and gnome libraries. Use java native interface. All the current interfaces are wrapped. They can finally use the current gcj to build _all_ bindings. Has a very active community! [ More demos. ]

Merging the silo. Some good desktop projects that would be nice: gconf backend. A gtk pluggable look and feel for swing. Sound wrappers that use gstreamer. Java wrapper for dbus.

Advantages of using libgcj: flexible managed runtime. libgcj can mix native code and bytecode seamlessly. Good for plugins or prototyping. You can use all the tools in the standard development toolchain. You can use gdb or valgrind. It's also cross-platform. GCJ supports all the hosts the GCC supports. You can debug with native parts because GDB supports GCJ. Relatively small footprint. Shared libraries avoid every copy of the code. Speed: gcj-compiled code is comparable of faster than other state of the art execution models for the java programming language. CNI - smooth interaction between Java and C++. Very nice to use.

Havoc is talking about platforms and what he thinks defines a platform. Talking about "silos." That is, stacks of platforms where things work well together, but don't work well outside of that silo. i.e. windows, vs. linux vs. qt vs. gnome, etc. Platforms define technology and policy. Not just mechanisms.

Platforms aren't complete. They don't abstract everything yet. Don't define UI guidelines enough, high level design issues, types of data storage and the exchange of data between applications.

Web is a different kind of platform. Pushes a lot of the platform to the server. Simplifies everything for everyone but the user. No UI guidelines, applications (backend) don't interact well. Can't share data.

What defines platforms - could be plugins, could be other things. X has a pretty low set of constraints, text editor plugin would be pretty constrained. GNOME and KDE both have a pretty big set of contraints. The line is blurry.

Trying to define platforms vs. plugins. Modular interaction design sucks. GNOME control center, X Window System apps. Windows mess of tray icons, menu items, desktop shortcuts, etc. Plugins rarely use the latest platform features because they only use the ABI that's most recent. ABIs take a while to get out there and then other parts of the platform lag.

Talking about implementation vs. interaction. User interfaces should be monolithic and hard coded, even though programmers rarely think that way.

Interaction designers are interested in "user-interesting first-class objects." Email, people, conversations, documents, appointments, etc. How will these be exported? How will apps share that information? WinFS enables this, but unclear how it will be exported to users.

Improving the desktop: focus on internet storange and internet use. Saving people from becoming system administrators. Include more functionality in the platform.

Two visions for the desktop: one is to copy the windows platform and just make it open source. Linspire, etc. Create an alternate platform on its own terms. We can do both or either. Odds are we will do both, because it's open source and people are going to do whatever they want.

Asking why users would reject longhorn? Like what they have already. Don't want to change. Longhorn's improvements doesn't offer the improvements that they need.

Havoc's Final Thoughts: Easier to win on user value than it is to match technical castles of unbounded size. Open source manages to both at the same time.

freesktop.org and X.org are building a platform substrate for beneath toolkits. Tends to be similar to the windows style platform. Any platform has to be able to run windows-style platform.

freedesktop.org doesn't show any signs of moving beyond the substrate layer. i.e. tried to make a UI guideline list. Didn't go anywhere.

freesktop.org seems good for mechanism, not policy. "Substrate not platform." However, mechanisms do contstrain policies. However not the same as some ambiguious policy.

Making incremental gains. Sharing more than one item does add value. Sharing an item with one more silo adds value. Have to be pragmatic and improve what we can.

Code sharing can be done via opportunistic refactoring. Create opportunities. Write things to be shared. Don't rely on your own silo. Sometimes a little work gets a large refactor off the ground.

Holy grail would allow object sharing with wild abandon. Design: if we could bring together some of the silos in terms of design, it would help a lot. Requires a single point of decision-making. May also require a unified release cycle and willingness to depend on latest and greatest.

Platforms are designed together, not stuff that shares code. Merging desktops means merging design, not implementation. The OS, including the kernel, currently counts as a seperate platform. A lot of the rhat desktop team is currently working on "base OS" issues because a lot of the user-visible problems are in that part of the platform, not in the "desktop."

Distributions or upstream? We can wedge patches at the distro level (rhat), because we have The Power. Upstream components still look broken out of the box. Distributions and desktop fragments. Need to move some of this upstream. One unpopular way is to pick a silo. This happens, but it's not good.

The Future! Building an official freedesktop.org platform substrate should be acheivable and valuable.

Design divergence isn't going away. We'll loose our windows-like look, even if just because windows keeps changing. Contains backwards compatibility, but it looks different and new apps will use the new look. Each silo will probably try to suck in more and more apps to enhance user experience via centalized design.

Parting shots. Diverge on goals, not implementation details. Don't implement font rendering twice. Divergence is solved through natural selection. We hope that goals-level discussions bring silots together. Innovation has to start in a single silo, but can trickle into others.

I found some really old spam when I was cleaning out my inbox today that contained this gem:

    Human Brain Software

    Human brain software can completely solve the question as follows:

        1. The motive force of human evolution;
        2. Human clock system;
        3. Human Intellectual Genes;
        4. DOS system and Windows system about human brain;
        5. Origin and prodiction of human talent;
        6. How to monopolize world soccer markets in the future.

    Notes: To monopolize world soccer markets is only a sort of
    measure or evidence.Its goal is to prove my human evolution theory
    with it.

I've been spending the last few days going back and forth with Owen about word spacing and justification. Not sure if that's going to make the next pango release so I guess it's up to me to just support Mozilla's crazy per-character spacing methods for font rendering. Getting this working with bidi is going to be fun fun fun.

I've also been reading a lot of the layout code and bugging the crap out of the poor layout folks. Scary thing is, I'm starting to understand some of how layout works. And it's not nearly as scary as I thought it was. Huge, complicated, but it all kind of makes sense.