Eclipse Launcher

12 \12UTC Setembro, 2008

Algumas vez se perguntaram porque é que umas vezes o Eclipse arranca um único processo chamado “eclipse”, e outras vezes arranca dois processos, um chamado “eclipse” e outro chamado “javaw”? A resposta está aqui.

Resumidamente, quando o pedaço de código do eclipse que é nativo de cada plataforma consegue iniciar uma JVM por JNI, temos um único processo, quando não consegue usa os executáveis do JRE em causa, o que resulta num novo processo. Uma forma de forçar a invocação por JNI e, consequentemente, a existência de um único processo, é especificar a opção “-vm” na linha de comando ou no ficheiro eclipse.ini  e apontá-la directamente para o ficheiro jvm.dll (ou libjvm.so) do JRE em causa. Isto pode ser particularmente importante quando se tem que parar programaticamente o eclipse em plataformas que não sabem muito bem gerir a hierarquia entre processos (leia-se: Windows): 

The fundamental problem here is that, unlike Unix, Windows does that maintain parent-child relationships between processes. A process can kill its own immediate children, but unless you make other arrangements to obtain the information, can’t kill any ’grand-children’ because it has no way of finding them. Ctrl-C types at a command prompt is just a character that the command processor interprets and not a signal sent from outside. When you ‘destroy’ a child command script, that process does not get the opportunity to terminate any child processes it may know about. Recent versions of WIndows (2000 or later) do provide a “Job” concept which acts as a container for processes. Killing a Job does terminate all processes associated with that job. However Jobs do not contain other jobs, so fully emulating the Unix behaviour is probably impossible. [Sun Bug ID: 4770092]      

  


EBCDIC String Sorting

14 \14UTC Agosto, 2008

Uma das muitas diferenças entre sistemas baseados em ASCII (ou qualquer dos seus super-sets) e os sistemas IBM – os mais tradicionais -, é que estes baseiam-se em EBCDIC, um sistema de codificação de caracteres de 8 bits que já vem do tempo dos cartões perfurados.

Essa herança tem uma consequência interessante: as letras do alfabeto não têm todas códigos consecutivos. Existe um intervalo entre a letra ‘I’ e a letra ‘J’, por exemplo. Outra característica interessante é que os códigos correspondentes aos dígitos 0-9 são maiores do que os códigos de todas as letras do alfabeto, enquanto que em ASCII acontece o oposto. Também os sinais de pontuação aparecem em posições relativas diferentes, assim como os caracteres acentuados.

Para referência, aqui ficam links para as duas tabelas: EBCDIC (codepage 037) e ASCII.

Em EBCDIC, a sequência efectiva de caracteres de acordo com o seu código numérico é a seguinte:

 âäàáãåçñ¢.<(+|&éêëèíîïìß!$*);¬-/ÂÄÀÁÃÅÇѦ,%_>?øÉÊËÈÍÎÏÌ`:# \

@’=”Øabcdefghi«»ðýþ±°jklmnopqrªºæ¸Æ€µ~stuvwxyz¡¿ÐÝÞ®^£ \

¥·©§¶¼½¾[]¯¨´×{ABCDEFGHI­ôöòóõ}JKLMNOPQR¹ûüùúÿ\÷S \

TUVWXYZ²ÔÖÒÓÕ0123456789³ÛÜÙÚŸ

Interessante, não? Os caracteres acentuados aparecem nos “intervalos”da tabela original…

Mas de facto, do ponto de vista prático, a consequência mais importante desta diferença é a seguinte: Uma aplicação baseada, por exemplo, em AS/400 apresenta uma listagem ordenada de forma diferente de uma aplicação escrita em Java. Em ambientes de migração esta diferença pode ter consequências drásticas para utilizadores que, por exemplo, tiram partido de o underscore aparecer antes das letras do alfabeto, para dessa forma criarem elementos que aparecem sempre à cabeça de uma lista.

Uma forma de, para o bem ou para o mal, passar a ordenar Strings de acordo com a tabela EBCDIC é implementar um Comparator que use um RuleBasedCollator criado especificamente com a sequência de caracteres EBCDIC.

Por exemplo assim:


String ebcdic_rules = "< â < à < á < ã < ç < ñ < '.' < '<' < '(' < '+' < '|' < '&' < é < ê < è < í < î < ì < '!' < '$' < '*' < ')' < ';' < '-' < '/' < Â < À < Á < Ã < Ç < Ñ < ',' < '%' < '_' < '>' < '?' < É < Ê < È < Í < Î < Ì < '`' < ':' < '#' < '@' < ''' < '=' < '\"' < a < b < c < d < e < f < g < h < i < '«' < '»' < j < k < l < m < n < o < p < q < r < ª < º < '€' < '~' < s < t < u < v < w < x < y < z < '^' < '£' < '[' < ']' < '´' < '{' < A < B < C < D < E < F < G < H < I < ô < ò < ó < õ < '}' < J < K < L < M < N < O < P < Q < R < û < ù < ú < '\\' < S < T < U < V < W < X < Y < Z < Ô < Ò < Ó < Õ < 0 < 1 < 2 < 3 < 4 < 5 < 6 < 7 < 8 < 9 < Û < Ù < Ú";

Collator collator = new RuleBasedCollator(ebcdic_rules);

if(collator.compare(a, b) < 0){
    //a is less than b according to EBCDIC sorting criteria
} else {
    //a is equal or greater than b
}


WebSphere headless

17 \17UTC Dezembro, 2007

Uma nota muito rápida sobre como conseguir que aplicações a correr em WebSphere possam usar classes do toolkit AWT sem que exista um ambiente gráfico funcional.

Para os apressados como eu a forma mais simples é definir como verdadeira a propriedade de sistema java.awt.headless, mas a teoria toda está muito bem explicada neste artigo da Sun.

Passar a propriedade no script que inicia o WebSphere, apesar de tentador, não funciona. O script de arranque do WebSphere faz apenas o bootstrapping do application server e a JVM que lança termina no final desse processo. A forma correcta está indicada nesta technote da IBM e passa por usar a consola de administração:

Servers > Application Servers > server1 > Process Definition > Java Virtual Machine > Generic VM Arguments

ou, alternativamente, editar directamente o ficheiro de configuração apropriado:

{$WAS}/config/cells/DefaultNode/nodes/DefaultNode/servers/server1/server.xml


Lenovo Rescue and Recovery

16 \16UTC Agosto, 2007

Já me passaram dois casos destes pelas mãos…

Aparentemente, alguns modelos dos novos Thinkpad vêm de fábrica com o software Thinkvantage Rescue and Recovery instalado e configurado para fazer backups periódicos.

Isto até podia ser uma medida interessante de protecção adicional, não fosse o facto de os backups serem guardados para um folder ao qual nem o Administrator tem acesso (takeown também não ajuda).

O que invariavelmente acontece é que, após algumas semanas de utilização do novo portátil, o utilizador dá conta que já quase que não tem espaço em disco. Surpreendido, decide seleccionar todos os folders da raíz do disco C: (ficheiros escondidos incluídos) e conclui que afinal até não está a ocupar muito espaço. Então para onde foi o espaço todo em falta e porque é que não consegue continuar a trabalhar?

O espaço em falta está todo a ser consumido por um folder

c:\RRBackups

que é onde o Thinkvantage Rescue & Recovery guarda os backups que vai fazendo. Como o administrator não tem acesso ao folder, este não é contabilizado no espaço ocupado quando se seleccionam todos os folders na raíz do disco.

Para ultrapassar o problema basta abrir o programa em causa (está lá, bem à vista, no Start Menu), desactivar o schedule que vem activo e eliminar os backups que já foram feitos.

Pode parecer um problema simples, mas o diagnóstico não é dos mais fáceis. Já houve até portáteis devolvidos à IBM por suposta avaria de hardware, que a IBM diligentemente substituiu por hardware igualmente “avariado”.


Novos portáteis Lenovo

10 \10UTC Julho, 2007

Recebi recentemente um portátil novo: um Thinkpad R61. Se dependesse só de mim esperava que o T61 chegasse ao distribuidor, mas não se pode ter tudo…

Já vem com o Windows Vista Business instalado e decidi manter, por um lado porque é que o caminho da menor resistência, e por outro porque gosto de experimentar coisas novas, venham elas da Microsoft ou não.

Foi a primeira vez que usei Vista durante mais de 5 minutos e a impressão foi bastante boa… até abrir o Internet Explorer! Já usava IE7 há bastante tempo no Windows XP e nunca tinha visto um comportamento tão mau como este. O browser abria bem rápido, mas depois engasgava durante uns 5 segundos antes de apresentar a página inicial – quer por acaso era about:blank. A mesma história repetia-se quando tentava abrir uma tab nova. Abrir uma tab é uma acção que espero que seja instantânea, esperar 5 segundos por isso é completamente inaceitável!

Mas é nestas alturas que dá jeito não ser fundamentalista e pensar dois minutos antes de culpar o Vista e instalar outro sistema operativo. Depois de procurar um bocado descobri que, basicamente, a culpa é de uma extensão para o IE7 que a Lenovo inclui nas instalações mais recentes. O add-on é o Lenovo Password Manager, que faz parte da ThinkVantage Client Security Solution. A extensão mantém-se activa mesmo que se desactive esta opção no Client Security Center, o que obriga a desactivar o add-on no IE para resolver o problema.

De uma forma geral acabei por desactivar a maior parte do software Lenovo / Thinkvantage que vem instalado de base. Mantenho o on-screen display, o power manager e pouco mais…


Seguir

Get every new post delivered to your Inbox.