e em seguida, Donald Smith convidou membros da comunidade para subirem no palco e participar de um painel. O painel contom com, entre outras pessoas, Bruno Souza (do SouJava) Martijn Verburg (do London User Group e da session Diabolical Developer) e focou, principalmente, na comunidade e as dificuldades de se manter um JUG com varias pessoas participando (e sempre que vejo paineis como esse, sinto-me um pouco culpado pela minha baixa participacao). Por ultimo, 3 dos 4 membros do JavaPosse subiram ao palco e conduziram varias pesquisas com a plateia e as technical session comecara.Do You Really get ClassLoaders? - Jevgeni Kabanov da Zero Turn AroundHonestamente achei que a palestra seria bem mais profunda do que foi. Jevgeni explicou o basico sobre classloaders e como eles funcionam em um ambiente JEE (mostrando varios exemplos bem didaticos) e explicando porque classloaders nao sao facilmente coletados. E como nao poderia deixar de ser, fez propaganda sobre o novo produto da Zero Turn Around - Live Rebel.The Art Of Java Benchmark - Aleksey Shipilev e Dave Keenan da OraclePalestra muito interessante, mostrando as principais tecnicas para se fazer micro-benchmarks bem como os principais obstaculos (visiveis ou nao). Aleksey tambem falou em como deve se saber exatamente o que se deseja descobrir com um experimento antes de faze-lo para evitar o erro tipo III - errar a direcao da causa e efeito - encarando os benchmarks como experimentos cientificos - inclusive dando bastante enfase em interpretar corretamente os resultados.Tambem deve se tomar cuidado para que a infraestrutura do benchmark nao interfira no benchmark propriamente dito. Talvez uma das melhores palestras sobre benchmarking que eu jah vi.LMAX Disruptor: High-Performance Concurrent Programming Framework -Martin Thompson e Trisha Gee da LMAXJa tinha ouvido falar do LMAX Disruptor antes, mas esta foi a primeira vez que eu ouvi a explicacao completa de como ele foi concebido. A palestra foi um pouco estranha pelo formato (os palestrantes alternavam perguntas entre eles e mantinham um dialogo), mas o conteudo foi otimo. Martin explicou o que significa mechanical sympathy: uma maneira de programar, levando em consideracao como o hardware funciona (caches, pipelines, memoria, etc), mudando bastante o conceito de como pensar no design de um software. Por sorte, muito do que ajuda o hardware a fazer um bom trabalho pode ser considerado tambem boas praticas de desenvolvimento: classes e metodos pequenos e especializados e codigo simples. Martin tambem desafiou a nocao de que precisamos desenvolver softwares que sao executados em paralelo para obtermos performance - por exemplo, com os processadores atuais, podemos executar 3 bilhoes de instrucoes por segundo. Por ultimo, eles mostraram como funciona o disruptor:-alguns processos (com uma thread cada) trabalham em cima de alguns ring buffers sem locks e sem sincronizar explicitamente os dados entre eles-como os dados se encontram num ring buffer em arrays (que nao sao explicitamente descartados), quase todo os dados ficam nos caches da CPU e podem ser rapidamente acessados quando necessarios, diminuindo os cache misses-quando um consumidor nao consegue consumir dados rapido o suficiente, o produtor comeca a ser pressionado, diminuindo a sua velocidadeEmbora essa