Hello guys, well when I applied to Google Summer of Code I had no idea on how it was going to change my life. So far not only I have been learning new things, but also meeting awesome developers. The climax of this was when we (brazillian students) asked for a small financial help to Google to take us to FISL (Forum Internacional de Software Livre – International Free Software Forum) in Brazil. Google did the amazing favor to help us so that we can learn/spread free software to others. We are in huge debt with them, and we’re amazed by their concerns about free software ideals. We managed not only to meet there (#gsoc-br) but also we managed to meet excellent FOSS developers there and had a lecture about the GsoC experience in FISL.

There I met the remaining gsocers, we shared our difficulties and we exchanged tips on how to solve problems. They all joked on me, :/, when I said that I preferred svn over dscm, like git or mercurial. But at the same time they gave me a very brief and informal talk/introduction to git (which I’m kinda liking :D). I talked also a lot about X and XCB with friend and hackers there since it’s directly related to my proposal.

GSoCers

I had a chance to meet some badass developers (like ‘Maddog’) and get amazing talks (like Glassfigh in OSGi bundles and What’s new on OpenJDK 7). I took some photos and the most cool was with the GNU.

Overall, It was a amazing experience, and I want to thank again Google, specially Carol (which is so kind =]), all the cool guys there (FISL) and my mentor Mario Torre (which understand that I’m a little behind but getting up the schedule now =).

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?

This method is part of the Misc class (which contains ‘handy’ methods for vector/graphic manipulation). So the question is, while this method does have it’s meaning in the program it’s not used anywhere on it. And to complicate it more the ‘same’ method with a different argument (3 dimension array) is used in the code. Should I remove it the unused??? I’m not totally sure but I think if they are not used we should remove it >_<‘. And that what I’ll probably do on my next commit. What you guys think? Should I keep or delete? :3

Other problems is that in general the classes uses a lot of public and static variables/methods, I’m doing some basic encapsulation on it. Also my next commit will include a revision/refactoring of the glorious gnu.x11.Display class with it’s > 1.4k lines of code. After I finish it’s refactoring the other classes will be easier, since they are usually < 200 lines of code. After classes refactoring is done is time to start going for the parser to generate automatic X11 code, the coolest part!

To sum it up I also received the confirmation that I can now commit oficially to GNU Classpath, so now I can submit code to XPeer there ^_^. Mr. Donald R. Robertson, III, J.D. sended me the confirmation. I’m honored to be able to contribute to a GNU project :]

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.

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

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