Marcos Roriz $:

Pessoal, Geek, Anime, Jogos, Ciência da Computação e Open Source…

Archive for the ‘GNU Classpath’ Category


leave a comment »

Hello guys, sorry for the lack of updates, been a busy week here.
The progress so far is that I’m ending up the refactoring in Escher (already finished the core java pkgs) which lend me changing almost all classes in XPeer @ GNU Classpath, I’m waiting right now to submit this patch and some review of my mentor (Mario Torre) so I can make it a best refactoring.
So far:

  • Reintegrated Escher to XPeer @ GNU Classpath (First task)
  • Refactored Escher (Almost finishing)
  • Next → Generate the protocol code in a description way (Mario Torre gave the huge cool idea in generating on @nnotations :D)

One of the things that I changed in XPeer too was the lazy connection. IMHO there is no need to wait for someone to getDisplay() to make all the overhead of connecting to the Xserver. Since usually after the instantiation of the Xtoolkit class there will be use it I did the start right ahead. This change made *somehow* the start of the gui way faster. Am I missing the reason behind lazy connection?

Written by marcosroriz

July 3, 2010 at 6:57 pm

GSoC Updates

with 2 comments

First of all I would like to apologize for my lack of attention with GSoC this week it was basically because my university (UFG) sent us to a coding week in other one (UFPB). To make that time lost up I’ll work double until the program end. I’ll everyday post here about what I’m refactoring and how I’m doing this stuff, and how I’m applying the corrections that Mario Torre is giving me. So to not lose some time I’ll post today some basic AWT Relationship (which explains Escher) and the class refactoring that I’m working right know (gnu.x11.Display).

AWT Relationship

Java has by default at least one AWT (Abstract Window Toolkit) implementation, which enables various ways to manipulate GUI in general (graphics/events). Everything starts with Toolkit which is a abstract class that defines the basic functionality of a rendering kit, that is a AWT. To add extra functionality GNU Classpath subclass the Toolkit into ClasspathToolkit which basically add extra methods for extra information, such as, getting all truetype fonts available on the system. The same process, sub-classing and adding extra methods, happens on OpenJDK but is called SunToolkit.

Now we need peers to make the communication with the toolkit (Gtk, Qt, X11) and Java. We basically have a bunch of implementation making calls to their respective peer, usually using JNI to call the C/C++ code. The X11 toolkit is special in a sense that it doesn’t need a full desktop environment to run, it needs only a X11 Server. Escher is the implementation of the X11 peer written totally in Java. It send and receive requests from the X11 Server and repass to Java. Since Escher is written totally in Java and the X11 peer don’t need a full desktop environment it makes perfect sense to use it on a embedded device that needs a low memory footprint. To sum up Escher like any X client can handle extension, in fact it already implemented the famous GLX extension which allow a client (application) to use OpenGL inside a X11 window.

AWT <--> Escher Relationship

Tomorrow I’ll bring some of the refactoring that I’m doing…

Sleeeeep ZZZZzzzZZ

Written by marcosroriz

June 14, 2010 at 1:27 am

GNU Classpath/Escher and GSoC

with one comment

Hello everyone,

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.

GNU Classpath Logo

GNU Classpath Logo

“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 :D. 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 :).

Written by marcosroriz

May 31, 2010 at 1:26 am