Marcos Roriz $:

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

Archive for the ‘Java’ 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

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

ClassLoader desmitificado.

with 3 comments

Até recentemente não dava muita importância no funcionamento da estrutura interna da plataforma Java até quando tive problemas que o Google não conhece. Para resolver meus problemas tive que mergulhar a fundo no interior da JVM. E apesar de ter vários materiais na rede é complicado compreender o linguajar e o funcionamento interno da mesma. Para começar entender o funcionamento do seu programa dentro da Máquina Virtual Java (Java Virtual Machine – JVM) é necessário compreender o coração da JVM  o ClassLoader (CL). De maneira simples, um CL é uma estrutura que tem como responsabilidade o carregamento dos seus bytecodes (.class). Cada ClassLoader contém o que ela pode carregar no seu classpath específico, isso é, o endereço (diretórios) das classes. Um classpath pode conter vários diretórios, sendo assim o CL irá procurar a classe no primeiro diretório especificado, se não achar irá pro segundo, assim suscetivamente até acabar a lista de diretórios do classpath. Porém o mais importante é entender como o CL carrega as suas classes e como ele é organizado internamente.

Antes de mais nada é necessário explicar que um tipo (classe) em java é identificado pelo seu nome e seu CL. Ou seja um objeto da classe Folha de CL 0x2bbd86 é diferente de um objeto da classe Folha de CL 0x813b2 pois apesar de serem da mesma classe esses possuem CL diferentes. O java faz isso para garantir a consistência de objetos internamente na JVM. Pois caso contrário poderia ocorrer um conflito entre um objeto Folha que representa uma árvore e sua atribuição a um objeto Folha que representa uma folha de pagamento. Ou seja, objetos originados de uma classe de mesmo nome pode não possuir estruturas idênticas.

Também é importante entender o processo chave de carregamento de classe, a delegação. Um ClassLoader possui ClassLoader pais e sempre irá fazer o seguinte:

  • A Classe sempre irá pedir a ClassLoader que o carregou para carregar suas dependências;
  • ClassLoader sempre irá delegar o carregamento da classe ao seu pai, para verificar se o mesmo quer carrregar a classe antes.

Agora iremos explicar a hierarquia dos ClassLoaders. Quando a JVM inicia ela não possui nenhuma classe carregada. A JVM usa o mecanismo de carregamento de classes conhecido como lazyness, preguiçoso, a JVM vai carregando as classes conforme é necessário. Porém existe um problema, o código que carrega uma classe é o ClassLoader que em si é uma classe em Java, se a JVM não possui nenhuma classe carregada como é que ela vai carregar as outras classes pois conforme a especificação Java uma classe só é carregada quando todas as suas dependências forem carregadas. Conforme novamente a especificação Java, ClassLoader herda de Object que em si deve ser carregado por uma ClassLoader o que leva a um dead-lock. A solução para isso é ter um ClassLoader que de fato não é escrito em Java e sim em código nativo. Esse CL nativo irá carregar as classes ClassLoader, AppClassLoader e ExtClassLoader. A árvore de CL é a hierarquia formada pelo agrupamento dos mesmos. Por padrão temos a seguinte hierarquia:

Hierarquia de ClassLoaders

O BootStrap é o CL nativo executado pela JVM o seu classpath encontra as classes do sistema, principalmente o runtime do Java. O ExtCL (Extension ClassLoader) tem como seu classpath frameworks ou aplicativos específicos do usuário, caso queira que esses sejam visíveis em toda a VM. O pai do ExtCL é o BootStrap. E por fim o AppClassLoader que é o CL que irá carregar sua aplicação e seu classpath é o especificado no manifest do jar ou o passado na linha de comando, e o pai desse é o ExtCL.

Faremos uma aplicação para demonstrar os conceitos vistos:

public class Info {
	public static void main(String args[]) {
		System.out.println("Boot class path: " + System.getProperty("sun.boot.class.path"));
		System.out.println("Extension class path: " + System.getProperty("java.ext.dirs"));
		System.out.println("AppClassPath: " + System.getProperty("java.class.path"));

		Info i = new Info();
		System.out.println("\nBoot CL: " + java.lang.Object.class.getClassLoader());
		System.out.println("App ClassLoader: " + i.getClass().getClassLoader());

Resultado obtido:

[marcos@hades AUR]$ java Info
Boot class path: /opt/java/jre/lib/resources.jar:/opt/java/jre/lib/rt.jar:/opt/java/jre/lib/sunrsasign.jar:/opt/java/jre/lib/jsse.jar:/opt/java/jre/lib/jce.jar:/opt/java/jre/lib/charsets.jar:/opt/java/jre/classes
Extension class path: /opt/java/jre/lib/ext:/usr/java/packages/lib/ext
AppClassPath: .

Boot CL: null
App ClassLoader: sun.misc.Launcher$AppClassLoader@19134f4

Desse resultado podemos claramente ver o que foi explicado, o classpath do BootStrap é o “SDK” do Java, o do ExtClassLoader é o diretório de extensões e o da AppClassLoader é o passado no argumento na cli, caso não tenha sido passado ele assume que é o diretório local: ., ou lido do manifest do jar. E também vemos que quem carregou nossa classe principal foi o AppClassLoader. Também vemos que o bootstrap CL é representado por null.

Bem você já deve ter adivinhado por agora que somente esses três CL são pré-definidos sendo assim nós podemos adicionar e alterar classloaders nessa árvore. Isso garante flexibilidade e isolamento de código, algo muito utilizado em Servidores de Aplicação como o JBoss e Glassfish. O servidor vai isolar cada requisição criando classloader de modo que uma requisição não seja visível na “árvore” a outra, isso garante uma robustez e segurança muito grande a plataforma.

Outro grande exemplo da manipulação de classloaders é o escopo estático de uma variável. Uma variável tem seu escopo estático, isso é, visibilidade, do CL  que foi carregado pra baixo. Vejamos um exemplo abaixo:

public class EscopoEstatico {
	public static int instanceCount = 0;
	public EscopoEstatico() {
		System.out.println("Valor da instancia:" + ++instanceCount);

	public static void main (String args[]) throws Exception {
		new EscopoEstatico();
		// Vamos criar um Cl novo e colocalo abaixo do bootstrap
		// Consequentemente a variavel static vai ser diferente lá
		// do que a especificada.
		URL urlArray = {new File(System.getProperty("user.dir")).toURL() };
		URLClassLoader cl = new URLClassLoader(urlArray, null);


[marcos@hades AUR]$ java EscopoEstatico
Valor da instancia:1
Valor da instancia:1

O que fizemos pode ser visualizado na imagem abaixo:
O problema é que a variável estática não está definida no caminho definido pelo o outro CL, então é considerado um novo “escopo”.

Então um dos problemas que pode surgir é, dado que eu carrego uma requisição em classloaders diferente e de modo que os mesmos não tenham nenhum CL em Comum, todos sejam filhos de null como garantir a visibilidade dó código ao longo da JVM? Bem o que sabemos é que todos diretamente ou indiretamente tem um CL em comum, o CL bootstrap (null). Porém esse CL só carrega os runtimes da plataforma Java, por padrão. Poucos sabem que podemos editar, adicionar, sobrescrever o classpath do BootStrap. Você pode até mesmo sobrescrever a implementação de uma classe que não gosta do JDK, como a implementação da pilha, etc. Concluindo, a ideia é estender os jars visíveis a este adicionando os arquivos que você queria que seja visível na JVM inteira. Isso é feito utilizando as opções X (extended) da JVM.

[marcos@hades AUR]$ java -X
    -Xmixed           mixed mode execution (default)
    -Xint             interpreted mode execution only
    -Xbootclasspath:<directories and zip/jar files separated by :>
                      set search path for bootstrap classes and resources
    -Xbootclasspath/a:<directories and zip/jar files separated by :>
                      append to end of bootstrap class path
    -Xbootclasspath/p:<directories and zip/jar files separated by :>

Como disse anteriormente você pode sobrescrever (-Xbootclasspath) ou adicionar no começo (/p de prefix) ou no fim (/a de append) jars ao classpath do Bootstrap. Você pode até mesmo sobrescrever classes do JDK. Vejamos um exemplo abaixo:

Copie o arquivo do source do jdk (java/lang) e modifique seu construtor

public class Integer {
    public Integer(int value) {
		System.out.println("Vou dividir seu int por 2, pq sou mau =P");
		System.out.println("VALOR ANTES: " + value + " VALOR DEPOIS " + value/2 + "\n");
		this.value = value / 2;

Crie um diretório temporário, como ~/temp e também crie ~/temp/java/lang. Note que ~ representa o diretório home do usuário.
Compile o arquivo e copie o seus .class’s para o seguinte diretório, ~/temp/java/lang.
Agora vamos fazer um simples teste.

public class Teste {
	public static void main(String args[]) {
		new Integer(33);

Compile e coloque esse arquivo no diretório ~/temp.
Agora execute a seguinte linha de comando:

[marcos@hades AUR]$ java -Xbootclasspath/p:. Teste
Vou dividir seu int por 2, pq sou mau =P

Vou dividir seu int por 2, pq sou mau =P

Vou dividir seu int por 2, pq sou mau =P

Vou dividir seu int por 2, pq sou mau =P

Vamos chamar agora sem modificar o classpath do bootstrap:

[marcos@hades AUR]$ java Teste

A própria JVM quando inicia executa algumas chamadas criando novos Integers, como podemos ver. Porém o grande resultado é que vemos que o diretório atual, representado por ., foi pré-fixado na classpath do BootStrap e não foi chamado o Integer normal do JDK. Isso garante uma flexibilidade enorme, pois podemos facilmente alterar qualquer implementação não desejada do JDK. Alguns hackers modificavam versões da classe System pois o método getEnv de pegar o PATH do usuário foi depreciado antigamente e não era possível chama-lo até recentemente (acho que adicionaram denovo no jdk 1.5-1.6). Porém a ideia principal é que podemos facilmente garantir uma classe escopo global na JVM colocando seu jar ou .class na lista de classpath do BootStrap.

No próximo tópico irei postar algumas modificações, manipulações e resultados de brincar com os classloaders.

[1] Java Geek, Using the BootClasspath –
[2] Inside the Java Virtual Machine – Bill Vernes – The McGraw-Hill Companies (1997)
[3] Inside Java™ 2 Platform Security: Architecture, API Design, and Implementation, Second Edition By Li Gong, Gary Ellison, Mary Dageforde

Written by marcosroriz

December 16, 2009 at 8:00 pm

Posted in Ciência da Computação, Java

Tagged with ,