[quote=Bruno Laturner]
Mas sério, não vou ficar brincando de a-minha-api-padrão-é-melhor-que-a-sua.[/quote]
Até porque não existe o equivalente na API padrão do Java.
Acho que ele só postou esse exemplo de cópia de arquivos por ser bem simples de entender. Ele já postou, por exemplo, como é que se copia um arquivo com java.nio, por exemplo, que é claramente mais rápido que com Buffered*Stream.
É pena que a especificação do Projeto Lambda não está muito fechada, e você ainda não possa baixar uma versão funcional do site (você precisa baixar os fontes você mesmo e fazer você mesmo a compilação do JDK, o que não é nada muito trivial. ) Não é o “closures” do Neal Gafter (que não envolvia mudar a própria JVM).
O Projeto Lambda, que é uma modificação bem tímida da linguagem a meu ver, vai permitir algumas coisas que ainda não são possíveis em Java.
[quote=entanglement]Acho que ele só postou esse exemplo de cópia de arquivos por ser bem simples de entender. Ele já postou, por exemplo, como é que se copia um arquivo com java.nio, por exemplo, que é claramente mais rápido que com Buffered*Stream.
É pena que a especificação do Projeto Lambda não está muito fechada, e você ainda não possa baixar uma versão funcional do site (você precisa baixar os fontes você mesmo e fazer você mesmo a compilação do JDK, o que não é nada muito trivial. ) Não é o “closures” do Neal Gafter (que não envolvia mudar a própria JVM).
O Projeto Lambda, que é uma modificação bem tímida da linguagem a meu ver, vai permitir algumas coisas que ainda não são possíveis em Java.
[/quote]
Dependendo do tamanho do arquivo lido a diferença entre NIO e IO é irrelevante, e em operações maiores eu não afirmaria com tanta certeza, pelo menos sem saber qual o modelo de threads utilizado.
Bom post Thigol,
na revista JavaMagazine desde mês (ed. 82) foi publicada um artigo do Osvaldo Doederlein) sobre esse mesmo assunto, aos interessados recomendo a leitura.
Esse recurso, pelo que entendi é chamado de “Automatic Resource Management - ARM” e aparentemente tem impacto apenas na “verbosidade” do Java.
Os defensores dessa coisa, reclamam de fazer isso em um bloco finally:
if (bis != null) try { bis.close(); } catch (IOException ex) {}
if (bos != null) try { bos.close(); } catch (IOException ex) {}
Como se ninguém tivesse escrito classes utilitárias para evitar os catch vazios esparramados pelo código. Eu uso assim:
FileUtils.close(bis);
FileUtils.close(bos);
Com relação aos outros aspectos das novidades, eu ainda estou avaliando (risos).
fw
[quote=Dieval Guizelini]Bom post Thigol,
na revista JavaMagazine desde mês (ed. 82) foi publicada um artigo do Osvaldo Doederlein) sobre esse mesmo assunto, aos interessados recomendo a leitura.
Esse recurso, pelo que entendi é chamado de “Automatic Resource Management - ARM” e aparentemente tem impacto apenas na “verbosidade” do Java.
Os defensores dessa coisa, reclamam de fazer isso em um bloco finally:
if (bis != null) try { bis.close(); } catch (IOException ex) {}
if (bos != null) try { bos.close(); } catch (IOException ex) {}
Como se ninguém tivesse escrito classes utilitárias para evitar os catch vazios esparramados pelo código. Eu uso assim:
FileUtils.close(bis);
FileUtils.close(bos);
Com relação aos outros aspectos das novidades, eu ainda estou avaliando (risos).
fw[/quote]
Com certeza. Eu não considero como sintaxe sugar, pelo fato de realmente ser muito útil. Como citado eu precisaria de um finally para liberar os recursos, pois a vida deles se estende além do escopo mostrado acima. Dessa maneira o próprio ciclo de vida delas se encarrega de libera-los para mim.
Está acontecendo com o Java e C# o mesmo que aconteceu com o Delphi e VB: a MS lança uns recursos que atendem 0,001% de melhoria na produtividade e sai com um marketing de que possui o recurso e o outro não. Daí a outra empresa corre e implementa também, mesmo que na prática pouquíssima gente vai usar e que ajuda muito pouco no produto final.
Chega uma hora que as duas linguagens vão ficar tão cheias de recursos quase inúteis que vão ficar pesadonas, enormes e confusas, gerando códigos idem. Até que surja uma nova onda e comece tudo de novo.
Alguém sabe dizer se o MigLayout vai entrar na versão final?
[quote=marcosalex]Está acontecendo com o Java e C# o mesmo que aconteceu com o Delphi e VB: a MS lança uns recursos que atendem 0,001% de melhoria na produtividade e sai com um marketing de que possui o recurso e o outro não. Daí a outra empresa corre e implementa também, mesmo que na prática pouquíssima gente vai usar e que ajuda muito pouco no produto final.
Chega uma hora que as duas linguagens vão ficar tão cheias de recursos quase inúteis que vão ficar pesadonas, enormes e confusas, gerando códigos idem. Até que surja uma nova onda e comece tudo de novo.[/quote]
É o ciclo da vida 
Antes de comentarem se gostaram ou não, vamos combinar uma coisa: o Java 7 é uma lenda urbana! Está no mesmo nível de Duke Nukem Forever e Chinese Democracy. De quando e quando, sempre lançam uma espécie de “novas features do Java 7”, mas esquecem que não há JSR, não há apoio (e com razão) da Apache e, possivelmente, do Google, e não há mais a aparente benevolência da Sun.
Talvez um dia saia, mas é de um futuro tão incerto que me faz pensar: pra que se preocupar tanto?
[quote=marcosalex]Está acontecendo com o Java e C# o mesmo que aconteceu com o Delphi e VB: a MS lança uns recursos que atendem 0,001% de melhoria na produtividade e sai com um marketing de que possui o recurso e o outro não. Daí a outra empresa corre e implementa também, mesmo que na prática pouquíssima gente vai usar e que ajuda muito pouco no produto final.
Chega uma hora que as duas linguagens vão ficar tão cheias de recursos quase inúteis que vão ficar pesadonas, enormes e confusas, gerando códigos idem. Até que surja uma nova onda e comece tudo de novo.[/quote]
como uma linguagem fica pesada?
[quote=Leonardo3001]Antes de comentarem se gostaram ou não, vamos combinar uma coisa: o Java 7 é uma lenda urbana! Está no mesmo nível de Duke Nukem Forever e Chinese Democracy. De quando e quando, sempre lançam uma espécie de “novas features do Java 7”, mas esquecem que não há JSR, não há apoio (e com razão) da Apache e, possivelmente, do Google, e não há mais a aparente benevolência da Sun.
Talvez um dia saia, mas é de um futuro tão incerto que me faz pensar: pra que se preocupar tanto?
[/quote]
Pelo jeito, você não acompanha o desenvolvimento dele. hehehe
Ele tem o cronograma dos builds, as JSRs e os recursos planejados, está em desenvolvimento e tem data prevista, sim. Quaisquer alterações no cronograma costumam ser lançadas no site, que é de onde as pessoas aqui do forum buscam informações.
Era assim com a Sun, continua sendo com a Oracle, pelo menos até agora.
[quote=marcosalex]Pelo jeito, você não acompanha o desenvolvimento dele. hehehe
Ele tem o cronograma dos builds, as JSRs e os recursos planejados, está em desenvolvimento e tem data prevista, sim. Quaisquer alterações no cronograma costumam ser lançadas no site, que é de onde as pessoas aqui do forum buscam informações.
Era assim com a Sun, continua sendo com a Oracle, pelo menos até agora.[/quote]
Cite pra mim quais são essas JSRs, tem uma listinha aqui.
Ter cronograma não implica que vai ser respeitado (“Era assim com a Sun, continua sendo com a Oracle”).
Ter gente desenvolvendo não implica haver uma aprovação no JCP (“Era assim com a Sun, continua sendo com a Oracle”).
A resposta simples é “não”. Isso mesmo ele sendo um dos bugs mais votados,
Realmente, você não acompanha o desenvolvimento. :lol: :lol: :lol:
Quando você estiver mais infomado, a gente retoma o diálogo, ok?
Dizem que sim, do mesmo modo que dizem que o Joda-Time vai entrar também, mas acredito que apenas o Joda entre.
mas agora, parando um pouco com o trollismo
toda linguagem de programação que quer atacar java, principalmente as de script (groovy, ruby, python) usam o mesmo exemplo, o de sempre e provavelmente o pior, que mostra N drawbacks da linguagem numa situação simples.
num código de abrir arquivo, o cara tem que lidar com Streams de baixo nível e muitos try/catches inúteis, checked exceptions etc parecem ser os primordiais pro Java virar alvo de críticas e mostrando como “qualquer linguagem é melhor”
não que isso tenha sido discutido nesse tópico, longe disso, mas é que os exemplos de código (que eu mesmo postei também rs) me fizeram lembrar de outros flamewars em fóruns ou até em livros o.O
Acho que é válido notar que vc pode escrever 1 linha de código ao invés de 20 para ler um arquivo. Mas se vc copia e cola no final não faz diferença.
Eu posso fazer assim no JAVA 7?
int codCadastro = 345;
try (Connection con = ConnectionFactory.getNewConnection();
PreparedStatement ps;
ResultSet rs; ) {
String sql = "select * from cadastro where id = ?";
ps = con.prepareStatement(sql);
ps.setInteger(1, codCadastro);
rs = ps.executeQuery();
if (rs.next()) {
//....
}
} catch (Exception e) {
}Ou seja, declarar objetos que quero fechar no try, sem inicializá-los dentro do mesmo? (vide os objetos rs e ps).
Gostaria de saber porquê eu acabo setando os demais objetos dentro do try…
Um exemplo simples. (Fiz um exemplo boboca, suficiente para ser compilado sem referência a nenhuma classe externa. Obviamente você vai usar seu ConnectionFactory mesmo.) Tratei a exceção só no bloco mais externo, que é o que você faria na verdade.
[code]
import java.sql.*;
class TesteTryWithResources {
public static void main (String[] args) {
int codCadastro = 345;
String sql = "select * from cadastro where id = ?";
String url = ".....";
try (Connection con = DriverManager.getConnection (url)) {
try (PreparedStatement ps = con.prepareStatement(sql)) {
try (ResultSet rs = ps.executeQuery()) {
while (rs.next()) {
}
}
}
} catch (SQLException ex) {
ex.printStackTrace();
}
}
} [/code]
Outra forma, que é obviamente mais elegante, é:
import java.sql.*;
class TesteTryWithResources {
public static void main (String[] args) {
int codCadastro = 345;
String sql = "select * from cadastro where id = ?";
String url = ".....";
try (
Connection con = DriverManager.getConnection (url);
PreparedStatement ps = con.prepareStatement(sql);
ResultSet rs = ps.executeQuery()) {
while (rs.next()) {
}
} catch (SQLException ex) {
ex.printStackTrace();
}
}
}