Enquanto serras elétricas e martelos gritavam sobre nossas cabeças, heroicos desenvolvedores tentavam prosseguir com nossa produção intelectual. Afinal, os prazos correm e os clientes não querem aguardar.

O edifício mal foi inaugurado e já passa por reformas, pelo que parece.

A semana começou mal. Hoje foi a poluição sonora. Ontem tivemos inúmeras interrupções elétricas causadas, segundo alegou a empresa fornecedora, pelo vento.

O projeto, liberado sob a licença GNU General Public License 3.0 (GPLv3), está no Launchpad.

Deseja utilizar ou testar o chat? Para executar logo o programa, que dá a opção de rodar o servidor e/ou o cliente, abra este pequeno arquivo com o Java Web Start. Se a configuração de sua máquina estiver correta para o Java Web Start, a aplicação deverá ser automaticamente baixada e executada logo. Talvez seja questionado que a assinatura digital do arquivo não pode ser verificada e, nesse caso, basta clicar no botão “Run”.

Pode ainda salvar este arquivo DalTuxChat.jnlp em sua máquina (clique com o botão direito sobre o link e em “Salvar o destino” ou algo assim) e executar o programa a partir dele. Esta forma é interessante porque sempre o Java Web Start verifica se existe uma versão mais nova disponível on line e atualiza o programa mas, mesmo se o site estiver indisponível, a aplicação existe localmente e é executada.

Também é possível baixar o arquivo DalTuxChat.jar (atualmente 45KB) e executá-lo com java -jar DalTuxChat.jar ou apenas clicando-o duplamente, se seu sistema estiver devidamente configurado associando os arquivos JAR (Java ARchive) com o Java.

Este programa vem sem ABSOLUTAMENTE NENHUMA GARANTIA; veja detalhes na cláusula n. 15 da Licença.
Isto é software livre, e você pode redistribuí-lo sob certas condições; veja os detalhes na Licença.

O seguinte texto foi na realidade uma mensagem postada hoje por mim no fórum interno do curso de pós-graduação em Desenvolvimento Orientado a Objetos em Java. Achei interessante deixar o registro no blog, principalmente por considerar que seu conteúdo possa ser útil a alguém, embora o assunto seja bastante técnico e específico para quem lida com a linguagem Java.

No meu trabalho de conclusão de curso da graduação, assumi desde o início um padrão onde sempre retornava o Iterator no getAlgumaColecao() dos objetos de domínio. Isso inspirado por lições da disciplina Linguagem e Técnicas de Programação III, no ano passado, ministrada pelo prof. Arthur Zavadki, que desde então já pregava a idéia de evitar expor a coleção. Depois de um tempo, como isto não era muito conveniente por não poder utilizar p. ex. for(“each..”), passei a retornar a própria coleção como Iterable, mas isto também não era interessante por ainda permitir que a coleção seja diretamente manipulada por quem invoque o método, bastando um typecast para Collection. Aliás, a rigor isto também pode ser considerado um problema com o retorno de Iterator, que permite remoção de elementos durante a iteração.

Como sugerido pelo prof. Cesar Moro na última aula (turma 1), uma alternativa é criar uma nova coleção contendo referências para os mesmos elementos, tendo que percorrer a coleção original para tanto. Data venia ^[1], achei que isso não era muito prático, então lembrei na mesma hora do método clone(), disponível em diversas classes, que [em tese] faz aquele mesmo trabalho.

Fui mexer hoje em uma parte da implementação do meu TCC onde um «Bean» possuía o método public Collection<Posse> getPosses(). O atributo posses é um HashSet. Fiquei curioso e corri atrás de outras possíveis soluções.

Deparei-me primeiro com o método toArray(T[]) da interface Collection, que poderia ser utilizado da seguinte forma:
public Posse[] getPosses() {
return posses.toArray(new Posse[0]);
}
Encontrei uma discussão a respeito do toArray() em um site, levantando inclusive questões sobre sua utilização em multi-threading.

Outra solução que encontrei em seguida, bem interessante, é o método estático Collections.unmodifiedCollection(Collection), que escolhi utilizar da seguinte maneira:
public Collection<Posse> getPosses() {
return Collections.unmodifiableCollection(posses);
}
Portanto, é como costuma dizer o prof. Cléber Lecheta (graduação):

Existem mil maneiras de preparar Neston: escolha a sua.

Enfim, a maneira que escolhi é realmente adequada? A idéia é encapsular a coleção para que não seja alterada fora da classe à qual pertence. E quanto a questões como performance e escalabilidade, o que diriam? Se os professores e os demais colegas puderem participar, desejo ouvir a voz da experiência e agradeço desde já.

.NET

Novell

Eis a apresentação que, tal qual suas fontes de informações e imagens (site do Mono e Wikipedia), publicamos nos termos da GNU Free Documentation License:

• Apresentação – Projeto Mono (PDF, 777kB)
• Apresentação – Projeto Mono (Flash)

Deve ser útil como uma pequena fonte de informações iniciais sobre esse importante projeto.

Para quem quiser experimentar uma versão release candidate (candidata a lançamento), vá ao site de download. No momento da redação deste post, está disponível a versão RC3. Faça sua escolha, já que há considerável diferença de peso: o pacote “Eclipse IDE for Java Developers” é para programação geral em Java. Já o pacote para Java EE, bem maior, é destinado a quem também vai programar para a Web.

De qualquer forma, como a versão final deve ser lançada nas próximas semanas, ainda convém ter algum cuidado ao utilizar em ambiente de produção estes pacotes de previsão.