“A produtividade e a facilidade no desenvolvimento são hoje mais do que nunca fundamentais. Nesta edição destacamos uma das mais completas e populares IDEs livres para Java - o NetBeans. Patrocinado pela Sun e com uma comunidade crescente, o IDE NetBeans é uma excelente porta de entrada para o desenvolvedor iniciante, e oferece recursos sofisticados para programadores experientes. Veja também nesta edição artigos sobre Threads, New I/O avançado, testes de carga, Jini 2.0 e Struts.”
Já estou com a JavaMagazine em maos e esta show de bola…
:arrow: A Reportagem de capa sobre o NetBeans ficou show…quem nunca usou a IDE fica expert nela.
:arrow: Sun TechDays 2003…super evento, com certeza…nessa reportagem saiu sobre o evento…como sempre, presença em massa dos JUG’s brasileiros.
:arrow: Reportagem da ujtilização de Struts para fazer um carrinho de compras ficou animal…é só implementar! (Utilização de session, taglibs do Struts e MySQL)
:arrow: Reportagem de concorrência da JVM ficou legal também.
:arrow: Tem uma parte de I/O muito legal…input/output avançada…legal para quem já tem uma boa noção.
Bom pessoal, é mais ou menos isso…corram na banca e compram a sua…tá muiito legal mesmo!
No último parágrafo do quadro “O Modelo de Memória” ele da a entender que double-checked locking vai ser válido no novo modelo de memoria. Não é preciso nem saber oque isso é para verificar que está completamente errado. www.jcp.org/en/jsr/detail?id=133 no charter da JSR 133 mesmo fala que double-checked locking e boa parte dos idiomas duvidos para locking vão continuar inválidos na nova especificação.
O novo modelo, digasse de passagem, vai tornar ainda mais agudo o problema do double-checked locking.
[quote=“louds”]No último parágrafo do quadro “O Modelo de Memória” ele da a entender que double-checked locking vai ser válido no novo modelo de memoria. Não é preciso nem saber oque isso é para verificar que está completamente errado. www.jcp.org/en/jsr/detail?id=133 no charter da JSR 133 mesmo fala que double-checked locking e boa parte dos idiomas duvidos para locking vão continuar inválidos na nova especificação.
O novo modelo, digasse de passagem, vai tornar ainda mais agudo o problema do double-checked locking.[/quote]
Esclarecendo (sou o autor do artigo): da forma como coloquei no artigo,
que foi escrito bem antes de se bater o martelo sobre essa JSR, ficou
realmente equivocado. Ocorre que há várias variantes de implementação
do double-checked lock, e foi sugerida, nas discussões da JSR, uma
variante que funcionaria, porém utilizando variáveis volatile. Acho que
você consegue localizar isso na internet. O problema, que não me toquei
na hora – falha de pesquisa – é que a nova especificação torna o volatile
menos eficiente, de forma que o double-checked lock até funciona mas
não tem nenhuma vantagem de desempenho sobre um algoritmo com
locks (especialmente se você usar os novos locks mais eficientes da
java.util.concurrent). Ou seja, não adianta nada funcionar, se não tem
mais nenhuma vantagem. O que não funcionará são as versões mais
“light” do double-checked, sem usar nenhuma variável volatile. Na época
eu poderia ter detalhado mais a questão no artigo, mas é um assunto
que considerei low-level demais.
(Utilização de session, taglibs do Struts e MySQL)