GNU Classpath/Escher and GSoC
First of all, most of my posts will now be written on English. After all, the main reason for this change is to reach a higher number of users, as English is considered the universal language these days. The other reason is that I’m currently participating on Google Summer of Code for the GNU Classpath project. I’ll post here my progress on the program, including achievements, solutions to problems and future ideas. So to start off, I’m going to present you what is and what I’m doing for GNU Classpath.
GNU Classpath is a free software implementation of the Java standard library. Ok, what does that means? It’s a implementation of the standard Java API, things like Swing, Socket, Math, FileOutputStream, RMI and so on. It’s not a Java Runtime, i.e., it’s doesn’t do memory management, security, etc. The Java Runtime uses these class library to run the application. A full JVM according to Sun/Oracle standards is the sum of the class library and these runtime algorithms. Since the JVM is majority written in Java (classlib) the runtime implements very low-level things in C, like garbage collection.
Now a brief history of GNU Classpath. In the old days there were a bunch of FOSS projects that had a implementation of the runtime and the standard class library. Since each project implemented the same classes over and over, this turned out to become a incomplete and redundant implementation of the standard class library. So they united their efforts to produce ‘one’ class library, which is GNU Classpath. And they all implemented their runtime algorithms to manipulate this library. Cacao, Jikes, JamVM, Jamaica, IKVM, all this and others free JVM’s are used with GNU Classpath.
“Revive and Restructure the Escher project”. This is my GsoC task/proposal title. So what is this Escher? What’s the relationship with GNU Classpath? Escher is basically a client for the X Window System (X11) written entirely in Java. It was started and developed by Mario Torre (my mentor), Roman Kennke and Stephen Tse, they are all nice guys. Back to the story, inside GNU Classpath we have various graphics peers, including GTK, Qt and XPeer (which uses Escher). They all send requests to a X Server, when they are demanded to draw something, such as a Box or a Font. The Gtk is the default peer, Qt and XPeer is also dead. The thing here is to revive XPeer which basically means reviving Escher also, since both projects are intimately related. But why XPeer, what does it have that the other peers don’t? It’s because XPeer communicates directly with a X Server standalone. This is useful specially on a embedded scenario. These devices usually, almost all ways, doesn’t have a Gtk/Qt-Peer. So I’ll be doing a synchronization with the development of GNU Classpath, refactoring XPeer and Escher with design patterns and also start decoupling Escher for other back-ends, such as DirectFB. The coolest part is that GNU Classpath is on various architectures ranging from ARM to SPARC so we can manipulate graphics on all these architectures.
I’m very anxious/excited with GSoC. My mentor (Mario Torre) is really cool and he is very patient on teaching (he the most patient/kind FOSS developer ever!). He’s also the most badass developer that I’ve seen😀. The other guys from the channel are all kind/patient too. They are all awesome! I’m really excited with GNU Classpath/Escher with these guys! Tomorrow I’ll post more of what I’ve already done (this is the first week of coding), including the patches for synchronization, some refactoring and the repository that I’m using. From now on I’ll post here my progress🙂.