As 5 tecnologias baseadas em Java para aprender em 2008

Assuntos Gerais Notícias
#181

O legal por aqui é que sempre quando sai prrd*, geralmente sai tb algo de bom do meio. O ideal é pular a parte da prrd* e ir direto ao debate quente mas educado.

Faça um programa que não libere nenhum objeto para o GC, rode ele com verbose:gc e veja se o GC vai acordar. Aqui no meu linux box ficou rodando por uma hora sem printar nada. Depois fui dormir… :slight_smile:

Se vc baixar o openjdk e dar uma olhada no código do SelectorImpl e do EPollSelectorImpl vai ver que o primeiro leak iterator a cada interação e o segundo está explicitamente chamando new Integer(nextFD) também dentro do loop!!! :cry:

Uma observação que fiz aqui há alguns posts atrás é que como o loop do selector vai rodar algumas milhares de vezes, pode não demorar muito para termos bilhões de inteiros no cache, no caso de vc mudar para autoboxing e usar o pool de wrappers. Interessante essa sua observação de que esse pool é limitado. Um pool de 4 bilhões de inteiros provavelmente não seria legal…

E a questão de primitivos eu concordo com vc e com o Doug. Já que Java tem primitivos então ela poderia vir de fábrica com collections para primitivos. Aqui nós implementamos nossas próprias collections de primitivos. Parece que Jakarta Commons Collections tb tem algumas. Outra opção seria controlar vc mesmo o pool de Integers, mas para isso vc precisa de um integer mutátvel. Um int[] com tamanho 1 é basicamente isso.

Como falei antes tb, num ambiente single-threaded (NIO), essas estruturas de dados podem ser otimizadas ao extremo e sem qualquer sincronização. Um pool de objeto acaba virando uma simples LinkedList. :wink:

#182

Vc é o Osvaldo Pinali ? Aquele que escreveu um artigo para a Java Magazine sobre as novas api concorrentes de Java ???

Cara, aquele artigo foi o mais impressionante que eu já li na minha vida, dada a qualidade técnica e a simplicidade com que vc descreveu e exemplificou um tema extremamente cabeludo.

Parabéns!!! Tenho aquela revista guardada até hoje…

Vc poderia aparecer mais vezes por aqui… :slight_smile:

#183

[quote=saoj]
Se vc baixar o openjdk e dar uma olhada no código do SelectorImpl e do EPollSelectorImpl vai ver que o primeiro leak iterator a cada interação e o segundo está explicitamente chamando new Integer(nextFD) também dentro do loop!!! :cry:

Uma observação que fiz aqui há alguns posts atrás é que como o loop do selector vai rodar algumas milhares de vezes, pode não demorar muito para termos bilhões de inteiros no cache, no caso de vc mudar para autoboxing e usar o pool de wrappers. Interessante essa sua observação de que esse pool é limitado. Um pool de 4 bilhões de inteiros provavelmente não seria legal…

E a questão de primitivos eu concordo com vc e com o Doug. Já que Java tem primitivos então ela poderia vir de fábrica com collections para primitivos. Aqui nós implementamos nossas próprias collections de primitivos. Parece que Jakarta Commons Collections tb tem algumas. Outra opção seria controlar vc mesmo o pool de Integers, mas para isso vc precisa de um integer mutátvel. Um int[] com tamanho 1 é basicamente isso.

Como falei antes tb, num ambiente single-threaded (NIO), essas estruturas de dados podem ser otimizadas ao extremo e sem qualquer sincronização. Um pool de objeto acaba virando uma simples LinkedList. ;-)[/quote]

Esses códigos como new Integer(…) existem mesmo no JDK, em muitos casos são simplesmente códigos legados (pré-JDK5) que ninguém da Sun ainda percebeu que podia revisar, no caso para tirar proveito do Integer.valueOf(). Talvez isso até ocorra na implementação do método Integer.valueOf(String s, int radix), o qual faz um new, sem delegar para o método que faz o cache. Você pode reportar isso como bug/sugestão, ou tentar corrigir vc mesmo no OpenJDK… Mas nem sempre é o caso. No exemplo de file descriptors, os IDs de arquivos podem ser números inteiros arbitrariamente altos (ou pelo menos bem altos), portanto não haverá muita vantagem em usar o Integer.valueOf() que só faz cache dos valores -127…+128. É um pool BEM limitado, é útil primariamente para índices de arrays pequenos, “magic numbers” como 0, 1 etc., e outros cenários onde é comum trabalhar com valores pequenos. Talvez quem escreveu aquele código de selectors ache que não vale a pena o overhead adicional (ainda que pequeno) de chamar o valueOf(). Por outro lado, face ao custo de abrir um arquivo/socket/etc, esse custo é desprezível, acho que valeria a pena sim evitar a alocação do wrapper, mesmo que numa minoria das vezes.

Note que o pool do Integer (e outros wrappers) não tem sincronização nenbhuma, pois o pool é fixo, sendo preenchido no momento de classloading da classe do wrapper.

Quanto a wrappers mutáveis, eu não gosto muito da idéia, pois são menos seguros para usos como chaves de Map’s, atributos de PK de entidades persistentes, e outros cenários comuns que “pedem” por objetos imutáveis.

#184

[quote=saoj]
Vc é o Osvaldo Pinali ? Aquele que escreveu um artigo para a Java Magazine sobre as novas api concorrentes de Java ???

Cara, aquele artigo foi o mais impressionante que eu já li na minha vida, dada a qualidade técnica e a simplicidade com que vc descreveu e exemplificou um tema extremamente cabeludo.

Parabéns!!! Tenho aquela revista guardada até hoje…

Vc poderia aparecer mais vezes por aqui… :-)[/quote]

Eu mesmo… obrigado pelos elogios :wink: tentarei aparecer mais, o problema realmente é que eu já escrevo tanto, que sobra muito pouco tempo (ou inspiração) par ficar contribuindo em foruns. Antigamente eu era bem ativo no JavaLobby e algumas listas, mas isso foi antes da JM e NBMag. Hoje até meu blog na java.net está às moscas, se consigo escrever um blog a cada dois meses estou satisfeito.

Por outro lado, quando tropeço numa discussão sobre um assunto como este, dificilmente deixo de cavar tempo para um reply…

#185

[quote=louds]
Lazy sweeping não é difícil de se implementar, já que opera completamente com memória fora do alcance do mutator step. O problema é implementar compactação ou cópia de forma concorrente ou lazy, que é o motivo pelo qual essa etapa ser stop-the-world no HotSpot.[/quote]

Isso é verdade. E existem outras maneiras de reduzir as pausas individuais do mark, mas sempre com algum custo, seja no tempo total de GC, seja no custo dos mutators. O algoritmo “train” é um exemplo, o próprio Metronome é outro. Sem falar na RTSJ, que permite reduzir drasticamente o tamanho do heap sujeito a GC convencional, porém com um custo tb de esforço da aplicação.

#186

IMHO, tecnologias baseadas em Java interessantes para aprender este ano:

  • JRuby
  • GRails ( a versão 1.0 foi lançada esta semana)
#187

[quote=Marcio Duran][quote=Daniel Quirino Oliveira]

É desenvolvedor Java há 8 anos, trabalhando atualmente como analista de sistemas para a EDS do Brasil,já tendo participado de diversos projetos Java EE para o setor de transportes, financeiro, e-commerce e telecomunicações. Além disso é coordenador do GUJ ( www.guj.com.br ) e costuma compartilhar seus conhecimentos em seu blog ( http://nullability.org).

Bom, é isso.

[update]:

Duas coisas para se pensar:

  • C++ não possui interfaces. Então seria C++ uma linguagem não-OO?
  • Java é 100% OO. Seria possível fazer isso então:

int a = 2; int b = a.add(3); assertEquals(b, 5); ??[/quote]

Bom o Daniel voltou ao assunto, e deu um exemplo de C++ em sua tese de JavaScript, tudo bem…
valeu a tentativa……

Ai vai a minha então sobre C++ e Java.

Algumas Linguagem (como C++)permitem que uma classe estenda mais do que uma classe.Essa capacidade é conhecida como “herança múltipla”.A razão pela qual os criadores de java decidiram não permitir a herança múltipla é que pode acabar bagunçando o código.

Já ouviu falar no cenário conhecido como o “Diamante da Morte”

Em obserção peço que sinceramente,leia o Capítulo 2:Orientação a objetos.
kATHY SIERRA
BERT BATES

[/quote]

Márcio,

Você escreve “encima”, “estenda”, um monte de idéias confusas e ainda duvida de tudo que está escrito, provado, testado etc … Você tem noção do que é networking? Tem noção que você tá se queimando na comunidade Java toda? Não sou de Java, mas todos os desenvolvedores/arquitetos/analistas que conheço, frequentam esse fórum aqui.

Caso a foto aí seja sua mesmo já te adianto: O pessoal ri muito do que você escreve e nunca vai te contratar pra um projeto.

#188

JEE 6.0
JSF 2.0
JPA 2.0
EJB 3.1
C#
Ruby
Python
É diversão garantida para um bom tempo! :wink:

#189

Ressuscitou o tópico.
As 5 tecnologias baseadas em Java [size=25]para aprender[/size] em[size=25]2008[/size]

Já estamos em 2009.

#190