quarta-feira, 20 de fevereiro de 2013

Compilando arquivos Java via código

Para compilar arquivos Java via código é extremamente fácil:

JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
int result = compiler.run( System.in, System.out, System.err, "SeuArquivo.java" );
if ( 0 == result ) {
System.out.println( "Compilado!" );
}

A saída do processo de compilação é realizada na System.out e na System.err. O retorno sendo zero, indica sucesso na compilação.


Dica: Para usar esta classe, certifique-se que você está usando o compilador da JDK e não da JRE. As classes estão no pacote /lib/tools.jar da JDK, que não exise na JRE. Caso você precise, pode usar a minha dica anterior, para carregar este arquivo Jar dinamicamente. Para não ter que montar o caminho de seu JAVA_HOME manualmente, pegue-o da propriedade java.home do objeto System:

String toolJarPath = "file:///"
+ System.getProperty( "java.home" ).replaceAll( "\\\\", "/" )
+ "/lib/tools.jar";

segunda-feira, 18 de fevereiro de 2013

Carregando JARs dinamicamente

Para carregar arquivos .jar dinamicamente e depois acessar uma de suas classes, você pode usar a java.net.URLClassLoader, passando para ela um arquivo usando o protocolo jar e usando !/ ao fim da string. Por exemplo:

String jarPath = "file:///C:/dev/Java/jdk1.7.0_05/lib/tools.jar";
String className = "com.sun.tools.javac.api.JavacTool";

try {
// Monta a URL com o protocolo JAR e !/ ao fim do caminho do seu arquivo.
URL url = new URL( "jar", "", jarPath + "!/" );
// Configura o loader para carregar o JAR
URLClassLoader loader = new URLClassLoader( new URL[] { url } );
// Carrega sua classe
Class< ? > clazz = loader.loadClass( className );
System.out.println( "Carregada: " + clazz.getName() );
} catch ( MalformedURLException e ) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch ( ClassNotFoundException e ) {
// TODO Auto-generated catch block
e.printStackTrace();
}

Com isso, você pode, por exemplo, tentar carregar dinamicamente algum Jar usado para fazer uma conexão JDBC, sem precisar colocar todos os arquivos de vários bancos de dados em seu projeto. Fica a dica…

quinta-feira, 14 de fevereiro de 2013

“Super Wi-Fi”

O “Super Wi-Fi” (já explico o motivo das aspas), ou IEEE 802.22, deve sacudir o mercado dos provedores de Internet em breve. Por que? Um roteador igual ao da sua casa, mas com ele, cobrirá uma distântica de até 30 km! Vai chover amigo seu querendo rachar a conta de internet, pegando um plano mais caro, mesmo que seu amigo more um pouco longe… Alegre E (falando sério) vai, principalmente, facilitar o acesso das pessoas em áreas rurais.

Wi-Fi ?

O IEEE 802.22 não é Wi-Fi, mas o nome “Super Wi-Fi” acabou pegando. Em casa, atualmente, geralmente usamos uma versão do protocolo IEEE 802.11 (ex: 802.11 g) e o termo Wi-Fi, que é uma marca registrada da Wi-Fi Alliance (uma associação sem fins lucrativos, composta por mais de 500 empresas) para o IEEE 802.11, é comumente usado para ele. Como todo mundo entende quando você fala “wi-fi”, mas nem todo mundo (exceto seus amigos nerds) entende quando você fala “IEEE 802.11”, você já sabe porque o “Super Wi-Fi” pegou…

Abrangência

O roteador 802.11 que você usa em casa roda na faixa dos 2.4Ghz, a mesma do Bluetooth (IEEE 802.15) e de muitos telefones sem fio (aliás, se estiver pra comprar um, procure o que usa outra frequência). A abrangência do sinal destas redes é pequeno, geralmente se limitando à uma rede local (LAN) ou  pessoal (PAN). O WiMAX (IEEE 802.16), por exemplo, já cobre uma área maior, e já é considerada uma rede metropolitana (MAN). Já o 802.22, cobre uma rede regional (RAN?), maior que uma rede metropolitana. Sim, maior que a abrangência do WiMAX 3G ou 4G. (E isso me faz pensar seriamente em ligar pros meus amigos usando essa rede, ao invés da usada pela minha operadora de telefonia…).

A Mágica, seus Problemas e Soluções

Funcionando na faixa de frequência abaixo de 1Ghz, como a da sua TV, é que torna-se possível o sinal ir tão longe (como mencionei, até 30km). O principal problema, como você já deve ter imaginado, é a interferência. Pra começar, qual frequência abaixo de 1Ghz usar? Ela vai colidir com o de algum canal? Enquanto isto não é definido pela Anatel, não há resposta definitiva. Será preciso esperar a transição da TV analógica para a digital e, provavelmente, o acordo com as operadoras de telefonia. As faixas que sobrarem (regulamentadas) poderão ser usadas livremente.

Mas aí, como saber a melhor faixa a ser usada? Quem deve decidir isso será seu roteador. Provavelmente ele analisará as frequências sendo usadas (onde você estiver) e irá decidir qual a melhor.

Barateamento

Para os provedores da sua cidade será muito bom. Licença pra cabear, custo de cabos, mão-de-obra, …, nada mais disso será necessário. Com algumas antenas poderá ser feita a cobertura de uma cidade pequena praticamente por inteiro. Locais onde não pegam a internet hoje, ou nem mesmo chegou telefone, poderão pegar o sinal que vêm das áreas centrais. Isso sem o provedor precisar instalar um cabo.

Mas e o custo para nós, usuários finais? Em tese, tenderia a cair. Porém, será preciso saber como o provedor fará para controlar o compartilhamento da rede de seus usuários. Talvez não controle, mas cobre mais caro pelo tráfego (leia-se valor por Gigabyte trafegado). Se isso acontecer, ele mesmo irá incentivar os usuários a “rachar” o custo… Há também o fato de que muita gente acaba usando determinado provedor porque o outro não chega no local onde mora. Com a ampliação da cobertura, a concorrência ficará mais acirrada, o que pode pressionar os preços para baixo.

O que deve vir depois

Após o 802.22 deve aparecer o 802.11ac, conhecido também como Very High Throughput (VHT). Esse sim, dizem, será realmente um Super Wi-Fi, suportando transferências de 1Gigabit/segundo. Parece muito, certo? Mas pense que hoje as pessoas estão procurando ver imagens em HD e estão aparecendo as resoluções Ultra HD, com 4K, 8K e (impressionantes) 16K. Haja compressão de dados… porque sem ela, a VHT não daria nem pro começo. É aquela velha história… mais banda pra usar, maiores dados pra trafegar…

sábado, 9 de fevereiro de 2013

No meu GitHub

Há uns meses criei uma conta no github, onde havia postado algumas bibliotecas de código C++ e PHP. Aos poucos pretendo ir adicionando bibliotecas, projetos e exemplos de código, usando também outras linguagens, como Java e JavaScript.

Na minha última atualização na php-util, por exemplo, adicionei um arquivo invoker.php, que permite invocar métodos PHP parametrizados numa requisição HTTP. Por exemplo:
<script type="text/javascript" src="jquery.js" ></script>
<script type='text/javascript' >
var data = { _c : 'SomeClass', _m : 'someMethod' };
var showResponse = function( response ) {
alert( 'Success: ' + response.success
+ ' Message: ' + response.message
+ ' Data: ' + ( response.data ? response.data : '' )
);
}
$.post( 'invoker.php', data, showResponse, 'json' );
</script>

Será enviado para o invoker.php os parâmetros _c e _m com, respectivamente, o nome da classe e do método desta classe a ser invocado. O arquivo que contém a classe será automaticamente incluído, uma instância da classe criada, seu método invocado e seu retorno obtido. Sendo a execução realizada com sucesso ou não, o resultado será serializado como JSON e enviado de volta para o cliente encapsulado em um objeto Response.


Continuando com o exemplo acima, será invocado o método someMethod de uma classe SomeClass. Se esta classe for simplesmente definida como a abaixo, a string "hello" será retornada para o cliente.

<?php
class SomeClass {
function someMethod() {
return "hello";
}
}
?>
Então, será enviada uma resposta para o cliente (em JSON) como:
{ "success" : true, "message" : "", "data" : "hello" }

Isto permite automatizar coisas repetitivas, como criar um arquivo PHP simplesmente para invocar o método desejado e obter seu retorno como JSON. O encapsulamento da resposta ao cliente sempre realizada através de um objeto de Response permite padronizar a comunicação, tornando mais fácil extrair os resultados das requisições.


Por exemplo, pode-se invocar um método de uma classe controladora que irá obter os parâmetros enviados (via POST) de um formulário e salvá-los, e então saber seu retorno.


Ou, por exemplo, invocar um método que retorna uma lista de objetos para serem apresentados na tela. Esse objetos serão colocados no parâmetro data da resposta (JSON) e poderão ser obtidos e manipulados facilmente pelo JavaScript.


Baixe o código, dê uma lida, mande sugestões, correções, dúvidas. Sempre que possível, tentarei colocar coisas úteis lá.